细说敏捷测试-敏捷实战中的探索-京东云开发者社区

### 1 什么是敏捷？

敏捷开发是一种思想或方法论，就是通过不断迭代开发和增量发布，最终交付符合用户价值的产品

敏捷思想源于最初的《敏捷宣言》：

【敏捷软件开发宣言】

- 个体和互动高于流程和工具；
- 工作的软件高于详尽的文档；
- 客户合作高于合同谈判；
- 响应变化高于遵循计划；

《敏捷宣言》代表敏捷的价值观，敏捷开发原则则帮助我们通过更灵活的方式思考开发方法和组织；具体十二条敏捷开发原则：

1. 我们最重要的目标是通过持续不断地快速交付有价值的软件使客户满意；
2. 欣然面对需求变化，即使在 开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好、效率最高的方式是面对面交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其不掉稳定、延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是激励减少不表要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何提高成效，并依此调整自身的举止表现。

敏捷开发模式

![](//img1.jcloudcs.com/developer.jdcloud.com/cd94fba4-6ca0-4b94-a7bd-afeebc7759a020221012164924.png)

### 2 什么是敏捷测试？

‘敏捷测试’既不是一种测试方法，又不是一种测试方式，而是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付，涵盖所需的、正确的价值观、思维方式、测试流程，一系列优秀的测试实践和更适合的测试环境，以及自动化测试框架和工具。

敏捷测试可以采用目前已有的各种测试方式，与传统测试相比，侧重点有所不同，主要的差别是价值观、思维方式、流程和实践等。

敏捷测试包括（但不限于）的测试活动：在工作中用具体的实例指导开发人员做测试，评审测试想法和假设，开发测试自动化，执行探索性测试，执行验证质量属性的测试，如性能、可靠性、安全性等。

#### 2.1 传统测试和敏捷测试的差别

![](//img1.jcloudcs.com/developer.jdcloud.com/68f9be24-2b30-48f9-b5fd-0040a49534ab20221012164959.png)

### 3 敏捷思维方式

包括 成长性思维、团队对质量负责的思维 上下为驱动的思维与用户思维

#### 3.1 成长性思维

成长性思维其宗旨是“请相信，你可以进步”，拥有成长性思维的人相信人的能力是可以被培养的，总是努力并不断成长；可以接受失败，但不会成为失败者，充满自信，内心有力量，认为今天的失败不代表明天会失败，相信自己的潜力是未知的，一定能克服困难，于是越战越勇，最终走向成功；

拥有成长性思维的测试工程师和拥有固定性思维的测试工程师的对比

![](//img1.jcloudcs.com/developer.jdcloud.com/71c3e2c3-39e9-41f2-8117-78908eb645a320221012165246.png)

#### 3.2 对团队质量负责的思维

敏捷中，我们强调的是共担

测试人员守护质量，提供质量信息，甚至帮助团队改进质量，自然很有价值，但是如果依赖测试来保证质量，那么其实是很难保证质量的，而且成本很高。应该让整个团队关注质量，从需求开始尽可能一次把事情做对，从而构建出高质量的产品，这对企业来讲更有价值效率更高成本更低。

#### 3.3 上下文驱动的思维

在敏捷测试中要认识到上下文是一直在变的，测试策略和方法也要根据上下文几时调整，不断优化，尽可能达到更有效、更高效的测试状态；上下文可以简单地理解为项目所处的环境，包括人员、风险变化、研发状态和质量标准等。

#### 3.4 用户思维

从用户视角出发，从用户故事角度思考的思维方式；

### 4 scrum 模式下的 测试流程

![](//img1.jcloudcs.com/developer.jdcloud.com/b4416913-732b-4c16-a226-1d4b4011ae6f20221012165451.png)

Scrum模式下的敏捷测试六层有7项活动：测试的分析与定义、测试计划、测试设计、BVT、持续测试、版本验收测试以及测试交付与反思，但是不能理解位7个阶段，许多互动都是并行的，包括计划、设计都是贯穿整个迭代的。

1. 测试分析与定义，对用户故事进行需求评审，为每一个用户故事建立验收标准，确保它具有可测试性，并从业务需求触发，了解要做哪些测试，初步界定测试范围
2. 测试计划，这里指当前迭代的测试计划，包括进一步明确具体的业务要求和质量标准，制定测试目标，明确测试范围和测试项，分解测试字母表识别出测试风险并制定测试策略等。计划是一个覆盖整个迭代的过程，也就是前面所说的，要基于上下文不断调整或优化测试计划，只是在迭代计划时先写出初步的测试计划，按照计划开始执行后续的测试过程。
3. 测试设计，这里强调的是粗粒度的测试设计，包括事件流图、状态图等
4. BVT（build verification testing）版本构建测试，每日构建或代码提交触发的软件版本构建，需要对软件版本进行自动验证，只有高成功率的持续集成才有意义。
5. 不但包括传统的冒烟测试，也包括代码扫描，检查代码规范性，安全性等 静态代码分析。
6. 持续测试是在迭代中的主要活动，包括设计评审、单元测试、用户故事实现的验证和集成测试等，也包含持续的新功能测试和持续的回归测试，以及性能测试、安全测试、兼容性测试等专项测试
7. 版本验收测试。敏捷的验收测试通常是指对用户故事的验收标准验证。
8. 测试交付与反思。测试交付还包括质量分析，并要回顾、审视整个测试过程，找到测试不加的地方，从而在下一个迭代版本中改进。

### 5 敏捷模式下如何开展测试？

#### 5.1 构建强大的敏捷测试基础设计

持续集成和持续测试
持续集成（continuous integration，CI），在1998年就被列入极限编程的核心时间。2006年 马丁 福勒提出了比较完善的方法和实践：
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，这也就意味着每天可能会发生多次集成，每次集成都通过自动化的构建（测试）来验证，从而尽快发现集成错误。
持续交付（continuous delivery CD ），持续交付是一种能力，能够以可持续方式，安全、快速底把代码编程（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。

在持续集成中的测试活动
通过与自动化测试工具/框架的集成，在持续集成环境中执行自动化测试，但是这里需要考虑持续集成中测试范围和提供快速反馈之间的平衡，一般持续集成自动化测试活动应该只包含 单元测试、代码静态测试和BVT（基本功能验证）

![](//img1.jcloudcs.com/developer.jdcloud.com/68c5f85e-24a7-4f3a-9561-2132ee63712d20221012165532.png)

测试左移：代码评审，有助于提前发现缺陷，提高代码规范性进而促进研发团队知识共享。

#### 5.2 敏捷测试的设计和执行

1）创建DOD
用户故事DOD维度
迭代DOD 维度
发布版本DOD维度

DoD(definition of done) 任务完成的定义。在迭代初为一个迭代建立DOD，并且在迭代完成时检查完成情况。

- 所有代码通过静态检测，严重问题都已修改；
- 所有新增代码得到人工评审；
- 所有完成的用户故事都有对应的测试用例；测试用例都已执行；
- 所有完成的用户故事得到Product Owner的验证。
- ……

2）将用户故事转化成测试场景
3）探索式测试和角色扮演的场景挖掘
4）自动化测试、UI自动化测试

#### 5.3 测试右移

把软件测试从研发阶段延伸到运维阶段，从研发阶段的持续测试延伸到部署上线后的在线监控和在线测试。

1）在线性能测试
- 全链路压测
- 在线性能监控
- 流量回放

2）AB测试
运营分析手段根据用户的不同反馈采取进一步的产品设计方案。

3）监控警告系统
4）安全性监控
5）混沌工程

在受控的情况下，提前发现生产环境中的薄弱环节，提高系统的可用性。但可用性的提高不能完全依赖混沌工程，更为重要的是为系统弹性做好设计。

6）智能运维与测试

### 6 分析测试结果和评估测试工作的质量

1）需要度量哪些方面：
测试质量（测试覆盖率，bug遗漏率）和测试效率（测试用例设计、执行、自动化转化率，缺陷验证周期等）

2）数据驱动改进

- 做好测试过程、产品质量相关的数据收集工作
- 做好数据的抽取与分析
- 度量结果的数据可视化呈现
- 更深入地进行数据挖掘，找出更有价值的数据。

------------

###### 自猿其说Tech-JDL京东物流技术与数据智能部
###### 作者：史松浩