先说一组数据，0年1、双月，财经-聚合支付团队需求左移率平均69.57%（近3个双月平稳在70%左右），其中SL-L占比56.5%，即有一半的需求可以在提测前编写自动化用例，并通过自动化完成完成冒烟测试的准入工作。当然，自动化召回除了与需求左移率有关外，与需求左移程度和自动化用例质量强相关。本文将从平台支持，流程规范，过程数据收集与分析，将需求左移工作闭环。
实施路径一、建立关键指标和面板首先，我的思路是尽可能的先细化过程数据，将数据收集和分析的工作尽可能的自动化，当整体看不清楚的时候，细化可以帮助我们暴露问题，有针对性的立标杆，抓短板。
我脑海中理想的场景是精细化到需求的粒度，通过各平台数据打通，将人工用例和自动化用例以及BUG关联起来自动分析，关键设置阈值，利于我们发现问题。
在此之前，我们想统计目标场景覆盖率，需要定期梳理增量需求的目标场景用例和存量目标场景的覆盖覆盖情况，耗费大量的人力和时间。如果我们能够在需求用例设计阶段将该目标场景识别出来，打好标签，在自动化用例编写时关联好需求，就可以实现需求的人工用例和该需求用例目标场景的自动收集，并与自动化用例关联，即可实时掌握目标场景覆盖率的情况以及当某个需求的目标场景未做自动化时，给出提示，可以有针对性的补充。
Case总数：该需求关联的所有文本用例数量
目标场景数：该需求所有文本用例中识别出的目标场景数量（期望自动化覆盖的数量）
自动化Case数量：实际完成的该需求的自动化用例数量
目标场景覆盖率：自动化Case数量/目标场景数*%
（阈值可以根据实际情况设置，我这里阈值是%，当不足%时说明原因。比如1个自动化case中可能包含个人工用例，但实际已经覆盖，或者当前不满自动化条件，还无法覆盖，后期待满足条件时补充，也方便跟踪）
Case左移动占比：评价自动化左移程度，自动化Case数量/Case总数*%，与自动化召回率相关
（阈值可以根据实际情况设置，我这里阈值是60%，期望人工用例中60%的用例可以自动化覆盖）
服务端BUG总数：该需求发现的server端BUG总数
自动化BUG数量：该需求自动化手段发现的server端BUG数量
自动化召回率：自动化BUG数量/服务端BUG总数*%
二、数据的自动收集与分析数据源：API形式对接Bis需求管理平台、Bis缺陷管理平台，Bis用例管理平台
工具选型上，用例管理工具使用公司的BIS用例管理平台，使用思维导图维护用例。
通过打标签的方式识别该文本用例中需要统计的节点。
case：表示该节点是1条有效用例
目标场景：表示该节点是目标场景（前提该节点必须标记case）
自动化：表示该节点完成自动化，子节点是自动化caseid（在TBOX平台实际编写用例后维护，主要用于人工用例和自动化用例的关系维护）
将用例与需求关联，用于通过API接口获取该需求的人工用例。
通过定时任务，每日获取Bis需求管理平台的需求列表，以及需求关联的用例节点，根据标签识别每个需求的文本用例数，目标场景数。需求关联的缺陷列表数据分析缺陷信息。
编写自动化用例时，与需求关联，即可实时获取需求关联的自动化用例数。将生成的caseid补充到文本用例中即可。（如果不需要文本用例和自动化用例的一一对应，可不用维护到文本用例，简化操作）
每周运营
转载请注明：http://www.0431gb208.com/sjsbszl/405.html
