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

一、背景

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

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

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

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

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

二、任务

2.1 认清精准测试

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

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

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

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

2.2 了解正向追溯

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

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

<!---->

2.3 了解逆向追溯

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

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

三、行动

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

3.1 了解精准平台架构

3.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。最终在精准平台确认了对应的入参区别，平台没有作为两个接口进行识别。

4、内部调用方法也被识别

在使用精准平台进行新增接口拉取的时候，发现平台会将一些私有方法识别出来，这些方法是内部调用，没有注册，接口测试平台也看不到对应的接口信息，无法覆盖。

3.6 最终接口确认

1、商家拆分服务

本次涉及 8 个改动接口，并补充缺少的 4 个接口的自动化之后，正常识别且状态正常，说明此服务接口都正常覆盖。 

2、商家核心服务

本次涉及 10 个接口改动，并补充缺少的接口自动化之后，对应接口都能正常识别且状态正常，说明此服务接口都正常覆盖。 

3、商家下单链路服务

本次涉及 4 个接口改动，并补充缺少的 2 个接口自动化之后，对应接口都能正常识别且状态正常，说明此服务接口都正常覆盖。 

四、结果

4.1 各个服务触发自动化结果

1、商家拆分服务

2、商家核心服务

3、商家下单链路服务

五、探索心得

5.1 总结

1. 借助于精准测试平台，发现一个开发梳理遗漏的接口，有效避免了梳理遗漏导致的测试遗漏，一定程度上规避了风险，是 QA 从经验型的主观判断向精准的数据可视化转变。

2. 借助精准平台识别出一些没有进行自动化覆盖的接口，让 QA 能针对这些清单进行接口自动化的查缺补漏，从另一层面提升了自动化用例集的完整性。

3. 精准平台与自动化平台、测试用例平台、覆盖率平台打通，从正向追溯和逆向追溯两个核心进行测试，确保数据的准确性、完整性，方便 QA 持续跟踪，提高测试效率。

5.2 优化

在接入精准测试平台的过程中，对平台有了进一步的了解，当然在使用的过程中也发现一些问题，并给开发提了相关建议，从而不断完善精准测试平台开发，也帮助 QA 更好更高效得完成质量保障工作。

本文属得物技术原创，来源于：得物技术官网

得物技术文章可以任意分享和转发，但请务必注明版权和来源：得物技术官网