“精准测试”在商家地址专项的探索-51CTO.COM

在商家地址专项测试中结合现有精准测试平台，以STAR模式介绍精准测试探索与实践。

1、背景

随着公司业务的不断迭代发展，业务架构越来越复杂，测试亟需优化以下几个方面：

（1）应用随业务发展在不断扩展，各个应用代码复杂度会不断增加，如何准确、全面判定代码修改影响范围会越来越重要；

（2）测试过程中会发现只是自身应用代码一个修改，会导致对外暴露的接口逻辑发生很大变动，此时测试人员需要判定出这个对外暴露的接口对上层应用到底有多大影响；

（3）业务快速迭代导致测试时间不断压缩，全量回归是一个很困难的事情，那么测试范围需要开发测试人员根据代码和业务熟悉程度精确把控，风险不可控。

基于上述背景，QA可以将精准测试作为应用上线质量的参考维度之一，有效辅助日常迭代测试工作，提高测试效率。

2、任务

2.1 认清精准测试

精准测试是基于源代码变更分析，结合一些分析算法，从而确定改动代码影响的范围，设计测试用例进行针对性测试，一方面可以提升测试效率，另一方面精准测试还可以将测试用例与程序代码之间的逻辑映射关系建立起来，而这个过程则是通过工具去采集测试过程执行的代码逻辑及测试数据。这两个点也正是精准测试的核心：正向追溯和逆向追溯。

所以，要想做好精准测试，核心目标可以总结为以下两点：

（1）质量的评估不再完全靠个人经验和业务熟悉度，而是通过精准的数据。在测试资源有限的前提下，将用例精简到更加有针对性，提高测试效率，有效的减少漏测风险。

（2）代码覆盖率的可衡量性，提升测试质量，同时帮助开发定位缺陷对应的代码执行逻辑，提升缺陷修复效率。

2.2 了解正向追溯

所谓正向溯源，就是解决开发处理bug的盲目性、QA测试覆盖率的可衡量性。通过精准测试可以分析出哪些代码被覆盖到，哪些代码没有被覆盖，从而统计测试覆盖率，通过代码覆盖率，找出漏测的地方，可以更精准的进行验证，减少重复工作。精准测试的运用是从经验型的主观判断向精准的数据可视化转变，让质量的把控减少了一些不确定性、不可控性。

在用例执行过程中，开发也可以看到QA执行用例的代码细节。从而追溯到调用具体方法与实现类，可直接在代码级定位测试执行的代码缺陷逻辑，并提供最后运行的时序数据。也可以更快地定位缺陷对应的代码执行逻辑，帮助开发人员快速修复缺陷，可追踪难复现缺陷。

2.3 了解逆向追溯

所谓逆向追溯，就是解决QA要测什么的问题，实现了代码变更的影响面评估，分析识别增量与变更代码。QA通过精准测试对影响的代码做准确的针对性测试，回归的范围更准确，避免了全量回归造成测试资源的浪费，既保证了质量又缩短了版本的迭代周期。

在日常的迭代回归测试中极大减少回归测试的盲目性和工作量，释放人力成本，将更多的时间和成本投入到更深更复杂的测试工作中，减少资源浪费。

3、行动

基于精准测试的两大核心目标，QA可以通过正向溯源和逆向追溯进行精准测试探索。下面就借助精准测试平台以商家地址专项这个项目进行精准测试实践。

3.1 了解精准平台架构

3.2 精准平台接入计划

迭代	需求	涉及服务	接口数量
512-513迭代	商家地址专项-地址监控	商家核心服务、商家下单链路服务、商家拆分服务	22
514迭代	商家地址专项-接口新增	商家拆分服务	2

3.3 开发梳理改动接口清单

从开发梳理的改动清单中，可以看到，本次商家地址涉及的改动的接口包含三个服务：商家下单链路服务（4个）、商家核心服务（8个）、商家拆分服务（10），总的接口数量为22个。

单从开发的技术方案上梳理的涉及接口清单上看，QA无法判断是否有接口遗漏或者错误，按照以往的测试策略，QA只能针对这22个接口进行相应的测试。

但是有了精准测试平台之后，QA可以先针对这三个服务在提测分支和线上master进行对比，识别出有变动的接口数量，可以初步确认测试范围。

3.4 精准平台拉取接口清单

精准平台地址：https://ep.shizhuang-inc.com/precision/center/recommend

（1）商家下单链路服务

从平台拉取的结果来看，当前提测分支feature-address-513_monitor分支跟master分支对比，涉及到4个接口的改动，其中2个接口完成自动化，2个接口没有相关自动化。

对比开发梳理的商家下单链路服务改动接口清单和平台拉取的接口清单，可以看出商家下单链路服务改动接口以及数量是完全吻合的，这无疑给了QA莫大的信心。

（2）商家拆分服务

从平台拉取的结果来看，当前提测分支feature-address-513_monitor分支跟master分支对比，涉及到8个接口，4个接口完成自动化，4个接口没有相关自动化。

对比开发梳理的商家拆分服务改动接口清单和平台拉取的接口清单，可以看出商家拆分服务改动接口以及数量也是完全吻合的，只是存在部分接口没有自动化覆盖，需要后期补充对应的接口自动化进行覆盖。

（3）商家核心服务

从平台拉取的结果来看，当前提测分支feature-address-513_monitor分支跟master分支对比，涉及到11个接口，且均没有相关自动化。

对比开发梳理的商家核心服务改动接口清单和平台拉取的接口清单，可以看出商家核心服务改动接口数量比开发梳理的接口多一个，并且有一个接口没在开发的方案当中，说明该服务需要进行具体分析。

3.5 具体分析发现问题

（1）接口遗漏

通过精准平台确认通过商家用户id查询退货地址接口也存在对应的改动，开发少梳理了一个，并同步开发在清单中进行补充。

（2）代码分支合并

商家核心服务识别出了一个非地址相关的改动，跟开发确认之后发现是因为当前提测分支没有合并当前线上最新的master分支，导致跑出了非地址相关的功能数据。告知开发进行对应代码合并之后，QA需要重新部署重新拉取接口再次确认。

（3）接口重载

商家核心服务有一个重载方法精准平台没有识别出这个根据商家id查询商家地址的接口，跟开发进行确认，最终结论是根据商家id查询商家地址的V2接口是重载了以下接口：平台没有看到重载的方法名，最终确认重载方法还是原来的方法名，只是在入参上作区分，一个只有商家ID，一个需要传商家ID、订单类型、商品ID。最终在精准平台确认了对应的入参区别，平台没有作为两个接口进行识别。