今年第一季度团队已提前试点“测试左移”，将自动化提前纳入需求测试分析阶段，在研发提测节点按需完成自动化左移。但是光从口头上说“测试左移”，也不能印证自动化左移的数据，以及左移带来的实际收益和价值，现阶段平台侧将 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：用例平台的用例模块支持可移动，在模块移动的时候平台自动更改版本号，同时用例平台告诉自动化平台版本号的变更。
左移数据结果如何衡量？
图片
提测左移的数据指标衡量会在星盘平台输出对应的结果数据。
- 星盘：迭代维度，查看域/子域的测试左移；
迭代左移的数据指标会在自动化平台输出对应的结果数据；
- 自动化：迭代/时间范围维度，查看域/子域/人的测试左移。
五、自动化左移规范
自动化编写
编写规范参考：【接口自动化】平台应用规范。
图片
关于提测左移的自动化，编写实施步骤：
图片
提测分支合并
- 是（已合入）：允许提测；
- 否（没合入）：不允许提测。
流程：协同面板--->子域/版本号--->需求“开发”节点--->提测
图片
图片
提测自动化
提测自动化配置：
- BVT 主流程：子域业务模块核心 BVT 主流程自动化测试计划；
- 需求左移：提测时，自动检索需求用例目录下是否有自动化上线 Case（无需配置）。
BVT 主流程：
- 执行 Case：研发提测时间，触发业务域 BVT 主流程自动化；
- 执行环境：迭代 Round-1 染色环境；
- 执行目的：保证研发 Feature-xxx 分支合入 Release-{Version} 分支后对业务域的主流程是否有影响。
需求左移：
- 执行 Case：研发提测时间，触发业务域需求自动化；
- 执行环境：需求染色环境（自动创建）；
- 执行目的：需求维度自动化 Case 是否受需求提测影响而失败，判断是否是脚本问题还是代码问题。
提测分析
提测自动化执行失败，是否会影响研发提测进度？
- 不会。现阶段不会卡研发提测进度流程。
提测自动化执行失败，可以提缺陷吗？
- 可以。失败分析后定位出是研发代码缺陷，直接提 RDC- 需求缺陷，缺陷阶段=测试冒烟。
六、总结与下一步规划
自动化测试左移是从之前传统的后期继承测试阶段提前至开发阶段的策略，通过在开发过程中引入自动化测试，在逐步提高测试效率，减少测试过程中的缺陷发生。我们将自动化测试与持续集成和持续交付相结合，实现了快速、频繁的测试和交付，减少了开发和测试之间的时间间隔，提高了产品质量和交付速度。
在自动化测试左移的基础上，我们将进一步完善和优化自动化测试流程，以提高测试的覆盖率和质量，扩大自动化测试范围和持续监控和优化，提升自动化测试范围，并且再进一步提高测试效率和质量。
