敏捷测试-最全体系

关注

原创最新推荐文章于 2026-09-07 13:07:50 发布 1.9k 阅读 AI 写同款· GEO 优化 ›

ArcGIS中根据DEM和地形起伏度进行地貌分类划分大家好我是GIS蒲公英，数字高程模型(digital elevation model, DEM)经常都被用到专题地图的底图中，下面来我们来交流一下仅选择海拔和地形起伏度两个指标，用DEM来进行地貌类型的自动判别划分阅读详情

敏捷测试-最全体系

既然前面谈了敏捷测试要涉及的相关知识，那么从这里开始从完整的生命周期来聊下敏捷测试需要掌握的相关技术。

从UserStory开始

在敏捷中需求变成了用户故事，要解决的问题没有变，但是解决问题的思路变了。

需求是一种描述最终产物的文档，强调定量，通过精确的标准来完美还原要实现的内容。需求规格说明书就是那厚厚的文档，在已知世界、已知解决方案的情况下这是没有问题的，但是现代这个社会已经不是这样了。

我们现在所面临的世界是一个未知问题、未知解决方案的世界。参考“无敌破坏王2”中，拉尔夫就是学了羊叫突然就火了，然后还是和Bee干上了，就这样在爆音上获取了足够的流量提成。

我们不知道用户需要的是什么，抖音解决了大家什么问题？夸夸群呢？很多内心深处的东西都被各种表面遮盖了，当我们觉得自己静下来的时候，认真思考我努力工作为了什么的时候，才能问自己工作是为了生存还是什么？哪怕薪水提高一倍，也没有本质的变化，买东西所能填充的内心空虚是短暂的，也是很容易就疲惫的。

工作为了更好的收入，收入为了更好的生活，那么理想的生活是什么？回到乡下过无忧无虑的生活，其实现在不也做得到么？这里说了这么多其实想引出用户故事的特点，阐述定性的东西，扩展规范定量的东西。

UserStory定性

其实不太想套用外面默认的很多格式，作为一个用户故事，我们一般是这样写的

“作为一个who, 我需要What，来实现Goal”

在这里就可以非常明白的看到和传统需求文档的差距，例如：

需求规格：使用木头制作一个10*10*10厘米的立方体，表面为黑色

UserStory：作为一个孩子，我需要一个黑色立方体，来作为我丢失一块积木的补充

这里大家应该可以非常明显的看出来两个写法的区别，由于过去问题的已知性和解决方案的明确性，只要你告诉我你要做个啥，我就给你做就行了，没有别的选择的。但是现在用户很难给出自己需要的内容，需要更加专业的BA人员来对用户的痛点进行分析，转化为用户故事。所以在这一点上用户故事更加在意定性，而通过快速交付的方式和用户沟通确认渐进明细，从而交付用户价值。

以前是花一周时间去和用户确认需求编写需求规格，用一周来实现，最终交付给用户。而现在是花一天时间去了解用户想要解决的问题，花一天做一个demo，再花一天和用户沟通这个demo有哪些需要改进的，从而最后可能只需要一周时间就完成了，而其中时间的节约从何而来呢？就是瀑布模式中的等待浪费。

UserStory编写格式

基本的格式模板

在这个格式中主要包含3个点，一个是基本的用户故事描述，还有优先级和工作量估算。

进阶的基本格式模板

在这个进阶的格式中添加了规则描述，来进一步对用户故事描述进行细化。添加了Given..When...Then的内容用来支持BDD，设计方案的附件链接和上线检查清单Definition of Done（DOD）。

高级格式模板

这是个更完整的用户故事格式，在这里引入了Acceptance Criteria验收标准。验收标准可以认为是对需求的明确条目化步骤，是测试用例的基础。而DOD是更加明确的验收标准，所需要满足的具体要求。

可以看到用户故事的格式升级在逐步的规范和明细被实现的对象，敏捷不是说不要文档，而是做合适的文档，在这个阶段测试就可以提前介入。

UserStory中的优先级与故事点数

一个项目一般有很多用户故事，如果要一次都实现它们就会变成瀑布模式，所以为了选择更有价值的内容交付，我们需要为用户故事排列优先级和工作量。通过优先级安排那些应该先做（后面会提及的用户故事迭代计划）和每一个大概要做多久（合理安排每次迭代的周期和完成内容），这两个都是团队共通讨论设定的。

1.优先级的排列

一般在敏捷中优先级的排列都是基于卡诺或者是莫斯科法则的。简单说就是把需求分为令人振奋的，必备的，可选的这些分类，然后通过大家讨论来确定需求的归属。

2.故事点数的估算

在敏捷中故事点数的估算也是基于经验的讨论（亲和估算，宽带德尔菲），由所有参与者分别估算自己部分的工作时间，如果同类误差过大那么再次讨论，从而获取一个相对大家可以接受的故事点数。

