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