软件测试价值提升之路--第2部分“扫门前雪”-第3章“拦截缺陷”-读书笔记

第2部分--扫门前雪

作为一个测试团队，基本的职责是： 测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。这些价值是作为一个测试所必须具备的，发挥这些价值能够让测试获得研发团队的基本信任。

这类价值分为3部分：

1、 拦截缺陷，即对产品进行测试，尽可能把产品的缺陷拦截在研发阶段；

2、 提供数据，即提供产品的质量结论，并且给出支撑这些结论的数据；

3、测试 过程可控，提升测试团队和测试工程师的能力，使得产品测试的效率、质量、成本都处于可控状态；

“扫门前雪”，说明这些价值基本上是测试的 本职工作，价值的发挥是依靠测试自身或者以测试为主进行能力建设。当然，这并不是说测试必须将这些价值发挥到极致，测试工程师还需要权衡成本和效益，找到合适的“ 度”。

第3章 拦截缺陷

拦截缺陷是测试最基本的价值，尽可能多地发现缺陷，尽可能在版本发布前发现并解决影响用户使用的缺陷，这是测试这个职业存在的基础。

为了说明问题的解决办法，这里按照缺陷的激活条件（产品中的错误在特定条件下被激活，导致产品出现故障，这个“特定条件”就是激活条件），把缺陷分为四类：

基本功能缺陷：用户进行正常业务的基本操作时，由于缺陷导致业务操作无法完成。这类缺陷对用户的影响最大，是研发最需要最优先解决的问题。

常规使用缺陷：用户大部分情况下能完成正常的业务操作，但在特定的条件下进行业务操作时，缺陷被激活导致操作无法完成，产品绝大部分的缺陷都属于这一类。想要减少这类缺陷，需要进一步按故障的影响范围和严重程度找到优先解决的重点。

受攻击暴露的缺陷：产品出现故障并非由于用户的业务操作，而是由于软硬件或网络环境发生异常、业务请求超出预期而造成过载、受到黑客攻击等。这类缺陷对用户的影响很大，但用户会基于成本来考虑解决的方式，不一定全部是通过增强软件能力来解决。

随机出现的缺陷：产品出现故障的条件不明确，如果故障的影响范围大、严重程度高、出现频次高，也会对缺陷进行专项分析。

3.1用户无法正常使用

3.1.1.问题案例

这类缺陷典型的有： 安装或升级过程中出错，新研发特性的基本功能有错，升级后原本正常使用的功能出错，产品在正常使用中数次崩溃，正常使用中有导致用户直接经济损失或信息泄露的错误。

3.1.2解决问题的思路

一般处理原则：如果这类错误经常反复发生，测试需要把拦截缺陷作为最优先的任务。

解决方法：这类缺陷的发现条件是，只要测试时覆盖了这个功能或特征，就能够发现缺陷。

推荐的解决思路是：

1、 建立基本的测试用例基线，基本用例集包含产品最常见的业务场景，覆盖绝大部分功能特性。

2、 尽可能实现100%自动化测试，在每次启动测试、产品发布之前都将基本测试用例全部测试一遍。

3、有时候出现问题还与 客户数据、环境和使用方法有关，那么基本用例基线的测试用例就需要包含客户的数据、环境、应用场景等信息，并按版本、客户进行管理。

无论是否有专业的测试团队，产品在发布之前一定是验证过基本功能的。缺陷没有被拦截，实际上大部分原因是：

新增的功能测试了，原有的老功能 没有全部测试；

原有的老功能测试了，但是 检查结果不完整；

新、老功能都测试了，但是测试用例和用户的 常用使用场景有出入；测试环境的基础数据、开关设置、终端类型、操作系统版本等和用户常用的使用数据有出入。

建立测试用例基线是确定了产品的常见使用场景，而自动化是固化成果，确保每次发布常规场景都能正常使用。

3.1.3建立测试用例基线

我们的产品都要求建立测试用例基线，用例基线包括 基本用例（基本用例集）、 常规用例（绝大部分正常和异常用例）、 生僻用例（非常规手段才能实施的测试）。

测试用例基线的建设标准包含 基本要求和附加要求两部分。基本要求主要关注测试用例基线的 完整性；附加要求主要关注测试用例基线是否 易于使用。

基本要求：

1、建立产品级测试用例基线，基线覆盖产品的 全部特性功能和所有质量属性。这是为了随时都能根据用例的测试结果得到 产品质量的整体试图。

2、测试用例基线中的用例集或用例，包含与产品特性、产品需求的 对应关系。这是为了在测试结束时，按特性或需求进行 测试结果分析。

3、测试用例基线包含基本用例集，基本用例 100%覆盖产品特性。要求每个产品特性都 至少有一个用例在基本用例集中。

4、测试用例基线的用例 不存在空用例、拷贝用例、自动化脚本和文本不一致等情况。这是 用例质量最基本的要求。

附加要求：

1、测试用例