注意：故事点数和工时还是有点区别的，故事点数只是用来区别不同需求的规模，并不完全等同于工作时间，一般会说一个工作点数大于4个工时。

备注：比较常见的解决争论的方法是使用敏捷扑克，通过出牌的形式来同步大家的想法。

UserStory实例化、验收标准与完成定义

用户故事本身还是一个抽象过的概念，但是它仍然有它的缺点，就和编写面向对象代码一样，它还是个类！所以实例化的概念就来了，到了具体的用户怎么做操作来实现对应的价值。由于用户故事是从用户来的，角色成为了用户故事实例化的基础。

实例化的关键在于构造什么样的用户，是一个普通用户还是个"特殊"的用户，是一个前台用户还是一个后台用户，都决定了用户故事实例化的内容。

例如，用户故事：

用户需要一个学习平台来整理自己的学习过程，从而获取学习成果，评估自己的学习效果。

那么对应的实例化可能就是：

小明是一个普通的学生，在学习数学，他需要一个学习平台来整理自己的学习过程，从而获取学习成功，进一步评估自己的学习效果。

小张是一个管理员，他需要在后台可以管理每个普通学员在学习时的信息，帮助学员调整。

小李是个学霸，在学习数学，他需要一个平台来自动查询自己还没做过的题目及找到最新的题目给自己获取挑战。

这里的例子里面用户故事还是比较初略的，所以还需要进一步细化用户故事，从而明确具体的操作步骤。

Acceptance Criteria 验收标准

和实例化的区别是验收标准是针对事的，我们在对该用户故事的具体操作中是怎么样的是验收标准的关键。

例如，验收标准：

1.用户需要通过实名制认证才能使用系统进行学习。

2.系统支持免费和付费两种模式。

3.系统提供对老师的评价功能。

更多的时候验收标准像是一个比较宽泛的测试用例，其核心包括一个Happy Path正向业务流程和多个异常业务流程说明。更加细节的用例一般会通过Xmind类的思维导图形式来记录，而这些内容都会和用户故事及用户故事对应的代码特性分支关联。

Definition of Done 完成定义

完成定义可以帮助开发者更加具体的了解整个用户故事交付时所需要验证的内容。从某些角度可以认为DOD是测试方案的一种展现，作为一个测试来说应该在用户故事上进行测试方案内容的编写，例如：

1.完成功能测试

2.性能测试接口能够达到100tps

UserStory实例化、验收标准与完成定义

光有用户故事是不够的，因为它们还是散开的一个个故事点，一个应用是很多用户故事组成的，为了能够有效了解应用的需求，这个时候就需要用户故事地图了。

用户故事地图可以更加全面的看到整个故事的完整结构（可以认为一个游乐场是一个地图，里面有很多的游乐项目是用户故事卡片），通过设计横向的用户使用流程作为用户故事地图的骨干，再将每个使用流程下的功能按照优先级排列，从而行程一眼就能看完整个系统的功能地图。

通过用户故事地图可以完整的看到系统的组成，但是在敏捷下我们需要迭代式的分批开发，所以接着就要根据情况要在用户故事地图的基础上进一步添加迭代规划，确保分批交付整个用户故事。

在这个过程中每一次迭代都会交付对应的内容，而在这个内容中就需要构建用户故事骨干，来明确组成最后软件的核心结构。每一次迭代都遵守MVP（Minimum Viable Product）最小化可行产品的原则，尽快给用户展示最终的产品并且获取对应的反馈，进一步在下一次迭代中调整需要交付的功能特性。

作为一个优秀的敏捷测试工程师，尽早介入用户故事，帮助制定合理的验收标准、完成标准、用户故事大小及迭代发布计划，这样能够很好的帮助自己规划测试内容，明确测试目标，提高测试质量与效率。这也是敏捷测试下测试左移的关键内容。

kanban看板看出名堂

在具体工作中，往往由于流程长，出现了问题很难定位和解决，如果想要发现、定位、分析问题，借助看板是最佳选择。kanban是一个非常好帮助可视化的东西，而且看板可以帮助管理UserStory。

看板管理，常作“Kanban管理”（来自日语“看板”，カンバン，日语罗马拼写：Kanban），是丰田生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具。及时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。

看板提供了状态迁移可视化的过程，帮助我们了解完成一个事情的过程，最基本的版本包括，to do、doing、done三个阶段。

接着把自己要做的事情作为一个小卡片放在看板的各个阶段上，通过改变push为pull的形式（拉动模式），让下游自己决定自己要做的内容，提高执行效率。也就是说作为doing阶段的任务都完成了，那么应该去看看上游To Do阶段的内容，来拉取自身想要的任务。

在使用看板的时候要根据具体的需要添加状态，设置各个状态的准入准则，进一步构建多跟泳道来让一个状态上可以同时处理多种类型的任务，再进一步限制在制品，让看板上的价值快速流动。这些都是看板管理的常见步骤和实践。

