霸气侧漏OK,但“漏测”？

一个信心十足的测试人员可以是“霸气侧漏”的：“相信我！都测过了！”。但不幸的是，一上线，发现“漏测”了！不是需求理解的遗漏，而是代码级别的漏测，防不胜防啊！那有没有办法避免“漏测”呢？

让我们先来看一个关于测试的核心问题：QA测的, DEV改的，用户用的，这3者是什么关系？

我认为的理想关系是这样的：

图1

但实际上的关系往往是这样的：

图2

图2中：

•黄色部分代表：“DEV改的”但没有被 “QA测的”

•红色部分代表：“DEV改的”且“用户用的”但没有被“QA测的”。它可以被包括在上面黄色的部分，只是测试优先级更高

•橙色部分代表：“用户用的”且没有被“QA测的”

那么如何避免这些”漏测“呢？

1. 针对“DEV改的”但没有被 “QA测的”（黄色部分）

•目标：

  • 通过提供“本轮DEV改过，但测试环境没有跑到的代码”的报告，指导QA补测这些地方，实现“凡改动过，必测过”。

•思路：

  •通过GIT 拿到当前正在开发的DEV branch和产品的Release branch之间的差别，识别出改动过的代码

    •通过jacoco得到测试环境的累计的代码覆盖情况

    •比较得出：本轮改动过，但没有被测试覆盖过的代码报告。

      •QA根据报告，补测

•参考资料：                  •https://testerhome.com/articles/16982

2. 针对“用户用的”且没有被“QA测的”（橙色部分）

•目标：

    •通过提供“用户常用的，但测试环境没有跑到的代码”的报告，指导QA补充自动化测试用例，实现“用户常用的，必被自动化测试时刻保护”。

•思路：

    •识别什么是“用户常用的”？(通过静态和动态结合的方法）

          •功能级别：BA提供VIP客户的业务流程/数据；QA分析VIP客户的真实数据

            •方法级别：ART report （提供被访问的方法列表（带累计访问次数））（这个是我们内部的一个报表）

            • 代码行级别：产品环境的Jacoco report

•方案：

          •理想方案：到代码行级别

                •产品环境jacoco report 覆盖到，但QA环境自动化测试后的jacoco report里没有覆盖到的方法/行。

                •*需要测试jacoco report对性能的影响

          •现实方案：到方法级别

                •产品环境ART report 里按照调用次数排名，没有被QA环境自动化测试后的jacoco report覆盖到的方法列表。