我理解的测试左移

本文作者: [阳际荣(韩锷)]

随着行业的发展，目前大部分公司都会追求更高的开发测试比，在更高的开发测试比的前提下，质量团队应该做什么保障质量效果更好是一个质量团队长期需要思考的问题，本文主要介绍我对网易云音乐测试左移的理解。

测试左移是什么

传统的测试左移

简单说，左移软件测试就是将开发周期看作从左到右的一条直线。
在旧模式中，测试仅在这条直线的最右边发挥作用。认识到这一瓶颈，我们现在希望将测试的开始位置尽量左移。
左移是在软件交付过程中尽早发现和防止缺陷的一种实践方法，目的是尽量在软件开发生命周期中尽早将测试任务左移，以提高产品质量。左移测试意味着在软件开发过程的早期阶段进行测试。

测试左移的优缺点

测试左移理论上的优点：

• 成本本身就是将测试左移的主要动机之一，据估算，超过一半的软件缺陷可以在需求挖掘阶段被发现，只有不到10%的缺陷出现在生命周期的开发阶段，在产品投入生产后消除缺陷的成本将是需求挖掘阶段的100倍以上
• 更高的自动化效率，左移可以提高自动测试的能力。测试自动化的主要好处包括：显著减少人为错误、扩展测试范围（可以同时进行多个测试）、测试人员能够专注于更有趣、更有意义的任务、减少生产问题
• 更快的软件交付效率越早发现缺陷、越能快速修复它们。如果您能在生产周期的早期发现缺陷，便可以更快地修复它们。从而：大大缩短两次产品发布之间的时间间隔，提高软件质量

测试左移理论上的缺点：

• 极高的测试基建要求，测试左移对代码扫描、质量度量、接口用例自动化、完善的测试用例、数据工厂、测试环境等都有较高要求，需要在具有一定基建能力下才能完善测试左移
• 很多团队所处的生命周期不适用，对于初创团队、创新团队、快速迭代团队等团队不一定适用于测试左移，上述团队在绝大部分
• 容忍度较高的互联网行业，对于部分用户体感不通的互联网业务，用户能够容忍小的问题上线，只要快速修复即可，该业务有时候大家更加看重的是快速发现问题，而不是在线下做到尽善尽美

云音乐测试左移的痛点

<img src="https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524692301/39b8/f41b/06f0/9d1424f96655a4d5943c7244fd0660aa.png">

开发以为：

• 测试左移完全是工作的转移，变成了纯是开发做测试
  
  测试以为：
  
• 测试左移，工作全是开发的，但是出问题测试也都要担责
  
  
  
  
  当我们讨论这个痛点之前，我们一定绕不过去的一个问题就是：开发测试比 ，目前的测试左移是我们主动选择的结果还是被动选择的结果
  
  
  
  
  结论：以目前云音乐的开发测试比，我们很难完全支持所有业务，此处涉及组织敏感数据，细节不在此处展开

行业内会是什么样

局部的测试左移：

• 极致服务端录制回放 https://help.aliyun.com/document_detail/62635.html
• 导购、交易特色录制回放方案
• 封版模式，服务端开发自测，同时通过客户端测试兜底

我期望的测试左移是什么

<img src= "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524697896/8e67/7374/1b14/c114114d0a715d9ce29d65dbbdf6caa0.png">


理想的测试左移：


事前

• 技术方案评审
• 核心p0、p1的接口自动化
• 场景自动化录制回放
• 特定场景的UI自动化

事中

• 中心化的客户端卡口（crash、舆情中心化卡口、高危组件识别兜底、包产物检查等）
• P0场景回归兜底（约1000个测试用例）
• P1场景回归兜底（约3000个测试用例）
• 核心财报埋点卡口兜底

事后

• 强大的染色能力，重点项目的上线，相关功能逐步灰度上线，灰度的功能能够全量隔离并单独监控，比如针对改动功能用户的舆情、crash等能单独识别
• 强大的中心化crash、舆情、slo监控处理群
• 资损监控

通过事前、事中、事后的方式，显著的提升确定性、提高质量，同时也能减少测试左移，研发的体感，避免工作量的转移

测试用例自动化的完善

进一步的覆盖率提升

测试左移一定需要具有强大的自动化用例，通过稳定、准确、覆盖率高的自动化测试用例提高整体线下质量。这里涉及到服务端测试用例与客户端测试用例，目前根据业界自动化成熟度在服务端自动化要求会更加高，需要涉及绝大部分场景，客户端这块主要用于稳定性自动化与核心用例回归兜底

<img src = "https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524706387/e8cb/d6e9/e225/392e871723ccaf06ae0a73fcc23664a9.png">

服务端自动化提升

目前从行业内技术发展看，服务端的自动化技术已经较成熟，不管是接口测试还是引流自动化，服务端自动化具有几个优点

• 稳定性高，在接口不大规模改动的前提下，服务端自动化在执行过程中有较高的成功率
• 成本相对较低，接口自动化主要是rpc接口的请求以及返回值的教研，通过gotest等接口测试平台，编写服务端自动化的成本相对较低，通过引流回放的成本更低
• 较好管理，服务端接口的用例基本以研发接口为主，整体用例场景较好管理

<img src ="https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524710023/7387/d404/c292/a92b91904493fb3e4eee3d7cf214f543.png">

首先是服务端测试用例的提升，平台这块主要希望服用gotest接口测试平台，核心2个关键次：稳定、覆盖率高

• 针对稳定，周维度跟进，连续两周稳定性不达标，@对应质量组长跟进，并提醒改进
• 针对覆盖率，中心化度量覆盖率，通过分析ox平台和goapi平台的接口数，并将各业务存量接口未导入goAPI的集中导入

