詹聪聪 2020/05/08 02:08:40
用体温计量体温不能治病，它只能证明一个人生了病；同样地，对软件的测试，并不能提高软件质量，它只能证明代码中存在缺陷。
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 测试策略
后端测试：接口测试，压力测试，部署测试，安全测试
前端测试：界面测试，性能测试，兼容性测试，安全测试
3.4.2 测试方法的质量
设计合理的测试方法
测试方法的评审
改进优化测试方法
3.4.3 测试用例质量
良好的用例设计方法：等价类划分、因果图法、场景分析法、正交分析法、路径覆盖、逻辑覆盖、语句覆盖
用例评审：保证测试的广度（界面、接口、数据库、日志）和深度（测试要点的精细程度）
测试用例维护：测试过程中补全缺漏的和思路有问题的用例，记录线上故障并添加到测试用例中
3.4.4 缺陷质量
缺陷分级：一般四级分类法，
缺陷记录：bug管理系统，bug的生命周期理论
缺陷反思：bug评审，开发避免类似错误，测试在设计测试用例的时候考虑类似情景
3.5 风险管理
项目风险：需求变动，开发环境不能满足，人员缺失，技术自身风险，安全风险
风险预测：根据项目实际情况和自身的软件开发经验，找到薄弱环节和不确定的环节，这些往往都是风险高发处
降低风险： 在可能发生风险的地方做好两手，甚至多手打算
3.6 组织技术学习
从长远来看，提升团队的技术水平，也能够提升软件产品的质量
4. 总结
- 对软件的测试并不能直接带来软件质量的提高，目前软件质量更多的依赖开发人员自身的素质。
- 当测试人员转变为质量保证人员的时候，他就和开发人员一样，为项目带来直接的价值。
- 质量保证需要全流程的质量管理和控制。
