敏捷下的测试(Cypress )

一、引言

在目前的软件开发领域，敏捷、DevOps 是最热门的‘词’了、现在大多数的公司都在进行着 “敏捷”转型。业界有很多所谓敏捷开发流程，比如Scrum，Kanban等，但是其中测试相关的内容相对较少，并且不够系统化和细节化，所以业界就出现了很多测试人员，他们总结了测试人员应该在敏捷开发中如何进行测试工作。由于很多测试人员也是公司或者团队在Scrum和Kanban的转型中接触和学习到敏捷，然后通过有限的资料以及自悟在团队中进行敏捷测试，又在一知半解下去宣传敏捷测试或者去抵制敏捷测试，导致敏捷测试甚至敏捷本身在国内乱象丛生。

首先敏捷测试一定是敏捷开发方法的一部分，所以敏捷开发方法论里应该需要包括敏捷测试的相关内容，但是现在业界中所谓的一些标准的敏捷开发流程里却很少包含系统化的测试实践。由于敏捷测试实践或者说敏捷实践的核心就是缩短反馈周期，逐步优化整个系统。并且因为每个团队的情况都是有差距的， 所以通过同一种标准的方式去要求所有的团队，会产生很多负面的效果。

现在业界已经有不少通用的敏捷测试实践，以及一些在特定条件下的经典流程(后面会介绍一个经典的敏捷测试管理流程)。其次 对于大规模敏捷开发中的敏捷测试来讲，其核心还是在开发团队里合理使用各种敏捷测试实践，缩短测试反馈周期。

因此不管敏捷开发还是敏捷测试里的敏捷都没有一个所谓统一的最终敏捷，应该是需要越来越敏捷的状态才是最好，然后 最终达到自己项目的一个稳定敏捷状态就可以。

二、实践

看完了别人的介绍，也要开始我们自己的实践、就如上文中说到的“敏捷中的测试是一个新开始、要努力尝试的过程”。

介绍一下背景。我们是一家在数字化转型中的公司，公司2019年开始进行数字化转型，也是从那一刻开始、“敏捷”从一个名词进入到大家的“工作中”。瀑布模型下的专职测试人员也要开始自己的转型了。经过一年的努力我们收获到一些成果，现在给大家分享一下。首先看看我们的流程图，不是最标准，却是最适合我们现状的。

下面我们针对流程中的每个阶段进行说明，只解释和测试相关的，除此之外的不在本文做更多的阐述。

2.1 需求分析阶段

这个阶段我们主要定义二个事项：

基于组织的“测试标准化文档“进行测试相关工作的相关追踪跟进机制的确认，并和相关人员达成共识，同时确认本次冲刺需要收集的度量数据。
完善功能级的DoD 验收标准，最终形成的一个在线检查清单，这个检查清单主要面对是用户或者PO层面、产品展示会议进行之前，会首先确认检查清单是否已经完成，所有检查项目是否已经全部通过。也是我们敏捷流程中质量内建第一把锁。

2.2 冲刺规划阶段

在冲刺规划会议测试人员会参与对用户故事的DoD 讨论和制定、确保开发人员和测试人员能在后续的工作中保持在同一个频道。

2.3 冲刺阶段

目前我们的现状是有跨项目的测试人员，负责多个项目的测试工作。为了能最大化测试人员的效能，引入自动化测试工作必不可少（后面针对于自动化测试工具做对应介绍）。虽然敏捷流程推荐是减少文档，但测试用例从目前阶段来看是一个必须存在的文档信息。针对于测试用例我们会使用走查的方式进行验证，例如导入导出相关的用户故事是开发A负责，当针对于这个用户故事的测试用例完成后，会同开发A进行第二次的确认，确认我们还在同一个频道中。

测试人员会基于编写好的测试用例进行自动化测试脚本的编写，测试脚本会同开发的代码存放在同一级的代码控制库中。

开发人员完成用户故事的开发后，通过CICD流水线进行部署，同一时间测试脚本会自动被执行。

测试人员会进行一次的测试报告的分析确认，确认测试脚本是可以满足相关功能，同时针对于测试报告中的bug更新到项目管理系统中,并指派对应人员进行修复。开发人员在进行修复后重复之前的发布流程,然后通过自动化测试的报告确认问题已经被修复。当然如果测试人员发现测试脚本不能满足测试的需求时，会同步更新测试脚本到代码库，以确保自动测试是可以被正确执行的。