02敏捷开发测试流程

一个典型的敏捷开发测试流程

为了详细讲解不同阶段或职位&＃xff08;Title&＃xff09;的测试开发所做的工作有哪些不同&＃xff0c;我以当前流行的敏捷模式下的软件开发测试生命周期为例来讲解。

如上图所示&＃xff0c;你可以看到&＃xff0c;一个软件产品的立项是从软件产品规划&＃xff08;图片顶部&＃xff09;开始的&＃xff0c;一般我们根据业务目标把规划的软件产品需求项&＃xff0c;基于实际情况&＃xff08;业务目标、公司战略等&＃xff09;拆分为多个 Backlog 进行进一步细化&＃xff0c;即 Backlog Grooming。

细化之后的需求按照优先级和发布规划&＃xff0c;会分为多个 Sprint 进行开发、测试、上线。在每一个 Sprint 内&＃xff0c;需求会被拆分为一个个的开发和测试任务&＃xff0c;开发人员完成 Task 开发后&＃xff0c;就进行自测。

自测没问题&＃xff0c;通过提交 Pull Request 的方式&＃xff0c;请求提交代码到 Master 分支&＃xff08;这个动作对应于提交测试&＃xff09;&＃xff0c;请求提交后&＃xff0c;代码托管平台比如 GitHub、GitLab 等会触发由 Pull Request 引起的自动构建。之后&＃xff0c;自动构建会引导持续集成平台&＃xff0c;把开发提交的最新代码打包成可用的测试版本。

同时&＃xff0c;开发通过更改 Jira Task 状态的方式&＃xff08;或者平台自动更改 Jira 状态、开发邮件/口头通知等方式&＃xff09;&＃xff0c;提醒测试人员进行测试验证。

软件测试版本生成后&＃xff0c;有两个测试内容会同时进行&＃xff1a;

持续集成平台会触发预设的测试脚本进行自动化测试验证&＃xff08;一般是整个产品的主流程冒烟测试&＃xff09;&＃xff1b;

测试人员根据获取到的软件测试版本&＃xff0c;针对开发提交的 Task 进行测试&＃xff08;主要针对新功能&＃xff0c;手工执行的方式居多&＃xff09;。

测试人员在进行人工验证时&＃xff0c; 先根据测试计划和之前准备的测试脚本进行冒烟测试&＃xff08;主要关注点在于本测试组负责的业务模块&＃xff09;。

冒烟测试通过后&＃xff0c;再进行功能、性能、安全等方面的测试验证&＃xff08;也就是图中 Sprint 这个模块内的蓝色的测试验证部分&＃xff0c;这是测试人员花费最多时间的地方&＃xff09;。测试人员进行测试验证的依据来自测试计划的制定和细化&＃xff0c; 这部分工作通常由项目立项开始&＃xff0c;至 Sprint Grooming 后&＃xff0c;开发提测之前结束。

如果测试验证不通过&＃xff0c;测试失败的结果会被反馈给开发&＃xff0c;Pull Request 不会被 Approve&＃xff0c;开发人员会修复问题&＃xff0c;再次提交 Pull Request 流程&＃xff1b;反之&＃xff0c;如果测试验证通过&＃xff0c;会通知开发人员测试已经通过&＃xff08;这相当于 Approve 之前开发提交的 Pull Request&＃xff09;&＃xff0c;然后开发就会合并代码到 Master 分支。合并会再次触发新一轮的持续集成流程&＃xff0c;如此循环往复。

合并进入 Master 分支的代码&＃xff0c;通过自动测试验证后&＃xff0c;就会被发布到指定测试环境&＃xff0c;测试人员会将自动化脚本在此环境进行新一轮的测试验证&＃xff0c;直至没问题后&＃xff0c;会依次经历几个测试环境的验证&＃xff0c;最终被持续部署平台采用蓝绿部署、灰度发布、滚动发布等方式部署上线。

OK&＃xff0c;了解了一个典型的敏捷开发测试流程后&＃xff0c;接下来&＃xff0c;我们看一下不同阶段的测试人员在这一流程中分别担任怎样的作用。

测试开发、资深测试开发、测试专家的不同工作职责

为了方便你理解&＃xff0c;我按照测试开发的不同阶段在上面的流程图中标记了不同的颜色。

1. 蓝色——初级测试开发

从功能测试转为测试开发&＃xff0c;你的工作内容会包括帮助功能测试人员编写测试工具及测试框架&＃xff0c;进而来提升功能测试的效率&＃xff0c;也就是通过开发手段让功能测试变得更简单、快捷。

