玩转手工测试之百度客户端产品手工测试提效实践
一、手工测试的主要挑战
首先我们来看一下百度内部大型app手工测试的主要挑战：
1、超复杂业务场景：随着各种应用的层出不穷和软件需求的不断迭代，软件系统内部逻辑越来越复杂，而外部操作会越来越“傻瓜”；通过传统的手工黑盒测试很难进行所有的逻辑覆盖，为此，需要极高的人力投入才能完成复杂逻辑的用例分析和设计，即使如此应用也会时刻携带隐形的巨大质量风险；
2、高频迭代发布诉求：百度内部的产品呈现出高频迭代的趋势，需求方希望尽早地看到结果，并给予及时反馈，所以技术团队需要用“小步快跑”的姿势来做产品，尽早地交付新版本；因此很多大型APP逐步切换到单周/双周发布模式，对于测试来说没有固定的回归测试时间，要求开发完成后立即完成测试；
3、测试/开发比例增高：手工测试都是人工进行的，它依赖的是人的算力，而随着人力比的增高，以及软件正确性验证的工作量，主要是组合路径膨胀的问题，人的算力是远远跟不上的；低效的手工测试，成为影响业务迭代的主要瓶颈；
超复杂的测试场景，高频的发布需求，超高的测试/开发比例，迫使传统的手工测试模式必须向智能化转型，来解决效能瓶颈问题。
对于手工测试来讲主要需要解决三个部分的问题：
第一步：测试输入，如何快速生成标准且全面的测试用例—产生结构化的用例数据；
第二步：测试执行，如何快速识别风险精准的选择用例执行—利用数据+算法指导测试行为；
第三步：测试分析，如何评估项目质量提升召回能力—通过风险评估进一步召回可能忽略的风险。
二、手工测试模式重建
基于以上问题，我们需要使用标准化和智能化的思路来重建手工测试，从根本上引手工测试从经验型方法向技术型方法的转型，实现提质增效的目的；
测试输入：标准化 -- 用例管理平台，快速生成标准化用例数据； 测试执行：智能化 -- 精准测试系统，智能用例推荐； 测试分析：智能化 -- 质量风险评估模型，自动感知风险； 循环转化：数字化 -- 历史数据积累，转化新的推荐&评估策略；
为了实现与测试场景的结合，需要从需求评审到项目发布，多个环节进行了标准化，自动化，智能化的交付模式改造：
需求评审后，可以通过需求卡片一键跳转用例管理平台进行用例编写，同时实现用例和需求的自动关联； 编写完成用例后，用例管理平台根据需求所属的版本进行自动归档； 研发同学开发完成提交代码后，根据story自动推荐自测用例；研发同学根据推荐的用例进行自测签章； 随后进入story测试阶段，测试同学根据签章情况进行验收测试； 集成测试阶段，根据代码风险进行回归用例精准推荐； 从story测试到版本发布，质量度模型根据各个阶段的风险引入和风险移除情况，自动输出评估报告，提前感知项目风险。
以上介绍的流程主要涉及两块，基于脑图的用例管理平台和基于白盒技术的智能测试平台；下面会对这两部分展开详细的介绍。
三、基于脑图的用例管理方案
3.1 总体设计
基于脑图用例的管理平台方案的设计思路，有三个关键词，分别是标准化，自动化和智能化；
标准化：建立标准用例管理方案，对用例完整生命周期进行标准管控；平台支持用例模板，分支复用，协同编辑等能力也可以实现快速的产出标准化的用例数据； 自动化：从需求建立到上线，建设完整的大前端迭代流程自动流转机制；支持自动提测判断，智能签章过滤，自动模板填充，回归用例生成，用例智能淘汰和状态自动流转等多种能力实现全流程自动运转； 智能化：让数据、算法做流程和测试行为的决策，为手工测试提质增效；智能化目前具备的能力包括，实时代码染色，用例智能推荐，风险智能评估等；
3.2 用例生命周期管理
现在我们针对用例管理平台的核心能力，用例生命周期管理做详细的介绍；用例管理平台制订了用例生命周期自动流转的机制，实现case标准化输出，流程自动化判断，测试智能化指导的管理模式。
首先，制订了从用例新建到用例淘汰全生命周期的用例流转方案；通过用例模板，用例复用，协同编辑等能力可以快速完成标准化用例数据的新建；在用例执行过程中，可以根据影响面进行用例推荐，执行用例使同步完成在线签章，提测状态的自动更新；用例分析环节，可以自动根据用例的优先级，执行记录，揭错能力，覆盖能力进行用例的优选和用例的淘汰处理。
另外，刻画了story用例集合，回归用例集合，冒烟用例结合，执行用例集合和淘汰用例集合的管理机制，实现用例生命周期和业务用例集合的对应，快速实现业务场景的适配落地。
同时，我们保障了脑图用例平台的编辑体验和本地xmind做到完全的一致；在不增加业务成本的情况下，实现线上化的用例管理能力。
通过脑图用例管理平台的用例生命周期管理能力，沉淀用例模板高效复用，提升用例编写速度；生命周期自留转能力，降低用例维护成本；产出标准化的用例数据，为后续智能化决策提供数据支持。
3.3 一站式流程管控
用例管理平台第二个核心能力就是实现了一站式的流程管控能力；以用例数据为起点，规范项目流程，打通研发流程各个平台，实现了状态自动流转，数据自动关联；以用例数据为支撑，输出用例状态及数据查询的能力，协同各平台进行项目高效流转。
首先，实现了用例管理平台和全流程平台的打通，通过一系列的插件和脚本，实现了用例数据和全流程平台数据的关联；有了全流程的关联数据，就可以进行迭代状态的自动的判断和流转；随后，制订了开发提测到测试发版整个流程的自运转机制，从需求开始，通过需求管理平台可以一键跳转用例管理平台进行用例设计，同时实现了需求和用例的关联；研发进行代码提交后，可以实现代码，用例和需求得关联，有了这部分数据后持续集成流水线就可以实现为研发自动推荐自测case；提测平台根据签章情况进行提测判断；成功后，联调平台根据联调用例进行联调判断，最后进入自动化测试平台针对变更执行自动的测试活动，执行通过后，发版平台根据全流程得数据特征判断是否可以发布；具体流程如下图所示：
脑图用例管理平台的全流程自流转能力，解决了项目流程约束靠口头沟通，手工操作，难协同，效果差的一系列问题；实现了迭代过程透明可靠地运转。
3.4 收益情况
业务规模：
使用规模：公司级首个脑图用例管理平台，接入100+业务线，服务用户1w+； 数据规模：累计迭代用例100W+，签章率60%；
流程支撑：
新手工测试交付模式：规范项目流程，状态自动流转；用例智能管理，降低维护成本；产出标准化数据，赋能智能测试； 全流程数据打通关联：从需求到上线，实现10+环节全流程数据关联，提供40个纬度数据分析服务；
四、基于白盒技术的智能测试方案
手工测试模式重建中，第二个关键组成部分-基于白盒技术的智能测试方案；该方案的主要目标为：用例智能推荐，质量自动评估，全流程客观数据指导。
整个智能测试系统的架构如下：
第一部分：利用前置编译器，对被测试应用程序源码静态结构进行分析，并实现源码插桩；然后将处理好的应用程序放入测试环境运行，测试工程师通过手工或自动化的方式执行测试用例，精准测试系统进行高速智能运算，实时生成用例和代码的双向回溯数据；
第二部分：根据代码的变更情况，利用用例和代码双向回溯数据，结合业务需求使用不同的推荐策略进行回归用例的智能选取，有效的提升测试效率；
第三部分：通过全流程采集的数据分析，结合风险引入和风险移出等多纬度指标数据，综合判断项目风险，给出合理的测试指导，降低badcase的发生，提升召回能力；
在整个过程中，用例和代码的双向回溯是一切分析的基础，但是随着版本代码的更新，回溯数据需要进行及时的更新，由于手工更新会耗费大量的人工成本，因此我们设计了代码diff分析工具，自动生成更新数据，降低重复录制的成本。
结合以上分析，我们整个智能测试系统由四个关键工具组成：
用例录制工具（生成用例和代码的映射库） 用例推荐工具（根据代码风险和业务需求进行用例选择） 质量评估工具（提供质量风险的评估能力，降低badcase） 代码diff分析工具（通过代码变更检测能力，进行录制和推荐case的判断）；
下面对四个工具进行详细的介绍：
4.1 用例录制工具
用例录制工具的主要功能是对APP进行插桩，支持自动或手工的形式进行用例录制并采集用例和代码之间的映射关系；目前用例录制工具支持java，kotlin，oc，swift，flutter等NA端主流语言；Android端采用jacoco离线插桩，iOS端采用IR插桩。
用例录制工具的操作流程如下：首先需要对APP进行插桩，然后在前端页面选择需要录制的测试集，选择安装了插桩包的测试设备，然后打开录制开关，执行用例步骤后，关闭录制开关；客户端会自动上报覆盖率文件（ec，gcda）到服务端，服务端针对不同的端类型采取不同的解析方案，最后解析为”包名-类名-方法名-参数列表”的形式进行存储；至此就实现了用例和代码的双向映射。
用例和代码的映射库是整个精准推荐的基础，数据的准确性非常重要；因此我们建设了全面的录制和校验规范，保障数据的精准。
4.2 用例推荐工具
用例推荐工具，支持多种推荐策略，适配不用业务需求；支持用例权重排序，高风险用例高优执行；回归case自动分配，降低维护成本。
用例推荐流程如下：流水线自动获取变更代码信息，然后业务线根据不同的业务诉求，选择推荐策略，平台自动进行用例推荐；推荐的用例针对人员匹配度，人均执行用例数进行分配，每个同学会收到一个需要执行回归用例的列表。
整套精准推荐方案上线一年左右，为了适配不同的业务诉求持续降低推荐比，我们不断推进用例推荐策略的迭代；一共经历了三个时期，权重排序--相关性推荐—风险推荐；共计孵化了四个推荐策略：用例排序，用例优选，最大覆盖率和底层方法过滤。
用例排序：根据用例的风险权重进行用例排序，按照排序结果进行用例执行，将风险最高的用例前置；用例排序主要解决是bug总是在回归测最后一刻发现，导致修复bug的风险非常高的问题，做到风险前置。 用例优选：从排序中优选出和本次变更代码相关的用例，减少用例执行的重复度；用例优选策略，解决每次发版都要对全部用例进行回归的问题，实现只进行修改代码相关用例的测试，用例执行更加精准高效。 最大覆盖率：在优选用例的基础上，保障覆盖率不降低的情况下，对用例进行选择，筛选掉完全被包含的用例；例如用例A完全包含用例B，那么使用最大覆盖率策略，会把用例B进行剔除，进一步压缩推荐比；最大覆盖率策略保证最小用例集合完成最高的代码覆盖。 底层方法过滤：在优选用例的基础上，通过用例变更和公共方法集合的包含关系进行用例选择；主要应用场景举例，例如一个底层网络库方法的修改，如果按照相关性推荐会推荐出几乎所有的用例，但是使用底层方法推荐，只是对这个底层方向选择高覆盖高风险的几个用例进行覆盖。
业务线可以根据自己的版本节奏，对质量的要求以及改动范围进行不同推荐策略的选择。
目前正在进行基于风险推荐的探索，针对代码风险进行用例推荐；期望能达到仅把存在bug的用例进行推荐，将推荐比降到最低，提升测试效率。
4.3 质量风险评估工具
为避免整个智能推荐过程中的badcase发生，我们孵化了质量风险评估工具，主要是从风险引入和风险移除角度进行评估；通过智能评估能力决策流程流转，实现测试人力自动分配，bug前置召回，交付流程无人值守，保质提效。
通过智能风险评估工具的上线，整套智能测试系统实现：测试前，识别风险进行测试活动和测试用的推荐；测试中，定向风险执行，前置拦截；测试后，决策风险，给出流转建议。
目前大前端的质量评估模型涵盖需求准入，需求准出，集成准入，集成准出，版本准出等过个全流程环节的评估能力。
五、代码diff分析工具
代码diff分析工具主要是通过代码特征识别，工程特性分析以及函数调用链分析能力，对代码变更进行检测，针对不同级别的变更，执行不同的推荐或录制策略；以实现推荐用例更加精准，用例录制成本降低的目的。
代码变更检测会针对例如增加空行，更换函数位置，try-catch容错，判空处理等场景不需要进行用例推荐和录制的函数进行识别；在推荐和录制场景剔除，节约执行和录制成本。
5.1 “手自一体”的高效解决方案：
百度内部很多业务都积累了大量的自动化测试用例集，而启动一次全量的自动化测试触发，使之大比率通过，非常困难。QA同学常常需要投入很高的成本，把大量精力花在自动化用例失败排查上面，然而有效发现 BUG 的概率依然很低。在反复排查无果、心神俱疲的情况下，很多业务几乎对自动化产生绝望之心，视之为鸡肋，用之无用，弃之可惜，十分头疼。
如何让自动化用例发挥它们应有的效用，让 QA 工作不那么沉重呢？针对这一问题， 进行了手工精准测试与自动化测试无缝对接；通过自动化手段降低测试执行成本和用例录制成本。
主要过程如下，新的版本发布前，根据代码变更进行回归分析，精准测试系统进行用例推荐，推荐的用例如果被自动化覆盖，自动触发自动化平台执行；执行过程中自动采集更新用例和代码的映射关系。
通过自动化手段降低用例执行成本的方案很简单也容易理解，这里就不在赘述了；降低录制成本方面，我们制定了较为详细的方案，下面给大家详细介绍一下。
精准测试的准确性依赖于用例和代码映射关系的准确，因此需要在版本有代码更新后，要持续更新用例和代码的映射关系；每个版本都进行更新，整个录制成本是非常高的，因此我们制订了用例录制成本降低的方案。
刻画了用例录制漏斗，对于需要录制的用例集合，先经过代码diff分析工具的调用链分析能力，自动完成代码调用关系的更新；自动更新集合的用例经过自动化平台的自动化录制；自动录制集合在通过代码diff分析工具的代码变更级别判断，将无需录制的用例剔除；最后剩余的用例流转到手工录制用例集合（大概30%），可以降低录制成本。
5.2 智能测试的收益情况
迭代周期：两个月1个版本两周1个版本单周发布 回归人天：15人天7人天3人天1人天 用例推荐比：用例推荐比大版本稳定在30%，小版本稳定在10%以内 迭代模式的改变：客户端精准测试体系贯穿从需求评审到项目上线整个软件测试生命周期及迭代的各个阶段，取得质效收益；根据不同的质量要求，优先级顺序、技术实现手段等，实现智能灵活的技术方案推荐、交付和应变机制；通过与自动化平台的结合，最大化发挥自动化用例效力的同时，落地了手自一体的高效方案，降低推荐比和录制成本；
六、落地实践案例
通过上面的介绍，对于使用用例管理平台进行用例标准化管理和项目流程规范化管控，以及智能测试的实现思路有一定的了解；但是这套东西是如何应用于业务，为业务带来质效提升的呢，下面我们通过两个案例来详细介绍。
6.1 大型APP，单周发布实践
百度内部越来越多的业务，推行了单周发版迭代模式；主要变更点是由之前的每四周发一版改为每周都能发布。
单周发布的模式下，对于RD最大的痛点是从串行开发的模式，变为并行开发模式（班车模式）；这也大大提高了开发过程中的分支管理成本，如何规范化管理分支，降低分支冲突，把控代码质量是需要解决的重点；因此需要对分支管理进行规范和优化以适配班车模式的开展。
单周发布模式下，对测试最大的痛点是原有测试模式，回归测试全人力投入，无法投入下版本新功能测试，导致班车模式无法开展；因此通过端中台技术驱动测试模式改进，从用例编写，提测准入，兼容测试，集成测试，回归测试全流程提效。
在整个迭代流程中，用例管理平台在用例编写阶段，通过用例模板复用，提供了快速的用例生成能力；在提测阶段，提供了便捷的用例签章和状态自动流转能力；在集成测试阶段，智能测试系统提供了用例推荐和自动回归能力；并且通过全流程数据的积累和分析，可以提供测试指导和风险评估能力
6.2 SDK项目，测试效率提升
SDK形态的业务，每次升级都要集成到多个宿主重复进行全部功能的回归，工作量非常庞大，严重影响测试效率；例如SDK的核心功能有1000条用例，该SDK集成5个宿主，那么原有方案要回归5000条用例；因此我们需要通过智能化的思路对SDK项目进行改造，解决SDK的测试效能瓶颈问题。
SDK的智能测试解决方案是对功能变动范围进行判断，针对不同的变动，采用不同的处理逻辑；主要方案是通过宿主端能力抽象，进行宿主能力的自动化校验，解决多宿主依赖的问题；通过SDK精准测试的落地，解决所有用例都进行回归的问题；针对特殊场景的case进行推荐策略升级，防止badcase的发生。
SDK的升级场景有主要有三类：
SDK内部功能改动：这类场景主要是宿主没有任何变动，仅对SDK进行配置升级；针对这种场景的升级，可直接通过SDK精准测试推荐能力，进行回归用例选择，提升回归效率； SDK+宿主都有改动：这类是最普遍存在的场景，SDK和宿主都有改动；需要除了sdk用例的精准推荐外，对于变动的宿主还要进行端能力的自动校验；提升回归效率的同时，保障召回效果； 宿主内部功能变动：这类场景是SDK无新功能，单宿主有业务升级；主要进行宿主能力的自动检验回归即可；
七、总结
回顾一下，这篇文章从手工测试的痛点问题出发，阐述了手工测试模式重建的思路及方案；并对该方案中两个重点能力基于脑图的用例管理平台和基于白盒技术的智能测试中台展开详细的介绍；最后使用两个案例解释了在不同业务场景下的落地过程；当前该套方案已应用于百度各大业务线的迭代流程中，根据不同的质量要求，优先级顺序，技术实现手段等，实现智能灵活的用例管理，用例选择和质量评估方案；减少无数据支撑造成的内耗。
点个“在看”少个 bug 👇