敏捷开发中的敏捷测试《敏捷测试全攻略》.doc

敏捷测试全攻略

目录
敏捷开发中的软件测试 ................................................................................................................... 3
什么是敏捷测试？ ................................................................................................................... 3
敏捷测试中测试人员扮演的角色 ...... 3
单元测试和可接受性测试 ....................................................................................................... 3
测试人员是否应该拥抱敏捷开发？ .......................................................................... 3
敏捷测试实践 ........................................................................................................................... 4
敏捷测试的挑战 ............................................................................................................................... 4
什么是敏捷开发 ................................................................................................................... 4
为什么以前的开发模式不再适用？ ....................................................................................... 5
测试的作用 ................................................................ 5
敏捷测试的挑战之一：测试员是否不再需要了？ ............................................................... 5
敏捷测试的挑战之二：测试不完整的软件 ........................................................................... 5
敏捷测试的挑战之三：可接受性测试是否过于简单了？ .................. 5
敏捷测试的挑战之四：把测试员作为项目组的一部分 ....................................................... 6
敏捷测试的挑战之五：测试什么时候完成？ ....................................................................... 6
敏捷测试的挑战之六：我们还需要bug跟踪系统吗？ ....................................................... 6
敏捷测试的挑战之七：用什么质量标准来度量敏捷项目 ................................................... 6
敏捷测试的挑战之七：回归测试 ........................................................................................... 7
敏捷测试的挑战之八：回归测试工具 ................................................................................... 7
敏捷测试用例设计 ........................................................................................................................... 8
测试用例的粒度 ....................................................................................................................... 8
基于需求的测试用例设计 ................... 9
测试用例的评价 ....................................................................................................................... 9
测试用例数据生成的自动化 .................................................................. 10
敏捷自动化测试 ............................................................................................................................. 10
公式化的典型的自动化测试过程 ......................................................................................... 10
敏捷自动化测试的原则 ... 11
工具支持测试 ......................................................................................................................... 11
到处是工具 .................................................... 12
“工具铁匠”的任务 ................................................................................................................. 12
测试员可能会问“工具铁匠”的问题 ........................................................................... 12
管理敏捷自动化测试 ............................................................................................................. 12
敏捷测试指引（1）-简介 .............................................................................................................. 13
敏捷测试指引（2）-测试与例子............... 14
敏捷测试指引（3）- 用面向技术的例子支援程序员 ................................................................ 16
敏捷测试指引（4）- 用面向业务的例子支援项目组 ................................................................ 18
激发出正确的代码 .......... 18
促进项目交流 ......................................................................................................................... 18
让可能发生的更加明显 .............................................. 19
敏捷测试指引（5）- 用面向业务的例子批判产品 .................................................................... 20
敏捷测试指引（6）- 用面向技术的例子批判产品 .................................................................... 21
敏捷测试指引（7）- 敏捷项目中的测试员 .................. 22
敏捷开发中的7种测试类型 ......................................................................................................... 25

敏捷开发中的软件测试

参考：Bret Pettichord 的《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

敏捷宣言：

个体和交互比过程和工具更有价值；
能工作的软件比全面的文档更有价值；
顾客的协作比合同谈判更有价值；
及时响应变更比遵循计划更有价值。- www.agilemanifesto.org

什么是敏捷测试？

测试遵循敏捷宣言进行，把开发作为顾客看待。项目的测试采用敏捷方法论。
敏捷测试的原则与上下文驱动测试（Context-Driven Testing：www.context-driven-）
的原则有交集，例如，上下文驱动测试的七大原则中的第三条：工作在一起的项目组成员是
项目的上下文的最重要的组成部分。就与敏捷宣言中的“个体和交互比过程和工具更有价值”
一样强调人的作用。

敏捷测试中测试人员扮演的角色

1、 测试是项目的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。
2、 测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。
3、 “BUG”是让用户感觉烦恼的东西，测试人员不作出发布的决定。
4、 测试员不保证质量，整个项目组对质量负责。
5、 测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。

单元测试和可接受性测试

测试驱动开发，开发人员在写代码之前要先写单元测试，用于激发代码的编写、改进设计（降
低耦合度，增加内聚）、支持重构。很多开源的测试工具支持单元测试（xUnit）。
用户故事是需要编码实现的功能特性的简短的描述。可接受性测试验证用户故事的完整性。
理想的情况下，用户故事是在代码编写前就写完。

测试人员是否应该拥抱敏捷开发？

有些人说XP会导致差的质量并且是偷懒的借口。我认为XP是令人激动的，并将在行业中
改进测试的实践。

参见《Testers Should Embrace Agile Programming 》
（ ）

敏捷测试实践

