【禁止转载】如何提高测试覆盖率

总结步骤:

1、需求规格说明书 => 需求点

2、需求管理公共库 => 补充需求点

3、需求点 + 测试分析 => 测试项

4、测试项 + 测试设计 => 测试点

5、开发的设计文档 => 模块测试指导书 => 补充和挖掘测试点，修正前期不合理需求 6、分析用户使用场景 => 检查当前案例是否能覆盖到用户场景 => 补充场景案例

对于一个产品的核心模块，决不能简单的根据需求和分析设计产出案例，而是要从 各个方面的挖掘，通过实践，对 5、6 步具体如何做，我自己整理出一套可供参考的方 法，下面详述上面的实践过程:

一、需求规格说明书 + 需求管理公共库 => 需求点

1、根据需求规格说明书划分大模块 2、细化某个大模块，分解出的需求点 3、参考需求管理的公共库，补充需求点

=> 输出:得到原始需求表，如下

二、需求点 + 测试分析 => 测试项

根据 以往的经验库，进行测试分析: 1、版本设计经验

2、升级测试分析

3、模块整体分析

4、关联测试分析 5、模块设计经验 6、领域经验检视

 => 输出:得到基本测试项，如下

 三、测试项 + 测试设计 => 测试点

根据以往的经验库，进行测试设计: 1、基本设计方法

2、产品专项经验

3、正交组合设计

4、业务逻辑设计

=> 输出:得到基本测试点，如下

四、开发的设计文档 => 模块测试指导书

开发的设计文档一般除了阐述功能的实现思路，还会涉及比较多的函数接口甚至开发代 码，因此我们看开发设计文档第一遍的时候，容易云里雾里抓不住重点。

我们其实只需要看我们要关注的东西，其他东西可以简单浏览。只有快速抽出重点关注 项，才能高效的产出模块测试指导书。

我自己整理了如下几项，可以帮助我们快速从开发的设计文档中找到重点，作为后续 的实践参考:

1、该模块是否涉及到一些全新的概念(比如我们的 bbc 全量包)，需要明确? 2、该模块包括哪些服务?

3、该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?

 4、该模块的操作流程有哪些?是否有子流程图? 5、该模块是否有多个状态的转化?是否有明确的状态转化图? 6、该模块对多个管理员是否区分，管理员权限如何设计? 7、该模块是否有一些特殊的操作限制?操作限制是否有明确的表格? 8、该模块的任务是否有并发需求?并发的设计?

9、该模块的所有指标如何? 10、该模块是否有异常处理机制?在设备各种异常时，该模块的设计是否满足能稳健运行?

上面这些点其实就是产出模块测试指导书的基石，而且也是我们测试过程需要关注的 重点，我们通过明晰上述每一点就能自然而然的写出测试指导书。如下，我写的配置管理 模块的测试指导书抽取的就是上面那些点进行分析的:

而且在上述过程中，我们需要能够逆推开发完善其设计，推动需求的完善。开发的设 计总是和需求有或多或少的出入，我们此时充当检视者的角色，检视开发的设计是否符合 需求，检视需求是否能够以合理的代价被实现。

=> 输出:(1)模块测试指导书 (2)推动开发完善设计，如下面邮件所示 (3)推动需求完善、甚至增删需求，如下面邮件所示

  五、模块测试指导书 => 挖掘测试点

在上面第三小节，我们已经产出了基本测试点，但是那些都是根据需求和前期分析得到 的，可以肯定存在着不少遗漏。我们就需要把《模块测试指导书》充分的利用起来，把其中 涉及的点都合理的转换成测试点，甚至能够在指导书中挖掘出更多的东西。

那么我们应该如何利用《模块测试指导书》挖掘补充测试点呢? 我总结了以下几点， 可供后续实践参考:

1、做例行的补充: (1)全部服务的异常监测、服务重启

(2)各类存储对空间的占用、占满、是否需要做存储的接口测试

(3)所有类型的管理员，操作权限测试、支持的多少管理员并发操作

2、可挖掘之处:

(1)对流程图的挖掘 --流程图全部流程测试、流程图重要的节点异常测试

(2)对状态的挖掘 --所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下

       哪些操作可做哪些不可做、多个状态是否可以共存

 (3)对关联项的挖掘 --流程进展到某一步关机重启/服务重启、和备份配置的关联、和操作 日志的关联等等

(4)任务的并发操作测试、是否可配置、是否会出现性能不足，是否符合用户场景

(5)异常处理机制测试，异常处理机制是否完善

(6)指标测试(这里要知会到专项测试人员)，开发的指标设计是否合理

=> 输出:(1)补充测试点，如上 (2)推动开发完善设计，如下

(3)推动需求完善、甚至增删需求，如下

       六、分析用户使用场景 => 补充场景覆盖

上面的一至五小结，全部分析完之后，你是否觉得已经很可以了? no!

我们最后还是要以客户导向为原则，再次检视一遍设计的合理性，因此，我在测试设计 的最后还是回过头来再次分析了用户的使用场景。然后我发现了以下几类问题: (1)案例的测试点虽然已经够全面了，但是因为一个点只涉及到一个功能，会导致用户场 景的整体流程没有覆盖到。如下，删除设备就不能只用一个删除设备的案例覆盖，它涉及到 多种组合方式，如下:

(2)好多测试点之间可能只有几个步骤有差异，大部分步骤存在冗余，用一个场景直接覆 盖会更加清晰高效

(3)检视发现真的遗漏了某个重要的点(比如我们 BBC 用户都会从公网跳转，但是测试点 没有从用户角度出发就容易遗漏) (4)检视案例也可能发现有些案例之间关联性太强了，分开测不太合理，合成一个测试点 又会导致案例步骤太长、案例太过复杂。比如模板多次分化的场景它比较复杂，无法用一个 案例单独覆盖，如下:

针对上述问题，我们可以:在该模块的场景类中起一些场景目录重新覆盖一些测试点、 或者补充覆盖某个没有考虑到的用户场景

=> 输出:该模块的场景案例，如下