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