前言

随着软件各行业的快速发展，用户客户及技术自驱对产品和系统的需求实现要求越来越多，从而必须要在研发测试周期排期固定的里程碑下可快速的进行 sprint 迭代按期完成质量交付，因此，对测试人员对软件质量的保障提出了更高的挑战；与此同时，在既要保障质量又要提升效能的产研测协同大环境和大背景形势下，进入测试阶段之前就必须要提升提测质量，如何提升产研交付质量到测试阶段呢？

重视测试左移就是重视软件质量和效能

测试左移这个测试方法已经出现很久了，但收效如何，收益如何体现，在不同的团队如何实施起来，这就需要 PM、RD、QA 三方共同对软件质量担负起相应的工作职责、协作起来，整个团队抵制任何形式重复劳作和返工，努力追求一次性完成正确的工作，测试人员来实施测试左移，则需要测试人员具备业务分析能力，能做一定的业务分析，能看懂业务架构和技术架构，甚至具备代码研发能力，能分析代码逻辑等。
　　
没有做好测试左移工作，必然会给软件开发造成返工成本的增加，不论是因修复缺陷而返工，还是因需求理解错误与实现不一致而导致写错代码而返工，对于软件研发项目里程碑都是巨大的损失和浪费，经常有这样的事例情况发生：最近某某项目某某迭代的某某需求就遇到一个难题，因为测试左移（需求评审）没有做到位，由需求设计问题导致了研发返工，delay 了某某天，使得研发测试不得不频繁加班，疯狂补救进度右偏移产生的风险损失。
　　
所以，这就要求产研测三方一定要重视测试左移的测试实践，因为，测试左移工作除了会消除返工的资源和时间成本浪费，还可以将问题进行早发现早修复，节约修复成本，推进产研测更好的协作配合，能很好的提升测试的有效性。

基于以上内容，后边我会介绍一下 360 中台业务测试团队是如何推动业务产研进行测试左移的，实施流程是都进行了哪些开展工作，供大家参考，希望对正在路上的小伙伴们有一定的帮助。
　　
测试左移都有哪些可实施的阶段呢，大家见下图所示：

这么多，都要开展实施么？怎么推动进行呢？

1.开发自测
其实要细化起来可能不止这些，如开发自测，会包括单元测试（将单元测试左移到编写代码的过程中去）、集成测试（将集成测试左移到开发模块或接口之间的调试过程中去）。此阶段测试推动难度最大，需要开发人员的高度配合和自我把控意识，同时也需要测试人员具备好的很高的编码能力；测试人员可以据此推动进行 code review、代码扫描、代码 diff、代码 mock 的测试分析和测试设计了。

2.需求评审
还有，大家都知道，需求评审前，测试人员就应该已经介入了，设计阶段也同样需要测试人员的熟悉和理解，测试人员可以提前提早的进行测试分析（测试分析包括分析产品，分析业务，分析业务架构和技术架构等），可以带动产品经理、UI/UE 设计人员、开发工程师将用户验收功能测试相关的一些工作左移到用户需求分析和设计的阶段去做。

3.用例评审
　　另外，用例评审前，测试人员测试进行相关的测试设计工作（测试设计包括设计质量体系，设计测试策略，设计测试用例和设计测试架构等），如设计测试用例可以编写抽取测试冒烟用例、可开发自测范围的用例，提供给开发进行可精准范围业务流程及业务逻辑的自测；另外测试人员还可设计测试框架，如依据获取到的接口文档设计自动化测试框架和 cases 及将测试用例中场景用例设计到自动化测试中。

4.UI 走查&产品走查
UI 走查、产品走查可在前端开发提测前进行，测试人员推动开发具备提测条件时组织 UI 人员、产品人员进行原型、文案、页面样式、页面布局、模块主要业务逻辑和主体流程的走查；并进行记录收集归档，便于可接受测试阶段和测试阶段可以依此进行测试验证。

