传统的测试左移

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

测试左移的优缺点

测试左移理论上的优点：

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

测试左移理论上的缺点：

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

云音乐测试左移的痛点

行业内会是什么样

局部的测试左移：

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

我期望的测试左移是什么

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

事中

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

事后

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

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

测试用例自动化的完善

进一步的覆盖率提升

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

服务端自动化提升

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

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

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

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

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

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

客户端自动化提升

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

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

客户端中短期方案：

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

瀑布流场景：

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

自定义动态生成场景：

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

强大的客户端卡口能力

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

版本发布三层兜底

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

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

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

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

版本流程优化

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

强大的监控能力

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

事前-监控设计

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

服务端系统需要关注：

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

前端监控需要关注：

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

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

事中-重点项目染色

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

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

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

事后-中心化监控处理

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

结语

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

最后

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