用体温计量体温不能治病，它只能证明一个人生了病；同样地，对软件的测试，并不能提高软件质量，它只能证明代码中存在缺陷。

1. 软件测试危机

1.1 国内软件测试的困境

目前的软件开发环境中，最在乎软件质量的是用户、项目经理，最应该在乎软件质量的软件测试人员并不关心软件本身的质量，他们只想找 bug。

早期的软件开发过程中，软件的质量仅仅只是靠编码后的测试来验证，谁能真正提高软件的质量呢，其实是开发人员，因此那时候软件开发人员的薪水要比测试人员高很多。

后来，大多数软件开发团队意识到，只有提高整体的软件开发效率，才能激烈的竞争中占有优势。这一时期有两个明显的特征：软件测试的周期越来越短，因为在交付的压力下，不再有以前那样充足的测试时间；软件测试人员的工作贯穿整个软件开发的周期。软件开发的 W 模型很好地诠释了这一时期的软件测试工作特征，软件测试有了专门的团队，测试人员的地位相比于过去有了明显的提高。

再后来软件开发的流程演变成螺旋模型，摒弃了 W 模型的长周期，追求增量开发，随着一轮又一轮的编码和测试，软件开发处于一种不断迭代的过程中。现在流行的敏捷开发模型，本质上还是螺旋模型。

即使是螺旋模型，测试人员始终还是从事着质量控制（Quality Control）的工作，不断手段多么花哨，接口测试，自动化测试，性能测试，安全测试，各种先进的测试工具，本质上和手工点点点找 bug 并没有什么不同。在软件的开发过程中，测试人员依然是很被动，被动体现在不能主动提高软件的质量。

1.2 软件测试人员的危机

软件测试人员将会分层，有管理能力熟悉测试流程的顺利成章地成为测试过程的管理者，代码能力强的演变为测试工具的开发者（为项目定制的自动化黑盒测试工具，为项目定制的性能测试工具等等），代码能力差的就只能从事点点点的黑盒测试。

黑盒测试岗位门槛较低，可替代性强。在不远的将来，黑盒测试人员不是被测试开发人员取代，就是被测试工具开发人员开发的测试工具取代。值得一提的是：当黑盒测试被取代之后，测试过程管理者也会有失业的风险，他们必须要转型为测试架构师才能适应潮流，才不会被后浪拍死在沙滩上。

2. 解决危机

2.1 引入软件质量保证

绝大多数公司招聘测试人员，更多地是：想通过他们的测试工作，去发现软件中存在的问题，修复缺陷，从而提高软件的质量。很明显，这是一种头痛医脚的行为，提高软件的质量难道不是更应该去直接提高代码质量吗？

对于测试人员来讲，解决软件测试危机的办法就是专注于提高整个开发过程的质量，也就是说，成为软件开发项目的质量保证人员（Quality Assurance）。测试人员更多的是需要在整个软件开发的过程中，通过制定标准，监督执行，保证每一个环节的质量，从而提高整个软件开发过程的质量。这其实是一整套解决方案，当你的过程有了标准化的、成熟的解决方案之后，软件的质量一定是过硬的。

2.2 质量保证的思路

对于螺旋模型而言，最基本的单元就是：

需求分析->详细设计->编码->集成->测试->验收

那么每一个过程都应该有对应的工作过程及体现工作过程的文档，质量保障人员就可以根据以往成功的经验，制定合理的质量标准体系来指导和优化工作过程，同时也在实践中优化质量体系。

3. 如何保证软件质量

如何保证软件质量这个问题很宽泛，应该保证以下几个方面的质量，那么软件的质量将得到保证。

3.1 需求文档质量

• 需求描述详尽：无缺漏，无歧义，无重复，没有无法实现的，没有巨大风险
• 需求指标明确：前提条件明确，数据指标精确。

3.2 设计文档质量

• 字段定义明确：字段没有混淆，数据来源和走向清晰
• 逻辑清晰通畅：软件操作不会进入死胡同，用户使用场景考虑全面
• 交互简单易懂 ：每个按钮点击前是怎样，点击后会有什么变化
• 提供丰富的辅助文档：Visio 流程图，Xmind 思维导图，Axure 交互原型设计文档等

3.3 代码质量

• 优质的框架设计：根据项目的实际情况选择合适的技术栈，底层设计容错性高、健壮性好、可扩展性好，前端兼容性好、性能好
• 编码规范：参考阿里巴巴的 java 编码规范制定
• 代码走查：开发人员自己或者结对进行代码走查，考虑逻辑是否完备，数据处理是否到位，场景是否缺漏，算法性能是否最优
• 代码评审：评价代码是否还有改进的空间等
• 单元测试：开发人员自行编写单元测试，测试函数方法是否满足要求，随着代码版本的迭代，能否保持原来的功能

3.4 测试质量

3.4.1 测试策略

后端测试：接口测试，压力测试，部署测试，安全测试

前端测试：UI 测试，性能测试，兼容性测试，安全测试

3.4.2 测试方法的质量

• 设计合理的测试方法
• 测试方法的评审
• 改进优化测试方法

3.4.3 测试用例质量

• 良好的用例设计方法：等价类划分、因果图法、场景分析法、正交分析法、路径覆盖、逻辑覆盖、语句覆盖
• 用例评审：保证测试的广度（界面、接口、数据库、日志）和深度（测试要点的精细程度）
• 测试用例维护：测试过程中补全缺漏的和思路有问题的用例，记录线上故障并添加到测试用例中

3.4.4 缺陷质量

• 缺陷分级：一般四级分类法，
• 缺陷记录：bug 管理系统，bug 的生命周期理论
• 缺陷反思：bug 评审，开发避免类似错误，测试在设计测试用例的时候考虑类似情景

3.5 部署质量

不是说保证了设计、开发、测试质量之后，产品上线后质量一定好。因为部署上线还有一整套流程，部署流程的质量，直接决定了产品的上线质量。
部署环境：硬件环境和软件环境，是否满足功能和性能要求
部署时机：选择对用户影响最小的时机，一般游戏更新选在午夜。
部署参数：测试环境的参数和正式环境的参数往往是不同的，往往涉及到参数的调整。
自动化部署：流程化，自动化的部署将大大减少人为失误。

3.6 风险控制

• 项目风险：需求变动，开发环境不能满足，人员缺失，技术自身风险，安全风险
• 风险预测：根据项目实际情况和自身的软件开发经验，找到薄弱环节和不确定的环节，这些往往都是风险高发处
• 降低风险： 在可能发生风险的地方做好两手，甚至多手打算

3.7 组织技术学习

从长远来看，提升团队的技术水平，也能够提升软件产品的质量

4.结论

保证软件质量需要一整套的质量保证体系，搭建这样的体系是 QA 的核心竞争力。QA 人员在从业的道路上需要不断地打磨自己的业务能力、技术能力、团队合作能力，才能在激烈的市场竞争中立于不败之地。