精准测试实践

前段时间接到了一个输入法开关下发的功能，通过精准测试的理念，在测试效率和测试覆盖度上提升较大，在这里分享一下测试过程：

1、背景介绍：

由于和不同手机渠道商合作，输入法对于不同的渠道，会下发不同开关，比如vivo手机会下发vivo开关，小米手机会下发小米开关。本次改动主要对服务器的下发逻辑进行了重构。需要进行回归测试。‍

2、实现了解：

和开发具体了解了下实现，本次的改动影响范围主要是下发平台的策略。现在下发策略平台共有策略50条，每条策略类似于这样：‍

每条策略的下发是依托于用户请求服务器的参数不同而匹配不同的策略。而每条策略都是有多个单元策略组合起来了。下发结果也是单元策略下发结果的并集。

3、确定测试全集：

通过了解实现，确定测试全集为：

1、 全部策略正确性。

2、 所有单元策略正确性。‍

4、确定回归方式：

根据评估的测试全集，大体估算了下用例数：

1、50条策略，平均每条策略有3层判断。每层判断通过等价类和边界值，大约有3条case。这样每条策略有50*3*3*3=1350条case。

2、50条策略的单元策略全集覆盖了所有单元策略。所以只要保证所有策略的正确性，即可验证了所有单元策略的正确性。

如果按照传统接口测试方法。每条大约设计和执行100条case，这样要14个工作日才能回归完毕。这种回归方式显然比较耗时。

重新梳理了下，这次项目主要是开发对代码的重构，回归的重点是新代码和原有代码在策略下发上要和线上保持一致。于是想到了通过导流来减少回归工作量的方案，具体方案如下：

1、 将线上流量导到测试服务器。

2、 对比测试服务器和线上服务器的返回结果是否一致。

3、 每条请求记录命中的单元策略id组合‍。

这样跑了一天的流量后，就得到了这样的结果：每条线上请求后面跟上本条请求命中的单元策略集合。

这样的结果显然是很难分析哪些单元策略没有命中的。于是写了个脚本，统一写到数据库中，得到了这样得结果：

有了这个表格，就可以对策略id进行group by，并和策略全集进行对比，得到结果如下：

从结果中可以清晰的看出流量未覆盖的单元策略，及覆盖的单元策略每条策略的命中请求数。

5、手动设计用例：

经过统计，所有204条单元策略中，有8条策略线上流量未覆盖到。覆盖度为96.1%

有了未命中的策略id，可以针对每条单元策略的命中条件，设计相应的接口用例覆盖单元策略‍。

6、验证覆盖度：

设计完对应8条策略的case后，执行case，确认流量未覆盖的8条单元策略全部覆盖完毕，至此，保证单元策略覆盖度达到100%，此项任务测试完毕。‍

总结了一下，本次结合精准测试理念，对项目的提升如下：

整体开展精准测试的大体过程如下：

欢迎添加我们的搜狗测试微信号，与我们一起聊聊测试。