通过对话产生测试，谁来测试？客户往往太忙了，不可能参与测试。定义测试是很关键的活
动，应该把开发人员和顾客代表包括进来，不要只是测试员自己做。
把用户故事转换成测试。测试提供的是目标和指南、及时的反馈、进度度量。测试应该用指
定的格式出现，以便让用户或顾客能清楚明白，还要足够的明确，以便能被执行。
开发人员负责提供支持自动化测试的特性。大部分情况下，为产品添加测试接口，而尽量不
用外部测试工具。
计划在每个迭代中探索产品，寻找bug、遗漏的特性和改进的机会。

进一步学习

Lessons Learned in Software Testing -
Ward Cunningham’s acceptance testing framework -
Agile Testing Papers -

敏捷测试的挑战

参考：Bret Pettichord 的《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

我们从上下文驱动测试的七大原则(www.context-driven-)可以看出，上下文驱动
测试倾向于快速的反馈和适应变化的环境。所以上下文驱动测试的很多原则和做法可以应用
到敏捷开发的软件测试中来。

什么是敏捷开发？

敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到
系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。
迭代包括需求的开发和测试，典型的迭代周期是2周。目标随着从上一次的迭代中学到的东
西、反馈以及商业机会而调整。
在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。
定义好接受标准，开发直到单元测试和接受测试通过才算完成。
敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。
在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），
持续地进行回归测试。

为什么以前的开发模式不再适用？

以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因
素的影响经常改变。
以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段
会随之而过。
以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。
以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确
性的判断。

测试的作用

有价值的东西有么提供产品，要么提供服务。那么测试提供什么产品或服务呢？有人认为测
试提供调试通过的、经过测试的软件。这是错误的回答。测试不提供产品，测试提供信息，
关于开发过程中的软件的状态的信息，以便基于这些信息做出决定。

敏捷测试的挑战之一：测试员是否不再需要了？

既然有开发人员做单元测试了，我们还需要测试员吗？有些项目团队采用了敏捷开发方式后
把测试员都给解雇了，然后过了不久他们就后悔了。
测试可以是除QA或测试员外的人来做，例如业务分析员，有些项目团队让开发人员来做接
受性测试。
但是有专门的测试员带来两个好处：
1、 专注于用户使用而不是软件的技术实现
2、 专注于发现软件的错误而不是证明完整性

敏捷测试的挑战之二：测试不完整的软件

频繁的迭代产生的测试版本很多时候是不完整的，测试员如何测试这些不完整的代码呢？
“故事”应该从业务价值方面来定义。一个“故事”应该在一个迭代周期内完成。好的“故
事”是不容易定义出来的，但是差的故事对测试人员的影响比对开发人员的影响还要大。有
时候测试人员需要帮助定义“故事”。

敏捷测试的挑战之三：可接受性测试是否过于简单了？

测试人员如果只是做可接受性测试，只是验证“故事”是否完整，岂不是太简单了？这样怎
么能做好测试呢？
其实，每一个迭代都需要额外的测试，而不仅仅是局限于验证“故事的完整性。

在迭代测试中还要按需进行下面类型的测试 ：
探索性测试：同时学习系统、计划和执行测试，寻找bug、遗漏的特性和改进的机会。
组合交互测试：专注于特性之间的交互。
场景测试：模拟真实世界的场景进行测试。
疲劳测试：长时间地执行软件
业务循环测试：基于月末、季度末等业务循环的边界来执行场景
压力测试：对系统施加强大的压力进行测试

敏捷测试的挑战之四：把测试员作为项目组的一部分

把测试员作为项目组中的一员不是牺牲了他们作为一个组织的完整性吗？
测试员一直被认为是受压迫的对象，经常坐在一起互相诉苦、互相支持。现在是时候结束这
种情况了测试员应该跟开发人员和分析师坐在一起，当项目组中有更多的正式或非正式的
沟通时才有可能达到敏捷。

敏捷测试的挑战之五：测试什么时候完成？

没有专门分配的时间来完成测试，我们怎么知道什么时候测试应该结束？
敏捷测试员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的
优先级一致。BUG列表也提供了测试完整性的提示。
一个好的测试员是永远都能找到需要完成的测试来做的。
为什么需要跟开发人员结对进行测试呢？因为开发人员对潜在的错误有一定的洞察力，测试
员对约束和错误的时机有一定的洞察力。而他们在一起能使自动化测试更加成功。
测试员应该自动化可接受性测试，使用与开发环境一样的编程语言来编写可接受性测试的代
码，重用单元测试的框架，使软件更加可测。
利用“灰盒”测试。设法弄清楚系统各模块之间的关系，分析变更的影响，看什么是需要测
试的，什么是可以不测试的。弄清楚bug，bug的表面现象是什么？产生bug的根本原因是
什么？弄清楚风险，使用解决风险的测试策略，调整测试目标。

