服务端精准测试理论及实践效果
点击箭头处“蓝色字”，关注我们哦！
服务端精准测试理论及实践效果
一
背景
我们不妨先来看如下2个场景。
场景一：
A：刚修复了一个紧急用户反馈，麻烦安排下测试
B：改动了哪些地方？影响范围？
A：改了好多地方，保险起见，还是把所有功能回归一遍吧
场景二：
C：昨天提测的功能测完了吗？
D：还在测，要跑200个用例呢
C：我就改了几行代码，怎么要测这么多呢？
相信这2个场景大家一定都不会陌生，这很好地反映了日常测试工作中的痛点。
二
日常测试工作中的痛点
开发有时不能说全所有的改动节点，或是多人开发，彼此不了解
代码洁癖，改动别人的代码
测试范围过小，遗漏
测试范围过大，代价太大
三
精准测试的引入
语句覆盖：每行代码是否都被覆盖了 判定覆盖：if...else，只需判断if和else是否都覆盖了 条件覆盖：也是if..else，但是条件覆盖相对于判定覆盖更加谨慎，需要覆盖if条件中每种情况，而不仅仅是覆盖是否执行
更进一步细化，可以维护函数内分支逻辑和测试用例的映射关系
函数A对应abc三条用例，函数B对应def三条用例，如果函数B改动则映射def三条用例
但实际上函数之间会有很多调用关系，假如函数C调用函数B，那么同时需要将函数C的用例也映射出来
同样的，变更分析也可细化到分支级别。加入函数A中if分支对应abc三条用例，else分支对应def三条用例。理论上，函数A发生变更，需要关联abcdef六条用例，但是如果能定位到是else分支发生变更，if分支无变更，那么可以只映射def分支
四
基础：建立并逐步完善知识库
最上层接口都初步维护完毕之后，可以考虑进一步细化，将已经整理的用例再拆分映射到更底层的接口甚至分支，这样做的目的是可以将每次改动对应的测试用例数量进一步精简。
三步走：评估、映射、执行
(一) 评估
主要产出为增量代码的影响面（影响接口列表），可以分为2步，首先进行增量代码diff，然后进行影响面分析，目标是完全使用工具自动化完成，如通过JGit来获取代码差异，解析到方法级别，作为调用链路推演的输入。如通过JavaParser+JavaSymbolSolver 基于静态代码得到完整的调用链路等。
目前这块效果如下图所示：
到此，关键的一步受影响的接口已经获得，有了上述的能力，我们可以知道通过哪些接口可以去测试这次改动的代码。
(二) 映射
这里就要用到公共基础里的知识库了，理想状态下，我们有了受影响的接口列表，那么就可以在知识库中自动检索出对应的测试用例，如果是自动化用例，那么就直接执行，如果是手工用例，那么就输出列表给到测试执行人员。
这块主要包含自动化用例执行和手工用例执行，与正常测试流程无异。
度量：测试精准度收集与改进
精准测试需要进行结果反馈，形成闭环，即测试精准度收集。较为直观的，就是采用测试覆盖率统计结果，针对服务器上的代码，无论是手动执行用例，还是自动化用例执行，统计变更代码的测试覆盖率，确认最终选取的测试用例，是否能真正覆盖所有变更代码范围。如果发现有覆盖遗漏，那么及时分析原因，不断调整人工评估方式或者代码扫描工具逻辑，并补充知识库，使变更必要覆盖率尽可能提高。
五
总结与展望
1.智能推荐用例
通过日常测试中的用例积累归类和覆盖率反馈的用例补漏尽快完善知识库。同时，在影响面分析关联知识库进行用例筛选的基础上，探索智能推荐用例的路线。智能推荐用例的影响参数有：线上监控，覆盖率和自动化覆盖的各种属性和特征，包括调用频次，时间分段，行业，覆盖率，是否有自动化，发布时间等等。
2.智能缺陷定位
作者介绍
蒋丰杰,质量管理中心
目前负责用户平台中心的质量保证工作，
专注于服务端测试理论研究、工具链探索和测试平台开发。