测试左移这个测试方法已经出现很久了，但收益如何，收益如何体现，在不同的团队如何实施起来，现阶段在质量平台还暂未标准化和统一化。测试人员来实施测试左移，则需要测试人员具备业务分析能力，能做一定的业务分析，能看懂业务架构和技术架构，甚至具备代码查看和编码能力，能分析代码逻辑等。

在QA方面，测试自动化是一种行之有效的方法，可以让业务测试更加便捷，减少任何形式重复劳作和返工测试，提高轮次测试执行效率。目前自动化已在迭代应用中进入收益阶段，不仅在回归阶段代替手工回归测试，将自动化作用价值体现最大，也让自动化提前介入需求测试分析中，做到“测试左移”。

今年第一季度团队已提前试点“测试左移”，将自动化提前纳入需求测试分析阶段，在研发提测节点按需完成自动化左移。但是光从口头上说“测试左移”，也不能印证自动化左移的数据，以及左移带来的实际收益和价值，现阶段平台侧将 RDC(Research and Development Collaboration / 研发协同平台，得物技术部自研的一套项目管理工具）、协同面板、流水线、用例平台、自动化平台五方联合，共同搭建出测试左移的全链路操作。

测试左移的本质：越早的发现不合理的地方，出问题的几率就越低。

测试左移是软件研发生命周期过程中的测试策略，将问题进行早发现早修复，并且节约修复成本。同时测试左移的落地实践，也是推行需求研发自测的实行过程中的关键步骤。测试左移的节点在“需求提测之前”。

• 早期发现和修复缺陷：测试左移可以帮助研发在需求开发过程中早期发现缺陷，并及时修复，避免测试后期对缺陷的修复成本和影响。

• 提高测试覆盖率：测试左移可以帮助早期识别测试用例，在测试分析和测试用例编写阶段提高需求测试场景用例的覆盖率。

• 优化软件设计：测试左移可以提前介入研发代码设计，加强与研发团队的沟通协作，了解代码接口逻辑实现细节，使测试的执行更具有质量和效率。

• 提高测试效率：测试左移可以前置介入左移方案设计和编写，提升测试阶段左移用例执行效率，降低手工投入测试成本。

• 减少测试的回归周期、减少人工测试投入成本；

• 提高产研测三方的高效沟通和协作，让测试更加融入到开发过程中；

• 提高软件整体质量，避免需求上线发生故障。

什么是流水线？有什么类型的流水线？流水线的价值作用是什么？下面一一说到，可以帮助大家理解～

流水线，也被称为持续集成或持续交付。是将需求开发到需求上线的过程分解成多个步骤，其每个步骤都是由专业的工具自动检测完成的。

流水线步骤包括：

全流程流水线

• 感知应用服务的代码变更，融入需求测试轮次节点特征，自动构建部署应用服务发布，减少人工 check 投入成本

• 流程：

• 研发本地代码提交至 Feature 分支：Feature 分支触发 Push 流水线；

• Feature 分支提 MR 进 Release-{Version} 分支：Release-{Version} 分支触发 MR 流水线；

• MR 通过：Release-{Version} 分支触发 Push 流水线，自动检测代码检查、构建、部署。

现阶段流水线不再需要针对每个服务每个流水线类型做配置了，可以通过流水线模板降低流水线配置的操作费力度。

• 内置流水线模板：内设五种流水线模板，无需额外配置操作，开箱即用；支持特殊仓库自定义；

• 自动适配迭代：开发分支自动适配开发迭代染色环境，迭代分支自动同步一轮、二轮染色环境(无二轮环境的统一使用一轮环境)。

Push 流水线

开发分支代码变更后自动构建部署到需求对应的染色迭代开发环境，Push 流水线主要的作用：

• 代码提交后即时进行构建检查、代码扫描，提前发现代码问题；

• Push 后自动构建部署到开发分支对应的染色环境(若无则不触发)，为开发过程提效。

MR 流水线

• MR 流水线主要的作用为：

• 合并前：作为代码门禁卡口，构建检查、增量代码扫描问题；

• 合并后：触发 Release-${Version}/Release 分支流水线进行自动构建部署到迭代染色环境。

• 运行方式：

提测流水线

• 协同面板提测流程增加提测流水线，需求关联的后端应用自动触发；

• 执行方式：

• 在协同面板进行需求提测时，针对需求关联的应用创建染色环境执行提测流水线；

• 基于 Release-${Version} 迭代分支运行，运行结果反馈在协同面板；

• 提测流水线运行任务节点：构建、部署、自动化测试、代码扫描、Jar 包扫描、安全扫描。

Daily 流水线

• 基准 Daily

• 运行环境：基准环境(T1)；

• 运行分支：Release 分支(生产环境 Commit tag)；

• 运行方式：只运行基准环境的集成自动化测试，用于 Case 稳定性验证(目标成功率100%)。

• 迭代 Daily

• 运行环境：开发周一轮染色环境、测试周一轮染色环境；

• 运行分支：Release-${Version}/Release 分支；

• 运行方式：用于迭代分支的自动化检查，及时发现迭代分支代码质量问题。

关于“测试左移”，想必会有几个问题大家想要了解。什么是左移、什么是自动化左移、什么节点算左移、左移的标准是什么、左移的数据结果如何衡量，下面我们来看看思路和方案。

将“自动化”前置到测试阶段之前，对需求进行尽早地测试。

左移节点

• 提测左移：服务端研发操作提测时；

• 迭代左移：迭代时间范围内。

提测左移

• 需求在服务端研发点“提测”之前；

• 需求测试用例下有关联自动化用例；

• 关联的自动化用例状态必须是：“上线”。

迭代左移

• 迭代时间范围内；

• 需求测试用例下有关联自动化用例；

• 关联的自动化用例状态必须是：“上线”；

• 关联的自动化用例必须是：“执行过”（在自动化测试计划中执行过）。

Q：若需求是跨版本，怎么办？

A：用例平台的用例模块支持可移动，在模块移动的时候平台自动更改版本号，同时用例平台告诉自动化平台版本号的变更。

提测左移的数据指标衡量会在星盘平台输出对应的结果数据。

• 星盘：迭代维度，查看域/子域的测试左移；

迭代左移的数据指标会在自动化平台输出对应的结果数据；

• 自动化：迭代/时间范围维度，查看域/子域/人的测试左移。

所有编写的自动化脚本，均按照自动化规范标准输出。

编写规范参考：【接口自动化】平台应用规范。

关于提测左移的自动化，编写实施步骤：

当服务端研发点“提测”时，判断研发的 Feature-xxx 分支是否合入到 Release-{Version} 分支。【分支规范】

• 是（已合入）：允许提测；

• 否（没合入）：不允许提测。

流程：协同面板--->子域/版本号--->需求“开发”节点--->提测

提测自动化配置：

• BVT 主流程：子域业务模块核心 BVT 主流程自动化测试计划；

• 需求左移：提测时，自动检索需求用例目录下是否有自动化上线 Case（无需配置）。

BVT 主流程：

• 执行 Case：研发提测时间，触发业务域 BVT 主流程自动化；

• 执行环境：迭代 Round-1 染色环境；

• 执行目的：保证研发 Feature-xxx 分支合入 Release-{Version} 分支后对业务域的主流程是否有影响。

需求左移：

• 执行 Case：研发提测时间，触发业务域需求自动化；

• 执行环境：需求染色环境（自动创建）；

• 执行目的：需求维度自动化 Case 是否受需求提测影响而失败，判断是否是脚本问题还是代码问题。

无论是需求提测进度，还是自动化执行结果，均需要该需求的“研发+测试”共同关注，并且分析失败原因。

提测自动化执行失败，是否会影响研发提测进度？

• 不会。现阶段不会卡研发提测进度流程。

提测自动化执行失败，可以提缺陷吗？

• 可以。失败分析后定位出是研发代码缺陷，直接提 RDC- 需求缺陷，缺陷阶段=测试冒烟。

自动化测试左移是从之前传统的后期继承测试阶段提前至开发阶段的策略，通过在开发过程中引入自动化测试，在逐步提高测试效率，减少测试过程中的缺陷发生。我们将自动化测试与持续集成和持续交付相结合，实现了快速、频繁的测试和交付，减少了开发和测试之间的时间间隔，提高了产品质量和交付速度。

在自动化测试左移的基础上，我们将进一步完善和优化自动化测试流程，以提高测试的覆盖率和质量，扩大自动化测试范围和持续监控和优化，提升自动化测试范围，并且再进一步提高测试效率和质量。

关注得物技术，每周一、三、五更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞~
未经得物技术许可严禁转载，否则依法追究法律责任。

“

扫码添加小助手微信

如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：