通过看板状态（增加状态）变化的时间监控，就可以很好的获得度量数据，了解团队在软件开发中的各个阶段的时间长度。

如果通过看板来管理用户故事（价值）配合合理的拆解过程，将过程可视化，就可以通过累积流图来非常清楚的掌握项目执行的过程。

在这个图中阶段之间的距离越短，斜率越高越好。累积流图和燃尽图比甘特图能够更好的反应项目的速率和状态，帮助快快速定位开发中的问题，及时调整。

在整个看板中作为测试人员需要添加不同阶段上的测试过程，并且配置自己的任务卡片，帮助团队了解测试所需要占用的资源及任务。在大多数情况下通过看板跟踪可以发现项目瓶颈在测试阶段，而导致的原因就是测试执行的瀑布化（缺乏提前测试设计的并行化以及测试执行效率、环境的问题）。

例如在上图的看板中，我们可以发现测试中的卡片数过多了（5/4最大4个并行卡片任务），那么这里就意味着出现了瓶颈，控制在同一阶段的Work In Process Wip在制品是提高看板流动效率的一个非常有效的手段，在DevOps是通过单件流One-piece Flow的理想概念来实现的。

其次在上图的看板中还能发现完全没有任务的状态，那么这就是等待的状态，上游为何没有提供可以pull的任务是规划的问题。

看板是一个非常好的信息发射源，帮助参与的所有人了解互相工作的内容，配合共通责任的文化，大大加速问题发现和解决的效率。所以每日站会要kanban配合会达到更好的效果。而测试作为团队的一份子，掌握和熟练使用看板也是必备技能之一。

Scrum流程体系

敏捷不是Scrum，这是我最想说的一句话，但是Scrum是我们最常见的敏捷实践模型。通过335（3个角色、3个交付物、5个事件）的几个核心规则，将敏捷的落地流程及关键交付和组织勾勒了出来。

Scrum的流程是比较好说清楚，是一个迭代的过程

主要流程为：

1.确定Product Backlog，这是已经确认了价值大小内容。

2.团队在Sprint计划会议中根据团队的处理能力和故事的MVP生成的规划的Sprint Backlog

3.在团队中进行迭代快速开发（每日站会跟进）

4.定期开展Sprint迭代回顾会议，评估当前的进度

5.完成本次Sprint Backlog的内容后完成迭代交付，判断是否要开展总结大会后，重新开始步骤2。

在整个Scrum活动中，测试进成为了研发团队的一份子（5-9人团队规模），测试是必须要参加Sprint Planning Meeting，Daily Meeting和Sprint Review Meeting的。

Scrum中的最佳实践谈到了TDD对于产品质量的重要性，但是并没有提怎么做好测试。在前面用户故事的有效介入中，我们可以看到用户故事迭代计划和Scrum Sprint计划的一致性，在进入迭代后如何在2-4周的周期内完成这些用户故事的发布可以通过看板来进行任务流动的管理，而进一步发现自动化或者非自动化测试在迭代中的优缺点，及时交付用户价值。

DevOps所带来的价值流

DevOps从表面上是将开发和运维两个工作整合的名词，其实是将敏捷Dev team和Ops的打通。在前面的看板中我们可以看到流动的价值（用户故事），DevOps的看板中需要加上运维端的发布。

在Devops提出了三步法则（持续流动、持续反馈、持续改进）

1.持续流动

持续流动进一步推动了敏捷的范围，也就是能交付的内容在没有交付到生产环境上仍然存在问题的，所以要将发布上线也加入流动过程中。而上线的内容是否开放是通过特性开关和灰度发布来实现的。

在WIP制品的概念下，当同时处理多件事情的时候，没有交付的内容都是在制品还是没有价值的。通过One-piece-flow的单件流概念，严格控制WIP（Work-in-Progress），从而提高流动速度。

2.持续反馈

持续反馈在流动基础上进行了度量，通过全生命周期的反馈，来确保每一步都是JKK100%质量达标的优质品。

3.持续改进

通过度量数据的文化和工作优化。

在DevOps中CI&CD的自动化是非常重要的基础，所以DevOps持续交付流水线成为了大家接地气的核心内容。从代码分支到单测集成、环境发布、自动化测试、打包发布，完全自动化。

而在DevOps中，测试开发成为了一个非常重要的技能，将测试任务尽可能的自动化与流水线集成，从而大大提高流水线上的测试效率。

从研发角度修改一行代码，做一个环境发布或者申请自动化都并不是一件很难的事情。其不难的原因是它是已知需求已知解决方案，对于测试来说就完全不一样了，一个小的变化所带来的影响范围是很难评估并且难于掌控的，需要大量的测试脚本来评估影响。所以当团队已经做到了DevOps化后，测试的瓶颈就进一步爆发了，如何让开发出来的内容更加规范，能够赋能给开发团队自行测试，这是作为测试人员摆脱依附状态的挑战与机遇。