微盟电商-以造数工厂为底座的低成本自动化应用实现（一）

微盟电商-以造数工厂为底座的低成本自动化应用实现

SAAS服务的特点是能够以同一套代码基础，服务各种使用场景的客户，由此带来的业务组合与配置的多样性是造成测试在造数环节以及自动化测试的实施阶段面临繁琐与困难的根本原因。如何确保自动化的高效实施并降低投入成本？电商测试团队从业务角度出发落地了造数工厂+自动化的组合方案。

微盟业务的特殊性

ToB与ToC电商软件业务相比，最大的区别在于可靠性要求高、配置丰富、定制化需求多。除测试环境之外，微盟还存在测试店铺的概念。不同店铺数据相互独立，配置迥异。从测试角度看，要覆盖不同的业务功能往往需要多个不同的测试店铺才能满足测试要求。众多测试店铺的维护，造数与自动化适配兼容都是前期设计时需要解决的难点。

造数先行-聚焦业务,化繁为简

相对于自动化测试，减少功能测试过程中重复的劳动，提高构造测试数据的效率显得更加迫切。这与testerhome行业调查报告中对阻碍测试进度因素与提效方向分析的一致。微盟造数工厂的初衷是希望打通业务壁垒，让构造业务前置依赖数据更简单。

微盟造数工厂与其他案例的差异化

区别于通过提供SQL，MQ的直接写入，微盟造数工厂采用了业务接口调用进行造数，这在很大程度上避免了安全风险。另一方面，这样的造数方式更贴近于业务，且符合测试的行为习惯。我们从6个维度对比了与其他方案的差异:

对以上关键特性分析：

1. 系统安全是红线，直接对数据库，MQ写入很可能会造成系统故障，数据表数据异常等不可控风险。
2. 上手难度：配置host，port，账密的这些数据并不是公开的，可能配置在Apollo中，这一步就会难倒很多测试小伙伴，且在对数据表设计不熟的情况下读写数据库，往往造成数据灾难。复杂的SQL语法，MQ的Topic，Consumer，Broker并非人人都懂，如果工具的学习成本太高势必会打击使用方的积极性。
3. 是否可用于生产环境？对数据库的直连读写在任何生产环境中都是禁止的，但是通过合法的接口调用可以创建所需数据。
4. 稍微复杂的系统数据库表都做了分库分表，一个业务模型数据涉及多张库表，甚至字段冗余，直写数据库很难确定数据应该写在库表什么位置，更难保证数据完整性。
5. 依赖数据是否可流转？例: 造数成功的商品数据能轻松被下一步构造营销活动数据时关联，或者直接用来创建订单？
6. 数据可追溯？谁在批量造数过程中触发了限流或者造数失败，甚至是发现了系统bug，都可以快速找到造数同学进行问题跟踪。

造数工厂带来的实际效率提升

假如我是负责订单的测试人员，现在需要验证拒绝买家发起虚拟商品退款售后申请，如果按照功能测试流程，至少需要完成以下步骤：

不难发现，灰色部分实际都是必要的前置流程，而我只想得到C端发起退款的售后单号。对于前置流程中的余额充值，虚拟商品创建等我并不太熟悉，会占用我极大的时间成本，预计需要10分钟。现在看下采用造数工厂带来的提升，整个造数过程在40s内即可完成：

造数工厂设计与实现的考量

1. 用户使用造数工厂的成本应该足够低，做到一键创建。

从下图中不难发现，造数的流程是串联的，前置数据可以被带入下一步造数中使用；而多数情况下订单业务同学可能只需要一个特定状态的订单，不关心下单什么商品与是否参与活动，这就需要造数工厂在后台自动完成商品创建，余额充值，加购等一系列过程，造数流程越后置，需要处理的前置流程越复杂，这对造数的兼容性与可靠性有极高的要求。

  2. 满足不同用户的造数需求。

如：商品业务测试同学在进行商品造数时，需要关心的商品选项很多，包括库存，预售方式，价格，销售渠道，规格等，而开发或者营销测试同学往往只需要一个普通商品，只关心商品类型与商品数量，太多的选项参数会产生干扰。造数选项太简陋不能满足造数需要，太复杂则影响使用体验，需要在简-繁之间寻找一个平衡。高级选项给定了常规默认值，展开/收起高级选项以满足不同角色造数需求。

  3. 数据可流转。

前置创建成功的数据可以被自动流转到后续造数流程中，让造数不再是单一的动作。

  4. 确保造数工厂不对业务服务产生影响。