敏捷测试的挑战之六：我们还需要bug跟踪系统吗？

有些人说敏捷团队不需要跟踪bug，只需要把发现的bug尽快修正就行了。
这种做法只适用于开发过程的测试，如果是一个完整迭代的测试，你就需要bug跟踪系统，
因为有些bug不是在这个迭代马上修改的。

敏捷测试的挑战之七：用什么质量标准来度量敏捷项目
其中一个最好的质量标准是发布后逃逸的bug数量。不辛的是，这是个事后的衡量标准。
采用每个迭代后计算逃逸bug数量的方法能标识代码的质量。

我们还可以从bug学习到很多东西：
1、 是否有些类型的bug在可接受性测试中发现的，其实是可以在单元测试就发现呢？如果
是，把它加入到单元测试。
2、 我们是否能让bug的发现过程或bug的诊断更简单？
3、 我们是否能让程序员不那么容易犯这种普通的错误？

敏捷测试的挑战之八：回归测试

伴随着频繁的迭代，我们需要频繁地重新测试，单元测试是不足够的。我们怎样有效地进行
用户层面的回归测试呢？
你不一定需要在每次的迭代都做完整的回归测试。可以每个迭代运行一部分的测试。需要某
种程度上的用户层次的自动化回归测试。

敏捷测试的挑战之九：回归测试工具

大部分的商业测试工具在敏捷环境下都不是很好用。大部分有这些缺点：
1、 指定的语言
大部分商业测试工具会指定某种语言，例如：WinRunner（TSL）、SilkTest（4test）、Robot（Test Basic），但是一些新的工具也开始使用标准语言，例如：Astra QuickTest（VB Script），XDE Tester（Java）
参考

2、 与源代码控制的结合不好
很多工具没有与源代码控制工具集成，使用临时文件和目录（WinRunner），参考

关键信息存储在Repositories中，例如Rational

3、 很难与持续集成配合使用
缺乏外部调用的API，不允许作为一个库被使用，因此很难与持续集成整合在一起。一些新
的工具则有所改进，例如TestComplete

4、 不能在所有机器上部署（受License限制）
受限制的、昂贵的License，使得很多开发人员不能例如工具运行测试
这些问题使得他们对于整个团队来讲不够实用。敏捷团队倾向于构建自己的测试工具和利用
开源工具。

开源测试工具

现在已经出现很多开源的测试工具，支持windows、Java、Web等平台，现在大部分都集中
在web平台，例如:HttpUnit、WTR等。

关于Agile Testing，可以参考以下资料：
.Agile Testing Papers

.“Where are the Testers in XP?”

.Mailing List

敏捷测试用例设计

敏捷宣言：
个体和交互比过程和工具更有价值；
能工作的软件比全面的文档更有价值；
顾客的协作比合同谈判更有价值；
及时响应变更比遵循计划更有价值。
- www.agilemanifesto.org

并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM
等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认
为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。
测试用例的设计是其中一项。

测试用例的粒度

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出
要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品
的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机
维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体
到界面元素的操作步骤，指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问
题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测
试人员的思维。

测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没
有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中
作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的
本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下
来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的
关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况
来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏
捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一
敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求
是软件的根本，验证对需求的覆盖是软件测试的根本目的。

要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your
Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该
把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶
段都要回来重新审视和完善测试用例。

测试用例的评价

测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各
种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，
尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交
互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完
成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总
会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体
现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在
于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部
可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程
序员了。

因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终
用户或顾客代表，还有开发人员。

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设
计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过
滤筛选、大批量数据的生成等都是计算机擅长的工作。

很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例
的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不
可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在
这方面可利用正交表设计数据或成对组合法设计数据。

可利用一些工具，例如TConfig、PICT等来产生这些数据。

在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。
大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用
工具生成。

工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但
是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory
等。

敏捷自动化测试
原文：Agile Test Automation – James bach

公式化的典型的自动化测试过程

1、 购买一个昂贵的GUI测试执行工具（例如 Rational、Mercury、Compuware等）
2、 定义很多测试用例
3、 招聘一个自动化测试组实现每个测试用例的自动化执行
4、 构建一个完整的测试库和框架
5、 不断地完善和修正

如果你的产品很容易测试并且变更不大的话，以上方式很适合。但是关于自动化测试，我们
为什么想得那么狭窄？
尝试把自动化测试想成是“任何使用工具来支持测试”。敏捷自动化测试就是把敏捷开发的
原则应用在测试自动化上。

