自动化左移实战

见贤思齐

背景先说一组数据，2022年1、2双月，财经-聚合支付团队需求左移率平均69.57%（近3个双月平稳在70%左右），其中SL-L2占比56.25%，即有一半的需求可以在提测前编写自动化用例，并通过自动化完成完成冒烟测试的准入工作。当然，自动化召回除了与需求左移率有关外，与需求左移程度和自动化用例质量强相关。本文将从平台支持，流程规范，过程数据收集与分析，将需求左移工作闭环。实施路径一、建立关键指标和面板首先，我的思路是尽可能的先细化过程数据，将数据收集和分析的工作尽可能的自动化，当整体看不清楚的时候，细化可以帮助我们暴露问题，有针对性的立标杆，抓短板。我脑海中理想的场景是精细化到需求的粒度，通过各平台数据打通，将人工用例和自动化用例以及BUG关联起来自动分析，关键设置阈值，利于我们发现问题。在此之前，我们想统计目标场景覆盖率，需要定期梳理增量需求的目标场景用例和存量目标场景的覆盖覆盖情况，耗费大量的人力和时间。如果我们能够在需求用例设计阶段将该目标场景识别出来，打好标签，在自动化用例编写时关联好需求，就可以实现需求的人工用例和该需求用例目标场景的自动收集，并与自动化用例关联，即可实时掌握目标场景覆盖率的情况以及当某个需求的目标场景未做自动化时，给出提示，可以有针对性的补充。【需求左移面板】【关键指标】Case总数：该需求关联的所有文本用例数量目标场景数：该需求所有文本用例中识别出的目标场景数量（期望自动化覆盖的数量）自动化Case数量：实际完成的该需求的自动化用例数量目标场景覆盖率：自动化Case数量/目标场景数*100%（阈值可以根据实际情况设置，我这里阈值是100%，当不足100%时说明原因。比如1个自动化case中可能包含2个人工用例，但实际已经覆盖，或者当前不满自动化条件，还无法覆盖，后期待满足条件时补充，也方便跟踪）Case左移动占比：评价自动化左移程度，自动化Case数量/Case总数*100%，与自动化召回率相关（阈值可以根据实际情况设置，我这里阈值是60%，期望人工用例中60%的用例可以自动化覆盖）服务端BUG总数：该需求发现的server端BUG总数自动化BUG数量：该需求自动化手段发现的server端BUG数量自动化召回率：自动化BUG数量/服务端BUG总数*100%二、数据的自动收集与分析数据源：API形式对接Bis需求管理平台、Bis缺陷管理平台，Bis用例管理平台工具选型上，用例管理工具使用公司的BIS用例管理平台，使用思维导图维护用例。通过打标签的方式识别该文本用例中需要统计的节点。case ：表示该节点是1条有效用例目标场景：表示该节点是目标场景（前提该节点必须标记case）自动化：表示该节点完成自动化，子节点是自动化caseid（在TBOX平台实际编写用例后维护，主要用于人工用例和自动化用例的关系维护）将用例与需求关联，用于通过API接口获取该需求的人工用例。通过定时任务，每日获取Bis需求管理平台的需求列表，以及需求关联的用例节点，根据标签识别 每个需求的文本用例数，目标场景数。需求关联的缺陷列表数据分析缺陷信息。编写自动化用例时，与需求关联，即可实时获取需求关联的自动化用例数。将生成的caseid补充到文本用例中即可。（如果不需要文本用例和自动化用例的一一对应，可不用维护到文本用例，简化操作）每周运营关注哪些需求左移程度低，自动化程度低，自动化召回率低，暂时无法自动化的原因，当满足条件时，可以及时补充，避免遗忘。三、运营过程相信大家在自动化运营过程中也许也遇到过这些困扰：1、新需求的代码变动对已有用例有影响，无论是接口变动或者断言变动，都需要修改已有用例，什么阶段发现合适？什么阶段修改合适？既要能够不影响目前上线流水线正常运行，也能够在新需求上线后，立即兼容新的逻辑和断言；2、需求迭代快，很难找到存量自动化用例不断迭代，为了方便，不断新建自动化用例，历史用例缺少维护，逐渐失效；3、自动化用例在需求的不断演进中，很难追溯历史版本；4、多个QA测试同一个需求，同步编写自动化用例时，很难协同复用，容易冲突。【自动化Case管理流程图】【解读】1、在需求左移前，先在feature环境运行基线Case，两个目的：验证是否存在BUG；新需求是否对存量自动化有影响，以免功能上线后导致存量Case失败，影响自动化稳定性；2、如果新需求对存量自动化用例有影响或者新需求可以复用存量用例，基于存量用例的修改步骤，参数，检查点即可快速生产新用例，我们均采用复制的方式创建用例，基于现有Case复制一个新的Case并关联到新的需求上；3、无论是复制创建的Case或是新增创建的Case，都关联到新需求，并在feature环境执行通过；4、当分支测试通过后，代码合并入master,需要基于master代码在prod环境运行通过，此时会自动触发 将这部分需求从隔离区移入稳定区的基线Case.(PS:没看过之前文章的，在简单介绍下机制：创建用例时，该用例处在隔离区（目的是代码上线前避免影响流水线基线执行，当在prod执行通过后，自动移入隔离区的基线Case）)；5、根据实际情况选择是否废弃 原有Case；6、在prod执行基线Case作为准出。四、实战接下来，以正在需求左移中的《普通担保支付支持垫资退款》需求为案例进行分享。1、什么时间点开始需求左移合适？在需求评审和技术评审结束后，开始编写文本用例，在RD开发尾声组织用例评审，并在评审时给出冒烟测试范围（如图，打标签【冒烟测试】），从此刻开始进入自动化编写阶段。2、需求左移的顺序如何把控？进入左移阶段后，优先完善冒烟测试范围的自动化Case，在逐步完善其他目标场景的自动化Case。以便于在RD联调时，将冒烟自动化Case给到RD，减轻RD构造测试用例的成本。其余目标场景自动化Case用于提高测试阶段的效率。3、自动化需要具备那些必要条件接口变动说明本次需求涉及到的被测接口的范围和变动，入参和出参，提供分支名，导入后可获取到最新的接口测试场景是否mock支撑目前我们是通过bytemock平台维护mock，在平台配置mock和对应的mockTag，通过接口base传递mockTag控制接口使用该mock规则，从而控制接口的返回和状态机"Base": { "LogID": "", "Caller": "caijing.tp.paycore", "Addr": "fdbd:dc02:ff:1:1:174:237:86", "Client": "", "TrafficEnv": null, "Extra": { "byted-trace-id": "113f5aa3d7ace2145be64dd8e589f63f:609e30fd18e752a5:519a1f5b5356b100:1", "bytedctx-_sr": "1", "cluster": "default", "env": "prod", "user_extra": "{\"RPC_PERSIST_MOCK_TAG\":\"ad_f\"}" } }质量决定要左移自动化质量首先，TBOX自动化平台支持测试场景的随意编排，步骤间参数可以随意传递，支持接口，数据库，回调的请求与校验。在编排自动化场景时尽可能兼容所有场景，所以步骤会冗余。但是没关系，为了减少自动化用例的编写成本，根据该Case的实际需要，选择需要的步骤即可，只有配置该步骤的入参和断言才会执行，否则跳过次步骤。这条用例我们进行【下单】-【下单查询检查订单状态】-【结算】-【结算结果检查】-【微信普通担保分账后原路退款成功】-【退款数据库检查】-【极速退shop_platform回补失败】-【退款数据库检查】-【退款查询】确保跟人工测试检查点一致。冒烟测试自动化提供给RD进行冒烟测试，最终以执行成功的测试报告作为冒烟测试通过标准，省去现场验收冒烟测试的时间。写在最后在开展自动化左移后，不同角色在其中都获得了收益，其中联调阶段发现缺陷数提升。对于RD来说，我们将冒烟测试用例编写自动化后提前给到开发，开发在联调阶段就能提前发现问题；对测试同学来说，测试过程更顺利，降低修复缺陷后，多次回归的成本。