最终期望
3分： 服务端线下接口覆盖率达到95%，CI用例通过率95%；代码覆盖率：50%
5分：服务端线下接口覆盖率达到99%，CI用例通过率99%；代码覆盖率：60%；

服务端自动化长远方案：加强引流平台的建设，通过线上流量录制回放，并做好线上流量的用例、场景管理，进一步减少自动化用例成本

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524709923/d435/7d75/0426/74c75a9185d07510f35f687603b34b07.png">

客户端自动化提升

目前从行业内技术发展看，客户端的自动化技术相对还需要突破，行业内经常听说某团队维护几万的服务端自动化脚本，但是很少听说某团队维护超过1000以上的客户端脚本，客户端自动化具有以下特点：

• 具有明显的中心化特征，不管是什么团队，最终客户端代码的实现都是通过中心化发版来上线，因此非常适合集中做monkey、内存泄漏等中心化稳定性操作
• 自动化稳定性相对不高，维护成本相对较高，因为前端UI界面变化较块，客户端脚本成功率普遍显著低于服务端

客户端中短期方案：

• 中心化的monkey、内存泄漏测试，通过中心化运作，通过monkey、内存泄漏等方案，集中发现问题
• 中心化的P0测试用例回归，测试用例不追求大而全，保障核心场景自动化没问题
  长期方案：目前行业内针对瀑布流、自定义动态生成有较好的客户端成功率

瀑布流场景：

瀑布流场景用户操作简单，核心功能主要为上滑与下滑，自动化运行简单，可以通过UI自动化执行上滑下滑，然后通过截图，图像对比进行校验，成功率较高，即使是千人千面也可以通过mock规避相关个性化问题，因此后续涉及瀑布流场景建议UI自动化突破

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524716128/c605/850e/a58f/84d516c7a83218470185615d235fbf73.png">

自定义动态生成场景：

自定义动态下发场景，客户端最终的界面是通过服务端约定协议自动生成的，因此只要和客户端引擎、协议打通，最终的界面是确定的，UI自动化可以针对协议编写自动化脚本，稳定性方面可以极大的规避之前UI界面变动导致的成功率较低的问题

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524716518/6a2d/bddf/07ee/0f6d3175664fdcc2940a33733bca5bdf.png">

强大的客户端卡口能力

客户端是绝大部分功能上线交付消费者的中心节点，集中做好客户端的功能保障，在很大程度上能形成中心化的兜底，规避较多的重大问题。因此云音乐主要在测试用例三层兜底、版本流程发布管控上做了较大投入

版本发布三层兜底

云音乐客户端版本版本发布设定三层兜底，首先是P00用例，只出为最核心的关键用例集，只要在涉及到发布，包产物有变动，都需要执行一次关键核心用例集

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524723036/4f7e/e86b/5085/9914164063df8ae6ea4816f78c1c91ad.png">

然后是P0用例，大概1000条左右，按照正常冻结集成时间，一天内执行完，主要包含日常回归的主要用例，每个模块的主流程

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524726284/0552/cf47/7c9a/f3d4a6b1d93cc602f6a04681c553f656.png">

最后是P1用例，大概3000条左右，主要包含每个模块其他额外的分支场景，该用例需要执行3天，且不需要考虑用户有修改代码，每次只执行一次

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524728224/cf76/417e/8908/eaa4fab9aac17f9958b993d8e111f432.png">

通过三层兜底，我们客户端实现了核心功能只要改动都做好了回归，分之场景一定周期也能做到全量回归，通过分级做到了成本与回归面的统一

版本流程优化

通过版本发布的checklist流程化，保障每次包的发出，不会出现较大的问题，让每次包产物的变化得到性能、功能、埋点、稳定性等方面的验证

<img src = "https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524729526/2b58/901b/e654/36ff90c42d065235aaf7ca8bbecd8394.png">

强大的监控能力

当前面所有的测试、兜底都完成后，还是会有问题泄漏，因此我们也需要有良好的问题发现能力，避免质量显著下降

事前-监控设计

我们希望重点项目上线前默认都是有监控的，带着监控上线的功能才更加具有确定性

服务端系统需要关注：

• GoAPI巡检监控
• SLO监控
• pylon 埋点监控
• 哨兵监控
• Nydus监控 / Kafka监控
• NDC监控
• 舆情监控

前端监控需要关注：

• Corona监控
• 舆情监控
• H5巡检监控
• RN巡检监控

同时发布要分批次，并做好分批次监控观察

<img src= "https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524732951/9e4d/8a1f/fab9/db32bb1c1882ab16692f06d62ca795de.png">

事中-重点项目染色

1、重点项目-关联标记（项目自定义标记，自定义流量标记x-proj-tag）

2、服务端链路监控告警区分：大前端请求API透传标记+网关请求流量打标+脚手架中间件透传标记+应用日志监控SDK上报流量标记+监控平台通过流量标记区分监控告警内容

<img src = "https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524735636/017a/4a09/6558/381359ed5c05d9bbe7193e92faff1519.png">

3、客户端监控告警区分：大前端日志异常和崩溃上报带上业务自定义标记

<img src = "https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34524742115/2684/a934/5bd5/78a92919d0c3d2629acce596e98484b6.png">

事后-中心化监控处理

监控的效果需要可被观测，因此分级的重要的报警都会被集中到中心化群里被所有人观测，提高处理者处理的压力和动力

<img src = "https://p5.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/34802849651/0566/f99b/2a10/490ef6c025ed2b4248b97ffde6072b46.png">

结语

以上就是我对测试左移的一些理解，也包含了挺多测试右移的思想。主要适用于风险适中的业务，对涉及资金类、电商核心流程等需要谨慎看待

最后

更多岗位，可进入网易招聘官网查看 https://hr.163.com/