测试之路-精准而优雅

蔚然天空

引子这几年业内一直在做精准测试，大都使用工具diff代码改动、分析代码覆盖率这些平台集成的能力。业务测试中，我们在技术设计和代码实现的基础上也做了一些精减和精准的测试实践，通过深入测试有针对的设计case，发现隐藏问题，保证质量。接下来我将通过以下几个场景，介绍一下在toB业务中应用精减和精准的思路和实践。1.场景一：上传表格的验证需求点运营同学需要在后台使用表格模板上传多组数据，上传时需要校验表头和字段。很多数据作为QA，这不就来活了，上传校验case贴上来：问题点case中校验内容很多，每个字段的缺失、错误、格式正确性都需要验证。怎么能更好更快的测试呢？精准测试找到对应的上传功能代码：os:原来神神秘秘在那敲代码的家伙们，也和我用一样的fori和String工具类。通过走查代码发现问题：用startWith是几个意思？需求是全匹配啊！提个BUG，问题修复（startWith换成equals）：发现本次纯数字是用同样的正则和.length()>判断，测一个上传数字校验即可。这个正则（^-?\d+$）判断纯数字有问题，大家看出来了吗？精减结果正常数据的表格，上传成功。非数字格式和长度大于30的表格，分别上传失败。剩下的case通过审阅代码的方式验证。测试通过。结果：审阅代码发现了【startWith】、【正则（^-?\d+$）】两个问题。减少了case中10条上传异常表格的数据准备和操作，节省了时间。小结首先找到代码位置，练习审阅代码，可以通过接口名搜索/diff代码/开发提供找到代码。同类重复的测试场景，结合代码对case场景归类，可以适当选取重复的内容通过审阅代码进行测试。注意：当你通过审阅代码测试时，需要特别关注如【正则】、【同类型代码（复制）】和【get参数】和【需求文案】，这也是审阅而不实际验证的弊端。沉淀总结CodeReview经验，关注【判断条件】、【取值】、【公式】等经常出错的逻辑点，挖掘代码中隐藏的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查询对应数据：--手动打码SQLSELECT*fromdbzz_****.****_volume_countwhere**_id=99530and***_id=999435and**_type=2and****_idin(9999623,9999624)andperiod=14ORDERBYiddesc;通过对比页面结果和SQL查询的结果，两个维度验证数据准确性。在此分享一个本场景发现的缺陷：标记且注释置灰的位置为问题代码缺陷：获取数据时以最细规则（最长匹配）取倒序最近一条（orderbyiddesclimit1）时没有问题，但以粗粒度的宽泛条件也取倒序最近一条，则数据不全（因为表中每一条记录都是以最细粒度存储）。发现原因：之前遇到一个类似的SQL逻辑没有使用sum，所以对此格外关注。修复：条件宽泛情况下的数据应是同条件下多条记录的合集，所以应去掉条数限制并改成sum。原mapper是selectnum，修复后是selectsum(num)小结业务中复杂的参数匹配，转化成代码时实际上是个多条件SQL，思路是只要保证最细条件和部分条件都能传入并查询正确即可。在审阅代码时，关注mapper信息并结合对需求的理解，可以单独写SQL验证取值逻辑。积累业务中同类型中的BUG经验，如上面SUM的缺陷，在后续的测试中保持关注，提高警惕。总结通过分析技术设计和代码实现，可以适当分类精减case，通过CodeReview减少复杂的错误验证，转为审阅代码进行测试。通过审阅代码，从代码层面确认逻辑是否正确，比如关注字段取值、匹配入参、查询条件、判断条件、公式计算等，发现隐藏的缺陷。以上的内容举例，在测试实践中减少了重复的验证投入，有针对的设计也更有效的发现问题，最后也会让我们的测试结果更有信心。