敏捷软件测试与团队协作

2011 年 8 月 26 日

敏捷宣言

• 个体和合作 胜过 过程和工具 • 可以工作的软件 胜过 面面俱到的文档• 客户合作 胜过 合同谈判• 响应变化 胜过 遵循计划

目录

• 一 敏捷测试简介• 二 敏捷测试象限介绍• 三 敏捷测试自动化• 四 编码和测试的关系• 五 我们团队如何引入敏捷测试思想

一 敏捷测试简介

1. 敏捷测试的定义： 首先敏捷测试是敏捷的一种测试，原有测试定义中通过

执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。在传统的测试定义上，还需要添加

敏捷测试是遵循敏捷宣言的一种测试实践：• 强调从客户的角度，即使用系统的用户的角度，来测试系

统• 重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。• 建议尽早开始测试，一旦系统某个层面可测，比如提供模

块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

2. 传统测试与敏捷测试

传统瀑布模型：

需求

设计

编码

测试

发布 时间

敏捷迭代和增量模型

3. 整体团队运作方式

敏捷开发与传统开发的一个最重要的区别是敏捷“整体团队运作”方式。在敏捷中，我们不关心小组或者部门，只关心发布优秀的产品所需的技能和资源。敏捷开发的重心是在一定时间内生产高质量的软件来最大化其业务价值。这是整个团队的工作，并不单单是测试人员或指定的质量保证专家的工作。敏捷团队中的每一个人都将变得“具有测试意识”。

4. 敏捷法则

• 提供持续反馈• 为客户创造价值• 进行面对面的沟通• 勇气• 简单化• 持续改进• 响应变化• 自我组织• 关注人• 享受乐趣

二 敏捷测试象限介绍自动和手动 手动

自动 工具面向技术

面向技术

支持团队

评价产品Q1

Q2Q4Q3

单元测试

组件测试

性能和压力测试

安全性测试

“ 非功能性” 测试

功能测试

实例

用户故事测试

原型

仿真

探索测试

场景可用性测试

用户验收测试（ UAT ）alpha/beta

1. 象限一 象限一代表测试驱动开发，是一个核心的敏捷开发实践。

单元测试验证系统的一小部分的功能，例如一个对象或方法。组件测试验证系统的一大部分的行为，例如提供某些服务的一组类。所有这两类测试一般都使用测试自动化工具，象限一的测试被认为是程序员测试、面向开发人员的测试或者面向技术的测试。

象限一测试的主要目的是测试驱动开发（ TDD ）或者测试驱动设计。首先编写测试的过程帮助程序员更好的设计代码。通过这些测试，程序员可以自信地编写代码来实现用户故事的功能，而不用担心对系统引入意外的改变。这些测试可以验证系统设计和架构是否恰当。

2. 象限二 象限二中的测试确定外部质量和客户需要的功能，为面向业务的测试，也叫面向客户的测试或者客户测试。

像象限一种的测试那样，也驱动开发，但是是在更高的层次上。在敏捷开发中，这些测试来源于客户提供的实例。

象限一和象限二中自动化测试提供的快速反馈形成了敏捷团队的基础，这些测试在每次代码改变或增加的时候运行。这次测试首先指导功能开发，当自动化以后，它们提供了防止重构和引入新的代码的时候，导致不希望的结果的安全网。帮助团队产生客户需要的业务价值。它们验证业务逻辑和用户交互行为与客户提供的实例一致。

3. 象限三

象限三属于面向业务的测试，这些测试使用运行的软件来查看它是否没有达到期望或者能否对抗竞争。通常用户和客户执行这类测试。

探索测试是这个象限的重点，它通过策略和确定限制的动作来指导，用户故事测试和自动化回归集的重要补充，也是一种经过深思熟虑的测试方式，没有测试脚本。当对被测系统了解得越多，就越能够使用这些信息帮助设计新的测试。

4. 象限四

象限四是面向技术的测试，目的是评价产品的性能，健壮性和安全性等特性。尽量想办法在项目早期对其进行性能测试，以保证向工作流中添加越来越多的功能后，测试依然能够继续进行下去。这么做可以及早捕获性能问题并重新设计系统架构以进行改进。

可以通过敏捷准则处理性能测试，以增量的方式构建工具和测试组件，最终的目标是产品在接近发布时不用再管性能测试了。

所以，尽量一开始就进行性能测试，而不是放到产品上线之前。

三 自动化

测试自动化是敏捷的核心实践之一，敏捷项目依赖于自动化。优秀的自动化能帮助团队高效地发布高质量代码。它为团队提供了一种在将速度最大化的同时还能维持高标准的框架。

源代码控制、自动构建和测试套件、部署、监控，以及各种脚本与工具让开发过程不再乏味无聊，同时还保证了可靠性并让团队在工作中保持最佳状态。

1. 为什么要自动化

• 手动测试需要太长的时间• 手动过程容易出错• 自动化让我们有时间做更有价值的工作• 自动化的回归测试提供了安全网• 自动化测试能较早且频繁地提供反馈• 驱动编码的测试和实例可以做更多的事情• 测试提供文档• 自动化的投资回报率高

2. 敏捷测试自动化策略

手动测试

单元测试 / 组件测试

验收测试 （ API层面）

GUI测试

敏捷测试自动化金字塔展示了 3个不同的自动化测试层次。最低一层是基础，它支援其他所有的测试。它主要由健壮的单元测试、组件测试与支持团队的面向技术的测试构成。该层次代表了大多数的自动化测试。在敏捷开发中，我们会尽可能多地向这个层次增加测试。

金字塔的中间层包含了大多数用户支持团队的自动化业务测试。这些功能旨在验证我们“在做正确的事情”。该层次的测试包括“故事”测试、

“验收”测试以及比单元测试范围更广的功能测试。这些测试运行在 API层或GUI层之后，不通过 GUI来直接测试功能。我们编写的测试用例会设定好输入和存根，它会将输入放到产品代码中并接收输出，然后将其与期望结果进行比较。由于这些测试绕过了展现层，因此编写和维护的代价并不高。

金字塔顶层很少使用自动化，这些测试通过 GUI 完成，会使用并操作展现层。我们会在编写完代码后再来编写这些测试，它们主要用户评价产品并成为回归测试套件的一部分。

四 编码和测试的关系

• 团队的每个成员都参与测试任务• 编码和测试是同一个过程的组成部分• 通过简单测试驱动开发，当简单测试通过，编写更复杂

的测试指导开发• 与开发人员紧密合作，使测试和编码集成• 评判产品的测试是开发的一部分• 在需求不明确或者意见不统一时，采取“三方协作”方

式• 让客户贯穿迭代期，尽早并经常让他们审查

五 我们团队如何引入敏捷测试思想

• 培养测试驱动设计意识• 学习并掌握自动化测试工具• 精简冗长繁琐的文档（需求及测试用例）• 有意识的让测试先行（在项目一开始启动性能测试，迭

代开发的同时进行迭代测试，增量测试）• 迭代开发中控制并减少缺陷，减少技术债务• 所有项目成员均参与测试• 结对开发与结对测试• 加强团队沟通与协作，每天的站立会议，进度汇报，代

码审查