【软件测试理论】（二）测试流程体系

1. 软件测试基本概念

1.1 软件测试的概念

软件测试的概念：

• 通过手动或者工具对"被测对象"进行测试，验证实际结果与预期结果之间是否存在差异。

1.2 软件测试的作用

软件测试的作用：

• 通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
• 测试可以降低同类型产品开发遇到问题的风险。
• 产品同质化严重，需要通过用户体验留住用户。

1.3 软件缺陷的概念

软件缺陷的概念：

• 软件缺陷被测试工程师和开发工程师称作为BUG。
• 软件缺陷会导致软件不能正常运行，它的存在会在一定程度上导致软件不能满足用户的需求，甚至有可能破坏会泄漏用户的重要数据。

1.4 软件测试的原则

软件测试的原则：

• 测试显示缺陷的存在
  • 说明软件存在bug，但是没法估计数量。
• 穷尽测试是不可能的
  • 测试活动是有时限的，无法把所有场景都覆盖。
• 测试尽早接入
  • 为了更好的去解决问题，早发现早解决，成本也越低。
• 缺陷集群性(2/8原则)
  • 遇到的权限基本集中在20%的功能模块中。
  • bug集聚的地方，问题可能会更多，需要重点和反复去测试。
• 杀虫剂悖论
  • 测试用例不能拿来测试太多次。
• 测试活动依赖于测试内容
  • 对每一个软件测试 使用的技术和理论是不同的，没有那两个系统可以用同样的测试方法。
• 没有错误是好是谬论
  • 测试没发现问题，不代表软件不存在问题。

1.5 软件测试的对象

软件测试的对象：

• 需求分析阶段：需求文档、接口文档
• 编码实现阶段：源代码
• 系统功能阶段：软件程序

1.6 测试用例的概念

测试用例的概念：

• 为特定的目的而设计的一组测试输入、执行步骤和预期结果，以便测试产品是否满足某个特定需求的文档。

2. 软件测试模型

2.1 V模型

模型说明：

• V模型是瀑布模型的一种改进，标明了测试过程中不同阶段。

各阶段说明：

• 需求分析：开发人员执行
• 概要设计：开发人员执行
  -详细设计：开发人员执行
• 编码：开发人员执行
• 单元测试：按照设定好的最小的单元去进行测试，可能是类、函数，主要是测试最小模块的功能是否正确。
• 集成测试：检测之前测试的小模块组合之后功能是否正确，在单元测试基础之上，把功能组合再去检查功能是否正常。主要测试内容是接口。
• 系统测试：把软件系统看成是一个整体进行测试，是在集成测试完成之后进行。
• 验收测试：已经完全以上的测试，送个客户之前进行最后的测试，主要测试是否满足客户的需求。

优缺点：

• 优点：
  • 既有底层测试又有高层测试。
  • 将开发接单清楚的表现出来，便于控制开发过程。
• 缺点：
  • 容易让人误解为测试是在开发完成之后的一个阶段。
  • 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些BUG可能不容易找到其根源，并且代码修改起来困难。
  • 如果需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

2.2 W模型

模型说明：

• W模型明确表示出测试与开发的并行关系，测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。
• 开发和测试流程每一步都是对应的关系。

优缺点：

• 优点：
  • 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。
  • 更早的介入到软件开发中，尽可能早的发现缺陷进行修复。
  • 测试与开发独立起来，并与开发并行。
• 缺点：
  • 无法支持迭代的开发模型。
  • 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
  • 对于需求和设计的测试技术要求很高，实践起来很困难。

2.3 H模型

模型说明：

• 软件开发中需求、设计、编码等活动被分阶段执行，但是实践中，他们并不是完全串行的，他们之间更多时候是交叉进行的，更多的是迭代执行。
• 把测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

优缺点：

• 优点：
  • 软件测试完全独立，贯穿整个软件开发生命周期，且与其他流程并发进行。
  • 软件测试活动可以尽早准备，尽早执行，具有很强的灵活性。
• 缺点：
  • 测试就绪点分析困难。
  • 对于整个项目组的人员要求很高。

3. 软件测试工作流程

3.1 传统测试流程

部分测试阶段说明：

• 冒烟测试：

  • 开发提交代码后，在系统测试之前，需要把所有功能流程全部跑通，也就是对软件基本功能进行测试。

• 回归测试：

  • 修改代码后，对原有bug进行测试，确保bug被修复且无新bug被引入。
  • 两种回归测试：bug修复后回归；老功能进行回归

传统测试流程缺点：

• 测试也是在开发编码结束后进行的，如果开发编码迟迟不好，测试人员只能等着开发进行提测，处于被动状态，也可能因此导致测试时间大大压缩，无法进行充分测试，导致漏测的情况出现。

3.2 系统测试流程

部分测试阶段说明：

• 需求分析：
  • 产品先出需求文档，然后召集开发和测试进行需求评审会议，会上会讨论需求内容：样式、作用等功能，然后进行需求评审
• 测试计划：
  • 版本测试时间
  • 开发提测时间
  • 测试用例谁写，测试人员有几个
  • 回归测试范围有多大
  • 版本协同谁负责，测试总结谁负责
• 测试设计：
  • 使用测试的方法，进行测试用例设计。考虑所有测试场景
• 测试执行：
  • 符合预期通过，不符合预期提交bug，附上截图、录屏、日志等信息
  • 督促开发修改BUG
  • 修改好BUG后进行回归测试
  • 对新功能测试好后，还要对有影响的老功能进行回归测试

3.3 BUG管理流程

部分流程阶段说明：

• 提交bug：
  • 写缺陷报告，清晰描述一些基本内容：
    • 做了什么操作，发现什么现象；
    • BUG的类型：功能还是性能；
    • BUG复现步骤；
    • 期望结果和实际结果；
    • 截图、录屏、日志文件。

4. 测试左移和测试右移

4.1 测试左移

什么是测试左移？

• 测试左移是往测试之前的开发阶段移动；
• 测试团队在软件开发周期早期就开始介入；
• 对代码进行测试；
• 测试团队的责任从发现bug到预防bug。

质量保障手段：

• 代码评审
  • 研发人员之间进行代码评审
  • 测试人员评审开发代码
• 代码审计
  • 偏自动化的一种手段，使用自动化工具去发现代码中的问题。
  • 比如，安全团队对代码进行审计。
• 单元测试
• 自动化冒烟测试
  • 快速验证和回归方法
  • 测试团队提供一个自动化冒烟的脚本去确定基本功能是否正常。
• 研发自测

4.2 测试右移

什么是测试右移？

• 测试右移是往发布之后移动；
• 产品上线后进行线上监控。

线上监控内容：

• 闭环的线上问题反馈-检查-解决-更新流程
• 更便捷的日志查看、回传服务
• 丰富有效的log，便于问题的快速定位
• 丰富的监控指标（例如业务异常点指标）
• 业务监控（例如短信发送等）
• 关键指标每日监控（服务器指标）
• 生产数据监控（警报）