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

　　把测试员作为项目组中的一员不是牺牲了他们作为一个组织的完整性吗？

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

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

　　没有专门分配的时间来完成测试，我们怎么知道什么时候测试应该结束？

　　敏捷测试员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的优先级一致。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）

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

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

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

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

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

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

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

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

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

　　开源测试工具

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

注:本文由会员liudong首发于51Testing软件测试论坛