精准测试——持续测试

news2024/11/16 1:46:38

前面已经介绍了黑盒测试和白盒测试。从前面的介绍中可以知道，黑盒测试是一种面向业务流程的测试，针对需求设计测试用例，在运行的系统上执行测试用例，完成测试。

整个测试过程中测试工程师对于测试代码是如何运行的一无所知，只能通过输入、输出评价系统的逻辑处理是否正确。

而白盒测试恰恰相反，测试人员需要面向代码测试，根据代码逻辑、覆盖路径设计测试用例。对于白盒测试用例而言，被测系统的代码是可见的，测试需要检查程序的内部结构，从程序逻辑入手，得到测试数据。

在黑盒测试中，针对需求的测试用例，代码覆盖率一般为60%～70%，如果要提高系统的测试覆盖率，需要投入的测试成本会远远高于覆盖率达到70%时的测试投入。

同时，黑盒测试过程中代码是不可见的，如果要获取更高的覆盖率，就只能设计大量的冗余测试用例，但是大量的冗余测试用例只使得提升覆盖率变成一种可能的行为，这并不是一个充分必要的方法。

冗余的测试用例会导致测试投入高、测试用例难以维护等连锁反应。针对上述这种情况，白盒测试在提升测试覆盖率上的效果就好很多。

因为白盒测试中的代码逻辑是可见的，所以每增加一个测试用例，我们就可以直观地看到覆盖率的提升。但是白盒测试用例的设计人员需要理解代码逻辑及调用关系，会编写测试代码，这会提高白盒测试的门槛。对于一般的业务测试工程师来说，这是一道难以逾越的鸿沟。

要解决黑盒测试和白盒测试的问题，同时兼有这两种测试的优点，就需要精准测试。精准测试借助一定的技术手段，通过辅助算法对传统软件测试过程进行可视化、分析与优化，使测试过程更加可视化、智能、可信和精准，从而实现测试用例和被测系统的双向追溯。精准测试的原理如图5-9所示。

其中，正向追溯指开发人员查看测试人员执行用例的代码细节，以方便进行缺陷修复。测试数据可以直接为开发人员的调试提供依据，帮助他们快速定位并修复缺陷。

逆向追溯指测试人员通过修改的源代码快速确定测试用例的范围，极大地减轻回归测试的工作量，快速修订测试用例，达到测试覆盖率最大化。通过推动精准测试的落地，我们可以帮助缩小回归范围，节省人力成本，同时防止缺少测试用例导致的漏测，前置测试，让测试工作和开发工作可以并行执行，提升项目敏捷度，缩短测试独占周期等。

精准测试也以持续交付流水线为基础，通过持续集成完成代码的构建、编译、静态扫描和测试环境部署，使用自动化测试平台完成回归测试用例的执行，通过测试监控分析，精确、详细地记录测试用例的运行过程，收集全部过程数据，进行缺陷分析、链路跟踪，建立测试用例和系统代码的映射关系，实现测试用例和系统代码的双向追溯，真正实现有所测，有所不测。

差异分析指分析两次提交的代码的变化，这主要依靠现在版本控制系统实现，目前通常使用Git。通过Git提供的diff方法，我们可以获取代码的变更，通过git diff命令可以获悉哪个文件的哪几行代码有变动，以差异小结的形式标注。

其中如果有变化，则对于删除的代码会标注减号，对于其他改动的代码会标注加号。通过这种方式，我们就可以获悉是否有代码发生变动，只要有变动，就需要通过内部映射关系推荐的回归测试用例进行回归。

代码染色是通过覆盖率监控实现的，在Java项目中覆盖率监控部分绝大部分是基于Jacoco实现的。

首先，Jacoco通过ASM字节码注入的探针标注代码是否执行过，这样就可以记录代码模块是否执行过，从而达到代码染色的目的。

然后，通过Jacoco的dump、merge、report生成测试报告。其中，dump先从Jacoco的代理中请求覆盖率的数据exec文件，然后通过merge命令将多个exec文件合并，最后通过report进行展示。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：