敏捷自动化测试的原则
1、测试自动化意味着使用工具支持测试项目的各个方面，不仅仅是测试执行方面。
2、当测试自动化得到指定的程序员（toolsmiths-“工具铁匠”）支持时，会不断地顺利进行。
3、“工具铁匠”由测试员领导。
4、“工具铁匠”收集并应用各种各样的工具来支持测试。
5、“工具铁匠”帮助实现可测特性并“打造”工具以便利用这些可测特性。
6、 组织实现测试自动化是为了完成某个短期的目标。
7、 避免盲目进行长期的自动化测试任务，而不是基于业务场景的分析。

工具支持测试
1、 测试创建（数据和脚本的产生）
工具可以产生特定的数据，例如：随机的Email信息，或产生数据库，或产生组合参数来覆
盖我们的测试。
2、 系统配置
工具可以保持或重现系统参数，把系统设置到某个特定的状态，或创建或回滚到一个“ghost”
的磁盘
3、 模拟
工具可以为测试模拟一些不具备的环境条件，这些环境可能会很难出现或提供起来很昂贵。
4、 测试执行
工具可以操作软件系统本身，模拟用户的GUI操作或绕过GUI层直接使用某些测试接口。
5、 问题分析
工具可以使某些不可见的东西可见。稳定地分析产品或分析log文件，或监视系统参数。
6、“预言”
“预言”是通过某些机制来判断错误或成功。工具可以自动地判断产品的某些类型的错误条
件。
7、记录和覆盖分析
工具可以帮助记录测试过程覆盖的地方和未覆盖的地方。
8、 试管理
工具可以记录测试结果，组织测试用例。

到处是工具
1、 MSDN库
2、 微软的很多开发工具都包括很多有用的小工具
3、 微软兼容性工具包和其他免费工具（）
4、 基于网页的测试资源（HTML checkers、accessibility analyzers等）
5、 widows资源包
6、 脚本语言（例如：Perl、Ruby、TCL）和相关库
7、 共享资源库（）
8、 操作系统监视工具（）
9、 开源测试软件（www.opensourcetesting.org）
10、探索性测试的监视软件（）
11、项目组其他人正在使用的工具

“工具铁匠”的任务

1、 快速响应测试员的请求并提供协助
2、 查找影响测试效率的问题
3、 调查测试员关心的问题的可能的解决方案
4、 应用技术改进测试过程
5、 提供产品的可测性功能特性
6、 研究工具并学习怎样使用
7、 收集开发人员或测试员创建的工具
8、 对产品进行评审以便计划自动化的可能性

测试员可能会问“工具铁匠”的问题

1、 我怎样测试这个新的功能？
2、 我如何才能看到产品内部做了什么？
3、 我如何判断测试是否通过？
4、 有没有办法让我能自动地执行这些操作？
5、 有没有办法让bug重现更加容易些？
6、 帮助我调查这些bug
7、 这里有一个测试要执行，你能否帮助我产生1000个变量？
8、 我的测试覆盖了产品的多少地方？
9、 我想对产品进行压力测试，是否有什么工具可以使用？

管理敏捷自动化测试

1、 请求清单
请求清单是测试员发出的自动化测试要求
2、 任务清单
任务清单是每位“工具铁匠”收到的分派任务
3、 移交清单
移交清单是目前被测试组使用的解决方案。每个都包括解决方案对测试效率的影响的简要描
述
4、 维护清单
维护清单是需要改进的解决方案的清单。可以考虑把它分成两部分：关键维护和增强维护。
5、 障碍清单
障碍清单是所有尚未解决的影响测试效率的问题清单。这些问题需要新的昂贵的工具、实际
的可测试性改进、或者需要更多工作而难以在短期实现

对于一个大型的测试组来说，至少需要一名“工具铁匠”，但是不要把所有测试员都作为“工
具铁匠”，因为这样做的成本太高，这样所有测试员都要像“工具铁匠”一样思考问题。

敏捷测试指引（1）-简介

原文：Agile Testing Directions – Introduction （Brian Marick）

在XP Agile Universe上，两个人-或许更多-告诉我说，我在敏捷测试的发展方面贡献不够。
我在过去5年里花了太多的时间说我不知道敏捷测试会怎样，没有足够的指示和指导。“但
是让我们看看，也许我们可以找到。”他们可能是对的。因此我让本文作为这方面的一个起
点。

我先重申一些普遍的概念区别，以作为起点。

如果你听到别人在谈论敏捷项目中的测试，问一下那些测试是面向业务的还是面向技术的，
会对你有很大的帮助。面向业务的测试是你可以用一个业务专家感兴趣的术语来向他描述测
试。如果你通过电话描述测试回