这一阶段的目的纯粹是助力功能测试&＃xff0c;减少人工重复劳动&＃xff0c;缩短测试周期。该阶段的测试开发仅仅聚焦在开发这个纯粹的事情上。

举例来说&＃xff0c;你通过编写自动化工具/框架&＃xff0c;把本应该是手工执行的工作转换为机器自动运行&＃xff1b;通过编写造数平台&＃xff08;Data Platform&＃xff09;&＃xff0c;让构造测试数据变得比以往更为简单。

所以&＃xff0c;判断一个测试开发是否合格的标准&＃xff0c;是看他能否让功能测试更省力。
2. 橙色和绿色——资深测试开发

资深测试开发不再局限于开发本身&＃xff0c;而是从流程出发&＃xff0c;检测公司整个软件开发周期中&＃xff0c;哪个部分耗时最长&＃xff0c;哪个部分最复杂&＃xff0c;哪个部分最容易出错&＃xff1b;然后资深测试开发就要改造现有流程&＃xff0c;通过详尽分析、仔细论证&＃xff0c;把最复杂、最容易出错的部分流程自动化掉&＃xff0c;纳入当前的持续集成流水线中去。

这一阶段的测试开发&＃xff0c;已经不满足于完成功能测试提出的开发需求&＃xff0c;而是通过自己的开发技能&＃xff0c;把测试各个阶段的任务有机地结合起来&＃xff0c;经过消化后重新组织输出。

比如&＃xff0c;以前公司没有持续集成、持续部署平台&＃xff0c;代码打包都是开发或者测试人工去操作的&＃xff0c;那么资深测试开发就要和整个开发团队合作&＃xff0c;建立并完善这些流程。再比如&＃xff0c;以前测试流水线没有建立&＃xff0c;自动化测试脚本需要人工触发执行&＃xff0c;那么&＃xff0c;资深测试开发就需要把这些流程整合。

因此&＃xff0c;判断一个资深测试开发是否合格的标准&＃xff0c;是要看他的技术产出是否能融入公司的技术体系中去。换言之&＃xff0c;就是要看功能测试的工作是否严重依赖他的产出&＃xff1a;如果测试开发停工&＃xff0c;那么功能测试就会很痛苦&＃xff0c;甚至也被迫停工。

需要注意的是&＃xff0c;这一阶段资深测试开发的产出&＃xff0c;肯定非常贴切公司的情况&＃xff0c;但未必符合其他公司的情况&＃xff0c;或者未必跟业界的主流情况一致。

3. 红色——测试架构师或者测试专家

可以看到&＃xff0c;这一部分的测试开发重点已经不是测试本身了&＃xff0c;而在于整个软件开发全流程的梳理。从项目立项开始&＃xff0c;测试架构师就要规划当前的测试框架需要何种裁剪才能保证本项目顺利发布&＃xff0c;并且在项目最开始阶段&＃xff0c;通过测试左移的手段&＃xff0c;对需求、开发技术方案进行分析&＃xff0c;在保证可测试性的前提下&＃xff0c;把公司现有的测试手段完美嵌入整个开发生命周期中。

在项目发布后&＃xff0c;通过测试右移的手段&＃xff0c;对生产系统进行监控&＃xff0c;对系统本身或业务本身的各种线上情况进行分析&＃xff0c;找出薄弱点&＃xff0c;反查整个开发测试流程中的短板&＃xff0c;然后补齐&＃xff0c;从而保证产品的高质量和业务的高可用性。

判断一个测试架构师或者测试专家是否合格的标准&＃xff0c;是看他能否在某个领域全部或者部分重新定义测试活动、测试顺序。换言之&＃xff0c;这一阶段的工作产出&＃xff0c;不仅仅适用于本公司&＃xff0c;放到其他公司也可以&＃xff0c;从方法论上来说&＃xff0c;应该是普适的。

围绕以上三个测试角色&＃xff0c;我们简要总结下&＃xff1a;

测试开发&＃xff0c;即提升测试活动的效率&＃xff0c;通过技术手段帮助功能测试工程师提升测试效率&＃xff1b;

资深测试开发&＃xff0c;即重构测试活动&＃xff0c;技术产出完全融入公司的技术体系&＃xff1b;

测试专家/测试架构师&＃xff0c;即重新定义测试活动&＃xff0c;输出普适的测试方法论。