注：文章来自对相关测试书籍的思考。

【原文】从狭义上讲，软件测试用于确认软件的质量，一方面是确认软件做了所期望的事情，另一方面是确认软件以正确的方式来做这个事情。

【细品】：

• 我们通常所以为的软件的质量是不是由测试保证的?其实不然，测试人员仅仅是确认、检查软件的质量是否符合某个标准，而并非是保证软件质量的，保证软件质量的人还是在于开发。

• 什么是做正确的事和正确的做事
  

【原文】从广义上讲，软件测试不仅是在测试产品本身，而且还测试软件开发生命周期的过程。如果一个软件产品开发完成之后发现了很多问题，则说明此软件开发过程很可能是有缺陷的。因此，软件测试是完善和提升软件开发过程的质量关键。

【细品】：

这段所说测试不仅测试的软件本身，更是在测试软件开发生命周期。这个我的感触太深了，我所在的公司测试团队对于软件整个开发过程的改善影响太大了，当然这源于我们有一个专业能力与影响力超群的leader，这个人是改善一切的关键。

我才去这家公司时，整个开发测试的现状如下：

1、做事情从没有规划，上至产品经理下发需求，下至软件产品上线后期跟踪维护，毫无章法

• 产品想召集大家讲需求就讲需求，想在开发测试过程中改改需求就改，一句话的事，从未有人拒绝或对需求中的糟点提出质疑，也很奇怪哦，当时这样的氛围下，该做的产品也一个没少，公司业务也照常进行着。
  

• 而测试呢，测试在测试前从不写用例，等待开发开发完以后直接对着需求文档测试，真大胆哦，既然是这样，测试用例当然也无存档，从不积累，也不用谈论用例评审什么的(那个时候根本不知道 用例评审 是什么?)，连bug我们都不带记录的，我们面对面去说，我曾一度觉得这样的做法简直不像一个拥有上百号人的公司的行为。
  

• 测试完了就该上线了，上线还算有点规划，至少能提前几天定下哪天上线，但并没有明确的上线策略(策略这个东西简直太重要了，不管是上线策略，还是测试策略又或更高层面公司发展策略)，那么，自然上线过程也不免坎坎坷坷。
  

• 我们都知道产品虽然都已经上线了，但不代表你所上线的东西是完美无bug的，一不留神上线后的第一天系统就瘫痪，页面、按钮异常，这种时候怎么办，我们当时反正是一锅粥，上面领导发脾气，下面干活的冒着虚汗排查问题，想想这画面就生动。

还有很多其他问题，此处不一一列举，这些问题其实就是整个软件生命周期过程的问题，一个普通的测试如果仅仅站在自己的职位立场上当然这些问题不是该你管的事，但是一个眼界格局够高的测试leader是必须要能够看到并改善这一恶劣情形的。

2、有项目时大家忙成一锅粥，没项目时呢，大多数人无所事事

• 代码框架优化的觉悟很少，大都是敌不动我不动状态，等待一直填坑。

• 部门知识积累基本没有，从不沉淀业务、技能知识。

• 除了工作本身以外，部门没有统一的一年规划，这时候的团队凝聚力也很差，人员流动性大。
  

以上是3年以前我所在公司在没有完善的软件开发周期过程时工作中存在的种种问题，可以说它关系着产品、开发、测试三方的和谐稳定性，而这样的过程由谁来推进改善呢?在我们公司这件事儿的确是由测试来完成的，现在想来我们领导真的厉害。

改善后的现状：

• 产品经理过需求必须提前2天发送邀请邮件，提前的目的是为了保证相关受邀人员能够提前查阅需求，待着问题去听，有疑问会上直接提出来，以确保会议的高效，需求没有明显的错误，同时也为后期开发测试的顺利保驾护航。
  

• 测试不再随意进行测试工作，必须在测试之前写用例，评审用例，这个过程其实是一个再次核对需求是否有误，确认大家对需求认知一致性的过程，以便及时发现隐藏的问题，调整方案。同时，根据已定的用例评估整个测试周期，提前预知上线时间。
  

• 测试的第一轮为冒烟测试，该轮测试不通过，则打回给开发，打回次数多了则应受到开发leader的重视，如此，逐渐提高开发自测的质量。冒烟测试通过以后，则进入真正的测试环节，发现bug务必提至相关的缺陷管理系统以便做好跟踪，并要求bug描述必须详细规范，减少二次沟通成本。
  

• 未上线之前，测试每天下班前都会发送进度邮件，告知干系人当前进度、问题等情况，以便及时预知风险。
  

• 上线至生成环境前必须做好上线策略，有条不紊的进行，突发情况做好预案。
  

• 生成环境的bug根据严重等级做好处理策略。
  

• 做好资产存档，知识分享，做到没有你在其他人可随时替补(这是站在管理者的角度，站在个人角度我们就需要想办法让自己不容易替代)。

整个核心的软件周期过程目前已得以改善，但依然还有很多其他问题需要继续推进，仅以此来记录我的测试生涯中的一点点痕迹，希望对其他测试同仁有所帮助。