引子
这几年业内一直在做精准测试，大都使用工具 diff 代码改动、分析代码覆盖率这些平台集成的能力。
业务测试中，我们在技术设计和代码实现的基础上也做了一些精减和精准的测试实践，通过深入测试有针对的设计 case，发现隐藏问题，保证质量。
接下来我将通过以下几个场景，介绍一下在 toB 业务中应用精减和精准的思路和实践。
1.场景一：上传表格的验证
需求点
运营同学需要在后台使用表格模板上传多组数据，上传时需要校验表头和字段。
很多数据
作为 QA，这不就来活了，上传校验 case 贴上来：
问题点
case 中校验内容很多，每个字段的缺失、错误、格式正确性都需要验证。
怎么能更好更快的测试呢？
精准测试
找到对应的上传功能代码：
os: 原来神神秘秘在那敲代码的家伙们，也和我用一样的 for i 和 String 工具类。
通过走查代码发现问题：用 startWith 是几个意思？需求是全匹配啊！
提个 BUG，问题修复（startWith 换成 equals）：
发现本次纯数字是用同样的正则和 .length() > 判断，测一个上传数字校验即可。
这个正则（^-?d+$）判断纯数字有问题，大家看出来了吗？
精减结果
正常数据的表格 ，上传成功。
非数字格式和长度大于30的表格，分别上传失败。
剩下的case通过审阅代码的方式验证。
测试通过。
结果：
审阅代码发现了【startWith】、【正则（^-?d+$）】两个问题。
减少了 case 中 10 条上传异常表格的数据准备和操作，节省了时间。
小结
首先找到代码位置，练习审阅代码，可以通过接口名搜索/diff 代码/开发提供找到代码。
同类重复的测试场景，结合代码对 case 场景归类，可以适当选取重复的内容通过审阅代码进行测试。
注意：当你通过审阅代码测试时，需要特别关注如【正则】、【同类型代码（复制）】和 【get 参数】和【需求文案】，这也是审阅而不实际验证的弊端。
沉淀总结 Code Review 经验，关注【判断条件】、【取值】、【公式】等经常出错的逻辑点，挖掘代码中隐藏的 BUG。
2.场景二：获取可用规则
需求点
【获取可用规则】是匹配规则的第一部分，要根据处置优先级和启用状态命中匹配到可用规则，如下图所示：
先不展开直接本部分上 case：
问题点
匹配规则是很复杂的场景，规则本身、状态（开关）和优先级（包含同优先级）的场景很多。
完整的规则如何测试？【获取可用规则】部分就上面的两条 case ，够不够全面？
精准测试
首先了解代码获取优先级的逻辑，实际就是一个排序 SQL（优先级字段和自增 ID 字段倒序）：
拿到 SQL 返回的集合，取第一条（get0）：
通过上面的了解，我们知道状态和优先级是通过 SQL 倒序取第一条实现的，按上述 case 可以覆盖【获取可用规则】的场景：
a. 前置在库里手动插入三个规则；
b. 构造一条可以命中规则的数据；
c. 验证排序规则的结果为对应期望结果。
d. 测试完成。
保险一点，写个 SQL 再查一遍：
SQL 结果第一个（即表中 id 为 44 ）规则命中，同第 3 步 case 执行的结果一致。
小结
对自己的 case 或者测试的系统没有把握，可以通过结合代码进行测试以确保功能正确性，就不用担心这部分测试不充分啦。
在测试执行过程中，我是通过数据库 insert 的数据，这里有一个前提：case 中已经保证了页面创建的规则在库里保存正确。
当然排序和优先级还有其他的实现方式，比如【加载到内存处理】或者【给优先级的选项增加不同的权重系数】等，期望大家总结沉淀，以后遇到从容应对。
^ _ ^ ：仔细的测试同学可能已经发现，这里把【获取规则】和【规则匹配验证】拆开验证，这是拆解理顺复杂逻辑的好方式。
3.场景三：规则组匹配验证
需求点
【规则组匹配】为匹配规则的第二部分，每一行是一个规则组，规则组里可以选择配置应用 4 条‘子基本规则’（条件为且），‘子基本规则’不命中则该规则组不命中。
还是这张原型图^_^
再看一下技术设计的部分流程图：
问题点
规则匹配要测试到不同规则组命中的场景，也要测试 A1，A2，A3，A4 子规则本身的正确性。
如果要对规则组进行测试，应该设计 A1+A3，A3+A4，A1+A2+A3，A2+A3+A4，A1+A2+A3+A4……笛卡尔积全量的规则组 case 进行验证。
这样穷举出来的 case 最全，但需要的测试时间也更多，有没有更好的解决办法？
精减结果
本场景中既有规则组又有‘子规则’，先测试规则组的命中，然后对‘子规则’单独测试（场景四）
测试规则组时，根据对设计方案的理解，既然是依次排除，那无需穷举 case， 编写 case 时排除不需要测试的场景：
通过审阅代码，确认代码实现是同技术设计一致的，上面的 case 可以覆盖逻辑：
执行测试时先构造命中规则数据，然后构造排除规则的数据（图中标记的数字为库表的记录 id），查询日志进行验证:
结合页面的验证结果，真实排除了规则不匹配的规则组，测试完成。
小结
遇到功能复杂的业务场景，拆分独立的功能单独测试，往往会让测试思路更清晰，最后再做集成测试，保证功能完整性。
听完技术评审后，结合技术设计有针对的编写 case，既能避免冗余 case，又能避免覆盖率不够。
审阅代码后，通过 log 关键字查询日志和验证，确保页面结果和系统逻辑结果一致，防止黑盒测试不充分。
4.场景四：同类的规则条件
需求点：
【同类的规则条件】为匹配规则的第三部分，单个规则组内所有‘子基本规则’都命中这个规则组才命中，需要测试各‘子基本规则’的匹配逻辑。
问题：
case 初版设计（从最全匹配的 case，逐次减少一个参数，这样保证每个参数都能测试到）：
本场景问题同上一场景类似，case 设计应为笛卡尔积的子规则，但执行的场景多，有没有更精减的方式呢？
精减思路：
了解代码中获取匹配数据的逻辑，实际就是一个多 where 条件的 sql：
所以需要保证的是：最细颗粒度条件参数可以传入并查询正确，部分条件参数可查询正确，case 可以精减为：
截取部分case
测试时，通过手写 SQL 查询对应数据：
— 手动打码SQL
SELECT * from dbzz_._volume_count where
**_id=99530 and ***_id = 999435 and **_type = 2 and
****_id in (9999623,9999624) and period =14 ORDER BY id desc ;
通过对比页面结果和 SQL 查询的结果，两个维度验证数据准确性。
在此分享一个本场景发现的缺陷：标记且注释置灰的位置为问题代码
缺陷： 获取数据时以最细规则（最长匹配）取倒序最近一条（order by id desc limit 1）时没有问题，但以粗粒度的宽泛条件也取倒序最近一条，则数据不全（因为表中每一条记录都是以最细粒度存储）。
发现原因： 之前遇到一个类似的 SQL 逻辑没有使用 sum，所以对此格外关注。
修复： 条件宽泛情况下的数据应是同条件下多条记录的合集，所以应去掉条数限制并改成 sum。
原mapper是select num，修复后是select sum(num)
小结
业务中复杂的参数匹配，转化成代码时实际上是个多条件 SQL，思路是只要保证最细条件和部分条件都能传入并查询正确即可。
在审阅代码时，关注 mapper 信息并结合对需求的理解，可以单独写 SQL 验证取值逻辑。
积累业务中同类型中的 BUG 经验，如上面 SUM 的缺陷，在后续的测试中保持关注，提高警惕。
总结
通过分析技术设计和代码实现，可以适当分类精减 case，通过 Code Review 减少复杂的错误验证，转为审阅代码进行测试。
通过审阅代码，从代码层面确认逻辑是否正确，比如关注字段取值、匹配入参、查询条件、判断条件、公式计算等，发现隐藏的缺陷。
以上的内容举例，在测试实践中减少了重复的验证投入，有针对的设计也更有效的发现问题，最后也会让我们的测试结果更有信心。
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/416148.html