5.showcase
测试左移实施 showcase 展示阶段，这个阶段就要测试同学推动产品和开发同事重视此阶段的进行，此阶段可以说事产品宣讲的一个验收，但此阶段是需要研发进行需求实现、模块集成及系统级联调后的一次研发成果的验收，主要是要保证需求与代码实现的一致，包括主要业务流程、功能逻辑、前端 + 服务端 + 底层依赖与系统框架部署环境关系的整体性和连通性，简单说就是是不是整个系统在产品人员、各端开发和测试人员的见证下是否可以跑通，不出现异常、流程走不下去、卡壳崩溃等情况的一次演示，出现问题可在各端开发共同在场的情况快速定位解决，目的就是保证软件需求实现可快速的完成整体的、完整的、环境通畅的达到可进入提测流程的作用。

6. 可接受性测试门槛
可接受性，我们的定义全程是 “可接受性测试门槛”，此阶段是进入到提测阶段开发提测部署到测试环境有测试人员进行测试，可以理解为是与冒烟测试共同进行的阶段；但和冒烟测试失败打回的标准要求是有明显界不同的；此阶段的门槛如何设定建立需要测试团队和业务产研团队共同商议决定。这个可接受性测试门槛可以包括 UI 走查、产品走查中的问题个数，也可以是接口调用不通或错误的接口个数，还可以是需求实现功能缺少的个数等等。达到此门槛约定的数量测试便可打回提测单给研发（注，即使冒烟测试是具备测试条件的）；当然了，提测单打回后测试人员不能等待开发再提测呦，测试人员要继续进行进行发现可接受性测试门槛约定情况的问题进行记录并及时提供给开发进行解决修复，其实就是要测试人员尽量控制减少打回次数和反复的流程操作带来的不必要的浪费。

7.其他阶段
产品设计、设计评审或叫技术评审、冒烟测试、代码走查等都可根据业务条件和资源精力投入是否具备进行实践开展。如产品设计就要求测试人员具备产品业务分析和对软件产品熟悉深入在经验上的能力而能参与到产品设计阶段发挥出测试左移的力量。
技术评审也需要测试人员不断的在熟悉并学习软件产品的各端实现细节、依赖关系、逻辑策略机制、时序交互过程、底层调用链路、使用的中间件及引入的组件功能特性等深入程度，最重要的是也需要开发能在输出概要设计及详细设计的技术文档的基础上才能开展进行测试左右的实施。
代码走查可以在介入到 CI&CD 流水线上进行自动化的左移，这个阶段就不多做累述了，因为就是利用工具能力进行配置、脚本实现和流程的依赖完成打通就能一劳永逸了。
冒烟测试，前面在可接受性测试门槛有提及，没什么好说的，这个阶段都是必须要做的，而且只能有测试进行和把控，友情提醒，可以在用例设计阶段先完成冒烟用例，因为是主业务流程、主逻辑功能的用例，主要设设计逻辑点多的可以细化清楚，形成的冒烟用例可以提供给开发进行自测，提测后要研发提供自测用例执行结果报告回来，这样会保障冒烟测试的通过率，减少冒烟打回的返工损失。

8.问答与价值体现
这么多，都要开展实施么？怎么推动进行呢？
答：不同的开发团队情况一定不会相同，测试推动开展要对业务进行情况分析、缺陷分类和标注后的分析，还要结合实际业务部门特点、重视程度、协同配合能力和力度进行灵活选取（结合分析的优先级确定出优先重要程度等级和各测试左移阶段具备的条件现状）可实施的阶段进行测试左移的推动实践。

　

结合 bug 分析和左移规避问题进行整体分析，可以阶段性看到测试左移产生的收效收益。

结束语

　　最后，要说的就是，随着软件质量保障、研发效能被重视的程度越来越高、越来越广，测试左移已经成为提升研发效能的重要方法和实践流程，对测试人员也是一次很好的学习与实践的机遇，如人工智能 GPT 的到来及快速发展，带给测试行业测试人员很大的压力，带入了很强烈的紧迫感和危机感；我们测试人员要做的就是通过我们不断的学习来利用人工智能的能力，在测试左移的向左过程中走出一条新的路来。