敏捷测试的挑战

AlexQin

敏捷测试的挑战之七：用什么质量标准来度量敏捷项目？

其中一个最好的质量标准是发布后逃逸的bug数量。不辛的是，这是个事后的衡量标准。

采用每个迭代后计算逃逸bug数量的方法能标识代码的质量。

我们还可以从bug学习到很多东西：

1、 是否有些类型的bug在可接受性测试中发现的，其实是可以在单元测试就发现呢？如果是，把它加入到单元测试。

2、 我们是否能让bug的发现过程或bug的诊断更简单？

3、 我们是否能让程序员不那么容易犯这种普通的错误？

AlexQin

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

伴随着频繁的迭代，我们需要频繁地重新测试，单元测试是不足够的。我们怎样有效地进行用户层面的回归测试呢？

你不一定需要在每次的迭代都做完整的回归测试。可以每个迭代运行一部分的测试。需要某种程度上的用户层次的自动化回归测试。

AlexQin

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

大部分的商业测试工具在敏捷环境下都不是很好用。大部分有这些缺点：

1、 指定的语言

大部分商业测试工具会指定某种语言，例如：WinRunner（TSL）、SilkTest（4test）、Robot（Test Basic），但是一些新的工具也开始使用标准语言，例如：Astra QuickTest（VB Script），XDE Tester（Java）

参考http://www.stickyminds.com/se/S2326.asp

2、 与源代码控制的结合不好

很多工具没有与源代码控制工具集成，使用临时文件和目录（WinRunner），参考http://paulhammant.com/blog/000245.html

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

3、 很难与持续集成配合使用

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

4、 不能在所有机器上部署（受License限制）

受限制的、昂贵的License，使得很多开发人员不能例如工具运行测试

这些问题使得他们对于整个团队来讲不够实用。敏捷团队倾向于构建自己的测试工具和利用开源工具。

AlexQin

开源测试工具

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

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

Agile Testing Papers
http://www.testing.com/agile
“Where are the Testers in XP?”
http://www.stickyminds.com/s.asp?F=S6217_COL_
Mailing List
http://groups.yahoo.com/group/agile-testing/

AlexQin

good job