研发效能认证学员作品：如何实现在DevSecOps的测试左移丨IDCF

本文主要是介绍研发效能认证学员作品：如何实现在DevSecOps的测试左移丨IDCF，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：赵露润（现就职于赛意信息科技有限公司）

研发效能（DevOps）工程师认证学员、PMP 认证、ITIL4 认证

前言

一个自主研发的ITDevOps系统，承载的主要功能有产品信息树管理，敏捷协同管理，开发服务管理，测试装备管理以及安全运维管理，而开发服务管理是旨在给公司其他项目提供端到端一体化的自动构建和自动部署功能和包管理功能，承载大量用户去频繁使用平台，怎么更好的着手于项目的测试管理工作从而减少遗留的上线缺陷，减少用户差评，提升用户满意度，反而是更加艰巨的任务。

痛点

为了更好的协调团队运作，提升研发效能，实现测试与开发敏捷协作，减少沟通成本，提升上线变更成功率，着手针对项目痛点并一一解决：

一、平台类产品需求，设计变化多，基线管理困难：平台类产品要快速响应业界的业务变化，客户对版本交付的需求变更大；

二、团队API资产模糊：项目微服务多，缺少整个API资产功能清单，新进人员对部分存量的API功能无从下手；

三、上线频繁，测试验收时间短：当前项目每2周例行一次上线，开发人员自测和联调占用了测试人员的验收时间，上线时间匆忙导致人为失误率高。

手工测试左移与可信测试线上化

作为测试经理，从当前项目运作中出现的测试结果和现状，明显的感受到，项目还处于传统的软件研发周期，即“瀑布模式”，在这个模式下，项目的周期清晰的分为几个阶段：制定计划-需求分析-软件设计-程序编码-软件测试-运行维护等六个基本活动，如图一：

如上图所示，软件测试阶段就处于软件生命周期第五个阶段，比较靠右的一个阶段。

因为项目每2周例行上一次线，在“靠右”阶段测试发现的缺陷修复成本会非常高，这些缺陷大部分并不是在编码的时候发现的，而是在转测之后发现的，甚至是上线后，导致上线失败，第二天继续接着上线，就会出现，开发人员忙于修复缺陷而延迟迭代的开发，测试人员后期忙于测试而前期无事可做，技术债像雪球一样越滚越大，开发和测试疲惫不堪，精力不充分，且最终导致项目绩效数据为：上线变更成功率越来越低。

为了解决这一现状，经过跟项目经理的沟通，提出了，在团队内引入手工测试左移和API自动化测试左移的概念。

怎么样才算手工测试左移呢？即从研发完成后测试才介入的方式，变成从指定计划，需求分析的阶段测试人员就开始参与。

一、预习会议

组织需求澄清会议

BA、开发、测试全员参与，在会议上，BA向开发和测试逐一澄清需求，并且开发人员和测试人员均要提出自己的疑问，BA将问题与PM和用户沟通业务方案后并继续与高级开发商讨技术方案，期间测试人员全程参与并关注记录需求任何变动过程。
组织开发反串讲会议

由开发人员进行开发反串讲评审，每个开发针对自己开发的需求，输出开发设计思路和流程图，测试根据业务点提出相应的疑问，并且与开发达成一致意见后，开发人员再继续投入到开发工作中。
组织测试方案评审会议

由测试人员编写测试方案文档，组织开发人员协同参与，开发人员针对方案中不正确或者模糊的地方，提出改进意见，完成需求从开发到测试的最终论证闭环。

二、依托平台

制定测试设计

测试人员引入测试设计，在项目的规划设计上，通过平台中项目管理的规划进行需求的计划和设计。项目管理根据常用的规划方式提供思维导图。将IR引入到本迭代的测试设计下，添加对应US，以及维护好测试责任人字段。
制定测试策略

