前 言
在之前的文章《辅助型QA转型之路》中已经初步介绍了针对运营类需求和订单相关类需求如何使用不同的测试工具提升测试效率。本篇文章主要介绍在日常业务测试过程中，面对不同的业务场景时如何进行测试场景抽离和测试手段选择，从而达到保证项目质量、提高测试效率的目的。
执行方式
1、业务场景——卖场类
业务特点：一个逻辑改动点，影响的范围比较多，如果有一个地方考虑不到很可能会出现漏测，比如服务标签，展示的地方有首页列表中、详情页的服务窗、详情页的售后服务、服务模块等。在POP项目迭代的过程中，每一期都会对服务标签进行文案属性的修改，那么如何快速测试新功能和回归呢？
解决思路：
（1）维护一套测试商品以及该商品在不同地方接口应该返回的内容作为基准版---结果A（可每次修改需求时更新该基准版结果）
（2）代码修改后重新获取一次接口返回内容—结果B
（3）结果B和结果A进行比对；比对一致则成功，比对不一致修改代码，重新进行比对
使用范围： 此工具不仅可用于QA测试&回归，也可用于开发自测兜底
实现方式： 在接口测试工程中使用testNg的dataProvider来维护基准版--结果A （已实现）或者是接口测试平台维护接口返回字段和校验点（待添加）
2、业务场景——自营已验机订单相关类
业务特点： 优品侧自营、已验机订单流程比较复杂，除了订单逻辑校验点较多之外，费用收取逻辑也是需要重点关注内容。故如何快速校验订单相关逻辑以及订单金额是需要我们重点解决的。
针对于订单费用收取部分：
其中部分业务线抽佣规则有些是在交易侧配置，而增值服务费、综合服务保障费等均在业务侧配置。故每次添加或者修改其中一个收费项时，其他业务线的各个收费项都要回归，比较耗时。如果有一个业务线的某一个收费项未覆盖到上线后就有可能出现收费错误等相关问题。
解决思路：
（1）阿波罗中维护订单抽佣、增值服务费等收费规则
（2）使用数据构造创建不同的订单
（3）根据业务侧维护的规则计算抽佣、增值服务费等--金额A
（4）根据订单号获取清结算结果--金额B；比对A与B是否一致
使用范围： 可用于rd自测兜底以及QA项目回归；同时，我们也可以定期抽检线上订单数据，对线上数据进行二次测试校验。
针对于订单逻辑校验部分：
优品侧订单验证点比较多，每个订单状态需要查看商品状态、订单的状态、库存信息等，在测试的过程中比较耗时。如在找靓机同售项目中查看商品状态需要在客户端测试平台查看找靓机商品和订单，需要查看额外的3个不同数据库中多个数据表。
解决思路：
（1）编写订单不同状态的校验规则
（2）根据订单号订单类型获取涉及到的校验点
（3）对第一步和第二步的结果进行比对；（目前只实现了第二部，具体校验逻辑还需人工参与）
使用范围： 此工具可用于QA日常测试也可用于开发自测或兜底回归
3、业务场景——跨平台需求
业务特点：由于是跨平台合作，双方交互多通过http接口，那么针对http接口我们如何保证对外提供的功能完善和健壮呢？测试手段、测试工具如何选择呢？这些是针对于此类需求我们需求思考的。
解决思路：（这里只列出来测试方案中的部分内容）
（1）提前了解开发与第三方业务交互接口的逻辑，包括涉及哪些接口、接口实现功能、接口出参入参、验签逻辑等
（2）根据接口的协议类型选择接口录入平台和接口测试工具
（3）接口测试用例设计，包括：
- 入参数合法性：入参数据类型正确性、入参是否为空、入参长度是否合法
- 功能测试：接口的功能、业务逻辑校验
- 出参：接口出参数据的正确性，错误信息的敏感信息
- 异常测试场景
（4）在提测前完成接口相关测试。由于跨平台项目对于http接口的健壮性要求很高，所以在联调前如果能完成接口相关测试的话无疑是给项目顺利联调打下了基础
（5）工具的选择上针对http协议接口优品侧目前使用的接口平台是YApi，主要基于其以下几个优点：
- YApi上维护http接口的相关参数简单快捷
- 接口分组功能较完善，便于大量接口录入的维护
- YApi对于http接口的mock使用简单快捷
- 编写验签规则使用js比较简单实现
- 接口用例可直接维护于YApi平台上便于操作执行
总结
每一个新的项目都会有它的特点，如何针对项目特点合理使用测试手段从而达到提效的目的是优品侧未来探索的方向。当针对不同的项目可以合理且高效的使用测试手段以及测试工具，同时能够有意识地把项目中通用的测试点抽离出来进行自动化，这才意味着辅助型QA的真正转型成功。
作者：许微卫
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~