1. 1. 明确造数目标环境&店铺。只允许注册到造数平台的测试店铺才支持造数。
   2. 接口限流。造数工厂对业务接口产生压力应控制在1%以内，在调用业务接口之前会先经过造数内部限流器的判断。我们使用令牌桶算法实现了的限流装饰器，支持自定义限流频率：部分查询接口在入参一致的情况下响应值在很长时间内不会发生变化，如查询店铺配置的 接口，这种接口就非常适合缓存响应值，减少对业务接口的请求次数。缓存装饰器

  如果业务接口既需要限流也可以缓存，则缓存应该先生效。

  5. 从用户反馈到主动监测。对于造数失败或者造数调用业务接口异常等问题，等待用户反馈后再沟通的成本很高且往往处理不及时，通过对造数流程中的异常进行记录并推送到企微，可以快速感知造数服务或者业务系统的异常。   

造数工厂拓展-API赋能

除却可视化页面的造数方式，微盟造数工厂也提供了90多个OpenAPI来满足多种业务数据的增删改查 。可用于辅助各团队进行自动化测试，避免重复造轮子。为防止造数接口被滥用，造数服务都需要access token验证，用户可以在登录造数工厂后通过个人信息获取专属自己的唯一Token。并携带在header中发起请求。

使用造数API相对直接调用业务API的区别:

1. 造数工厂托管了批量测试店铺，统一处理解决了业务接口的登录鉴权问题；
2. 造数工厂精简了业务接口参数，使造数请求body结构复杂度降低70+%；
3. 造数工厂避免了业务方重复造轮子，不需要担心业务接口变更导致的case异常；
4. 造数工厂内部自动处理了接口依赖，让用户只需要调用一次接口,  例：

自动化测试-高效可靠,持续集成

行业内软件测试交付流程中的情况分析

根据testerhome2023软测行业调查报告显示，只有30%公司测试的自动化率达到50%。可见测试自动化的落地效果并不可观。

不少团队对自动化测试在实际测试过程中的作用经常饱受争议，归根到底具体因素可分为：

1. 项目情况紧张：考虑到对于一些短期项目或者处于早期开发阶段的项目，需求变更频繁，自动化测试脚本可能需要频繁地进行调整，会增加额外的工作量和成本。
2. 成本与收益：自动化测试初期需要较大的人力&时间投入, 这些投入在短期内可能看不到明显的回报。
3. 技术门槛：不少公司的测试团队人数少，制约对自动化的推进，且对于自动化测试的技术栈缺少实际应用经验，难以落地。

微盟电商自动化实施过程

自动化落地必然不是一日之功，微盟电商的自动化经历了如下阶段，才稳定服务于业务迭代的回归与日常巡检。

自动化测试的本身并不具备很高的技术门槛，最需要的是深入业务抽丝剥茧，制定适应业务实际情况的结构体系，绝非生搬硬套。

构建一个良好的测试框架是自动化测试成功的关键。测试框架应该易于维护、可扩展，并且能够支持项目的长期发展。这包括合理的目录结构、代码复用、以及清晰的测试数据管理策略。以商户PC端UI自动化为例，结构可以简单表示为：

使用造数工厂完成业务流程闭环测试。单端UI自动化不能覆盖完整的业务流程，例如:验证商户端同意退货退款售后流程，需要C端发起申请与退货。可以使用造数工厂提供的接口快速完成UI测试流程。   

• CASE管理与执行。Jenkins的用例编排难度高，用例执行数据不容易落到数据库做周期性的case执行情况分析。通过自研可视化测试平台与gitlab打通，平台内置了Pytest, HttpRunner,TestNG等执行引擎，满足不同团队在平台关联用例库，可视化编排、运行测试脚本。
• CASE的防腐与治理。随着自动化case量不断增长，case的防腐化就显得至关重要。

  • 通过在case的备注中记录编写的责任人，及时跟进失败case。

  • case分支管理，feature调试通过才允许提交merge master。
  • 定时任务每天多次跑测，及时发现落后于迭代的功能，并及时适配。
  • 对于失败case标记排查后的失败原因。
  • 对执行记录数据分析：通过以上措施，在2023年，case不断增长，执行次数不断增加，整体case稳定通过率依然达到96%以上。
  • 
• 自动化测试纳入迭代发布CI流程。在灰度以及转正阶段通过DevOps的SPI通知测试平台自动触发回归任务。
• 用例模型统一，微盟测试平台(WTP)落地。

  上面的电商测试用例平台虽已经满足用例管理与执行，但由于用例依然不够直接，功能测试很难通过脚本名称定位所需case。WTP对用例模型进行统一， 从case注释中抽象出了用例标题，级别，负责人等基本字段，以及用例详情，拓展信息等其他字段，方便用户直观检索case。这里不过多介绍，WTP还会有专门的文章介绍

• 总结

  微盟电商过去的一年多时间，完成了WEB、小程序、接口自动化的落地，累计实现case达到近2500+，改善了测试同学迭代熬夜值班，手动回归的状况，明显提升了测试效率；造数工厂也已经服务于各业务线的功能测试与自动化环节。截止目前累计发现有效bug 296个，保障了业务迭代的质量。