测试设计完成后，针对每个US，添加子节点，再添加测试策略，其中包含：测试范围，测试层级，测试类型，验证环境，风险和处理方案。从原来通过文档描述，改成线上化通过子节点添加，从需求引入到下发功能节点，完成测试可回溯。
制定测试方案

测试策略完成后，着手将本地编写测试方案逐步牵引到线上化管理，由原来直接在本地通过xmind完成测试方案的编写改成，通过本地直接导入的方式或者线上化编写的方式来实现测试方案的备份管理。
制定测试用例

测试用例线上化以迭代的方式进行，将用例通过基线整体管理，若当前迭代有变动，则自动同步到baseline去，并且在测试方案线上化实现可选择用例的关联关系，完成从测试设计，测试策略，测试方案的线上化可追溯。

经过几个迭代的初步运作，测试用例的执行能够完全被线上化跟踪，漏测的现象慢慢减少，发现缺陷的时机也从迭代结束时发现提前到刚开始业务需求上的提前规避。

这时候我们已经完成手工测试的规范化，和测试左移的第一步，俗话说，不积硅步，无以至千里，怎么才能继续第二步呢，这里就涉及到API自动化测试的左移了。

那么，如何实现API自动化测试的左移呢？

API自动化测试左移

我们一般知道，测试金字塔，也被称为测试自动化金字塔，本质上描述了开发和QA团队应该纳入自动化测试套件的测试类型。此外，它定义了这种评估的顺序和频率，其目的是提供快速反馈，以确保代码变化不会影响现有功能。如图二：

1.单元测试（UnitTest）

单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快速的反馈，在开发过程中就可以对逻辑单元进行验证。

2.接口测试（Service/服务/API Test）

接口测试是针对业务接口进行的测试，主要测试内部接口功能实现是否完整，如主要业务流是否能走通，异常处理是否正确，数据为空时校验等等。接口测试的主要价值在于接口定义相对稳定，不想界面或底层代码会进场发生变化，所以接口测试比较容易编写，用例的维护成本也相对较低，在接口层面准备测试的性价比相对较高。

3.集成测试（UI Test）

集成测试从用户的角度验证产品功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个业务流，集成测试的业务价值最高，它验证的是一个完整的流程，但是因为需要验证完整流程，在环境部署、准备用例及实施等方面成本较高，实施起来并不容易。

对当前项目而言，API资产无管理，无线上化操作，且没有接入到开发后的测试阶段。所以，第一步必须要把自动化流水线上面搭配API自动化测试，完成定时定量执行，提前发现环境及接口不稳定等因素。就必须要从以下两个方面着手：

API线上化管理
1. 线上化基线版本：通过线上的API基线版本，约束在版本交付过程中，不做变更，如果要做变更，可以根据基线版本计算人天，进行同等人天需求替换。
API资产管理
1. API功能清单：API功能资产清单线上回归，分层分级设计，清单目录结构清晰
2. API用例清单：API明明使用业务描述+代码术语相结合，便于开发和测试人员快速确定API基本信息与自动化测试用例信息
3. 进项必修课：新进人员入项必修课，了解项目API功能清单

通过以上两个阶段，将项目的API资产进行梳理，完成API资产的线上化，统一化，一致性管理。并且作为新进人员进入项目的学习清单项之一，既完成了项目组织过程资产的沉淀，又完成了项目API的线上化运作，最终在流水线上，搭配自动构建，自动部署，API自动化测试，完成API自动化定时执行，以及跟手工测试用例关联，完成自动化测试结果自动回写和自动化发现问题缺陷数增加。

此时，API自动化测试的发挥已正常初步试运行成功，但是测试人员初步接触API自动化测试后，在编写API自动化测试用例时，有很多参数无法理解，还要去跟开发进一步沟通和对接，那么，鉴于此现象，为什么不能将这个沟通提前到一开始呢？所以，此时又引入了API自动化测试左移的概念，即，在开发进行API设计时，测试人员就参与，在API设计完成后，测试人员就开始编写自动化测试用例，大概分为四步：