敏捷测试的挑战

什么是敏捷开发？         敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。迭代包括需求的开发和测试，典型的迭代周期是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）参考http://www.stickyminds.com/se/S2326.asp 2、 与源代码控制的结合不好
        很多工具没有与源代码控制工具集成，使用临时文件和目录（WinRunner），
        关键信息存储在Repositories中，例如Rational 3、 很难与持续集成配合使用
        缺乏外部调用的API，不允许作为一个库被使用，因此很难与持续集成整合在一起。一些新的工具则有所改进，例如TestComplete 4、 不能在所有机器上部署（受License限制）
        受限制的、昂贵的License，使得很多开发人员不能例如工具运行测试         这些问题使得他们对于整个团队来讲不够实用。敏捷团队倾向于构建自己的测试工具和利用开源工具。开源测试工具
        现在已经出现很多开源的测试工具，支持windows、Java、Web等平台，现在大部分都集中在web平台，例如:HttpUnit、WTR等。

原文转自：http://www.ltesting.net