|
本文要点 1、分布式微服务架构下的自动化测试，传统的金字塔分层测试理论是否仍然无懈可击？为什么说基于服务的接口自动化及全链路回归最具性价比？ 2、如何破解接口自动化测试及全链路回归技术门槛搞、用例准备效率低、构造数据难、链路复杂、结果校验等痛点？全链路智能测试自动生成测试场景、一键呈现全链路校验数据，自动生成测试报告，链路集成测试由2天缩短为10分钟。 3、生产流量录制回放，自动录制线上数以万计的真实场景用例数据，有效提升线下回放的测试覆盖率和充分度，用例构建1天减少到分钟级，效率提升百倍。 作者:蚂蚁集团 凤启 来源:微信公众号: 蚂蚁研发效能 出处 :mp.weixin.qq/s?__biz=MzU3NzczMDI4Ng==&mid=2247484320&idx=1&sn= 3e650dc5f2dd9a255a2a3570eaa8de59 01 前言 质量和效率，是业务研发过程中最注重的两个维度。高质量是保障业务平稳进行的绝对前提，高效是更好保障高质量地重要条件，二者不可分割。在业务飞速发展的当下、产品迭代越来越快、项目越来越多，交付周期越来越短，这给质量和测试带来了前所未有的挑战。基于经典金字塔模型分层自动化等最佳实践为解决质量和测试的挑战提供了很好的思路。 02 经典测试分层理论 金字塔分层测试的自动化，有这如下的特点 单元测试自动化可重用的测试用例 ：在相同或更改的环境下轻松地多次重用相同的测试用例，通过消除场景中的人为因素来保证准确性，以一半的预算提供更精准的结果。执行时间更少：允许“快速失败”，可以及早发现代码中的错误和故障，减少返工成本。最大的测试覆盖：可以同时运行多个复杂的测试用例，提供了比传统测试更大的覆盖范围，从而使团队可以构建更全面，更高质量的产品。具有成本效益的解决方案 ：最初投资似乎很多，但从长远来看，它以更少的体力劳动，早期的错误修复以及开发和测试人员之间的协作确保了生产成本的最小化。基于服务的接口测试自动化相对UI测试更为前置，把问题拦截在前期，降低问题修复成本。前后端分离结构，各服务之间更多的是通过接口来实现互通，对接口进行直接测试，相比Unit单元测试可以更全面的覆盖各类测试场景。性价比较高：相对来说，接口就比较稳定，入参和出参相对固定的，用例这样维护起来也比较方便。因为按接口测试，出现问题后在被测接口中排查，UI自动化：性价比最低，辛辛苦苦写好的测试用例，跑了还没几天，新的需求之后，开发把页面改了，原来定位的控件失效了，N条测试用例跑不通了。维护成本高，自动化测试脚本构造的越快，维护成本也就越大。比如一个UI节点细微的变化，可能导致自动化工具没有识别UI控件，那么所有用到这个控件的测试用例都需要更新，查找替换并且保证没有替换错就是一个很大的工作量，更别说一般录制的脚本人工都不容易理解。稳定性差，某条测试用例本地调试的时候是通的，批量执行的时候就失败了。上次跑通了，这次又失败了。。。这既有代码的问题，也有图像识别分辨率的问题。 03 我们的看法 在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试，对分层自动化测试来说，这有一定的指导意义。 UI自动化位于分层金字塔的顶层，贴近客户真实需求和业务场景的黑盒测试。但受限于各方面因素，投入了人力、物力、财力，但往往收获颇微，这更适合UI相对稳定和大量UI重复操作等场景的自动化。我们认为在UI方向的自动化测试投入应该更为慎重，主要依靠人工测试是可以接受的。Unit单元测试自动化有着白盒代码覆盖全、效率更高、返工成本更低。但由于其主要聚焦在单系统内的实现逻辑，某种意义上说离整个系统的表现、客户需求、业务场景距离仍太远。 在分布式微服务架构下，业务链路和微服务间交互尤为复杂，接口自动化天生为高复杂性的平台带来高效的缺陷监测和质量监督能力，系统越庞大接口测试的效果越明显，能有效提高测试效率，提升用户体验，降低研发成本。综合UI自动化和单元自动化两者的优势和不足，我们认为基于服务的接口自动化及全链路回归是最值得投资和投入的，所以我们推荐以下橄榄球分层模型。 03 接口自动化痛点 这里所说的接口自动化测试包含两类，一类是纯接口的验证，一类是接口场景类的测试。前者类似于用Postman之类的测试工具改改参数再下发接口，查看一下结果是否符合接口逻辑，这一类相对来讲比较简单，蚂蚁智能测试平台也有非常成熟的产品能力。后者是由接口构造一个测试场景，实际上是一种业务功能的测试，只不过由接口来衔接，这类接口自动化涉及到了业务功能的测试，往往会节省较多的测试工作量，尤其是在进行回归测试的时候。 接口场景类的测试，即使用接口来完成业务的逻辑测试，特别是全链路回归是本文主要探讨的方向，其主要的痛点如下： 链路复杂，一个支付宝的全链路可能涉及几百个系统，海量的验证点人工难以有效梳理。入参构造困难，对于下游系统来说入参有上百个，很难去模拟某一笔业务的真实的业务入参进行测试验证。资金流涉及人员多、数据确认复杂导致确认周期长。老业务回归需要金融核心层系统反复确认资金流数据。环境不稳定，重试依赖各种环境和人，难以快速发起。 例如在一个典型的支付场景中，不光链路复杂，单纯一个资金流的信息也极为庞大，涉及到大量的系统和数据交互。 04 解决思路 全链路接口智能测试的一个核心思想是采用自动化，智能化，平台化的方式去自动生成场景、一键式呈现全链路校验数据，自动生成测试报告，帮助用户快速理解业务和进行校验，并提供极致简单的测试服务。 无需编写测试脚本，将用户行为通过组件化编排，拖动组件快速生成全链路用例，不同业务场景可以自由组合执行用例，实现全链路跨系统的自动化集成测试减肥药，标准化质量执行。 通过录制线上流量，对线下环境的开发分支进行回放校验，以达到对系统比较全面的业务回归。 05 最佳实践 全链路接口测试 新建用例模板，可自由对组件、管道进行编排和设置。 生成用例，只需要在模板上填入基本信息就可以新增一个用例，然后在每个节点上可以编辑用例参数，填入自己用例的入参和用例名称。 用例执行和调度，通过实验室管理用例集，支持手动执行或定时自动执行。 测试报告和执行详情。 录制回放通过录制线上的全量数据，包括测试驱动数据，下游需要mock的数据，以及校验的基线数据，所以可以做到降低接口测试的建设成本，覆盖比较全面的场景，有效的mock，以及全面的校验 线下自动拉取线上录制数据并构造用例，免去了开发线下编写测试用例的时间和精力；自动录制线上数以万计的真实场景用例数据，有效提升了线下用例回放的测试覆盖率和充分度；用例回归更能接近线上真实环境的行为，贴近业务真实数据。 录制回放的核心逻辑主要包括以下几个部分 数据采集：无侵入的统一信息模型采集能力，在链路系统中采集全链路的必要信息（对象、db、消息），转换成统一格式日志进行打印。数据模型统一：智能测试平台经过E（extract）、T（transform）、L（load)对全链路数据进行提取加工。模型化智能推荐核验关系：智能测试平台对数据进行规则处理，把校验规则自动清洗沉淀成表-表一致性校验规则、对象-表一致性校验规则、消息-表校验一致性规则等。可扩展校验引擎：最后通过自动校验引擎，输出整体的全链路校验报告和通知，并且每个服务化能力都有统一的服务能力提供给使用方。 录制回放技术仍然面临较多挑战，需要通过技术创新不断得到解决 录制 - 全场景且最小子集：录制期望利用线上的真实流量，获取系统全量的业务场景用例集；但是同时希望用例集是没有重复用例的，对于回放来说，同样的用例不需要在线下回放两次以上。落地 - 迭代变更的适配（侧新）：之所以要进行录制回放是因为有变更，有变更就有可能对我们已经录制的数据造成影响，甚至导致大部分的用例无法在此次迭代使用，迭代变更对回放效果的影响是导致大部分团队放弃利用此方案的最主要原因之一。回放 - 不断降噪（问题排查）：因为录制用例的庞大，假设目前用例有10w左右，就算通过达到了99%以上，失败的用例也有1k左右！其中除了以上的迭代变更影响，各种噪音是影响方案最终落地的拦路虎。排除环境差异、配置差异、数据差异引起的回放数据和录制数据不一致（噪声），那么剩下的应该就是发现缺陷了。 06 落地效果 全链路接口测试 操作简单，使用方便，通过自动规则引擎，不需要人工配置任何校验规则，比以往传统的通过编写业务规则脚本效能上提升了百倍，并且通过全链路的数据串联能力，帮助我们更好分析全链路的数据，保障资金安全。网商银行、支付宝等：解决用户业务联调过程中人工触发联调效率低、结果校验易遗漏痛点问题，提供完整自动化测试解决方案，用例构建1天减少到分钟级，效率提升百倍。 结合内部开源工具，开创性地构建了无侵入录制采集框架工具，能够灵活对被测系统进行数据采集，通过大数据处理，自动分析合并业务场景，产出符合业务语义的用例场景，并通过高效回归引擎驱动，做到了亿级流量降维用例转化，自动保鲜、高效回归。 在金融核心各业务接入情况来看，自动化测试用例膨胀增长了10倍： 06 结语 全链路接口智能测试方案可以帮助开发和测试同学不再困扰于本地测试用例的编写和维护，从而专注于业务代码功能的研发；与此同时通过对线上真实流量的仿真模拟回放达到对系统更加全面的业务回归，帮助测试同学提升测试的充分度，增加测试回归的信心指数。 |
|
|
来自： 新用户0175WbuX > 《待分类》
