文/赛宝认证中心徐飞

摘要：时下敏捷的概念在开发过程中引起非常多的关注度，那么对于开发过程中的一些特殊的工作是否也存在敏捷过程呢？比如说测试，是否也存在敏捷测试的概念的？如果有敏捷测试的话，那么敏捷测试应该如何操作呢？本文作者就敏捷测试如何开展讲述了一定的看法。

关键字：敏捷测试

1序言

简言之，敏捷测试是指在采用敏捷技术的项目中开展的测试。在传统测试过程看来，测试是为了度量和提高被测软件质量的过程，一个好的测试是指很可能找到尚未发现的错误的测试，而一个成功的测试是指发现了至今未发现的错误的测试。软件测试是对软件建立信心的过程测试是评估软件或系统的品质或能力的一种积极的行为，是对软件质量的度量。测试工程人员经常在抱怨测试工作没有很好的开展是因为：需求频繁变化、文档更新不及时、没有足够的测试时间等等。那么在测试过程中引用敏捷的概念进行测试（敏捷测试），是否可以提高测试的工作效率呢？

在我的理解对应敏捷开发的管理就是敏捷管理，同样对应敏捷开发的测试即是敏捷测试。敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值观：(1)保持简单；(2)以任务为导向，而不以过程或是角色为导向；(3)通过沟通和反馈保证测试能够建立合适的质量标准；(4)尽可能减少测试周期的时间需求。

敏捷管理和敏捷测试同样可以应用到非敏捷开发的项目中去。同样敏捷管理和敏捷测试在敏捷开发中将会得到最大的体现，但能不能管理好和测试好就看你做的是不是真正的敏捷管理和敏捷测试，看你是不是真正的将敏捷的思想融入到管理与测试中去了。

2敏捷测试

2.1敏捷测试核心

敏捷测试要求开发团队在设计阶段之前充分学习该项目的行业知识，从最终用户角度和实际出发充分的挖掘需求。在设计阶段要完成对敏捷设计的灵活性、可扩展性和易维护性的检查，这个工作最好由公司内部的其他架构师来完成，开发人员和测试人员列席并给出意见。在敏捷开发的高度迭代过程中，测试人员需要从以下几个方面考虑测试活动：

首先要从整个项目全局考虑，及早发现需要更改设计的问题，但时间上不能花太久。其实这个测试更多的是去看、去思考，而能不能发现问题就要看你对现有需求吃的是不是透彻，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现客户的商业价值为目标；

然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的缺陷及时反馈给开发人员；

最后在开发人员忙于修改那些优先级较高，难度较大比较耗时的缺陷时测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等等问题。

那么，作为一个测试工程师如果在测试中使用敏捷的思想进行测试，那么他在敏捷测试中需要保证其工作符合相应的准则：

(1)‰获取和明确用户的质量期望；

(2)‰建立合适的系统测试、用户验收测试质量标准；

(3)‰推进单元测试、开发测试；

(4)‰建立持续构建框架；

(5)‰持续改进自动化测试；

(6)‰保持质量度量结果的可见性。

2.2敏捷测试任务列表

根据以上对采用敏捷思想进行测试的要求，敏捷测试中的测试任务可以进行概括下，敏捷测试需要执行以下活动：

(1)为系统建立不同层次的质量验收准则：

(2)让开发人员随时可以得到关于代码质量的反馈；

(3)通过测试驱动开发等方式不断提高代码质量；

(4)建立合适的自动化测试框架以减少测试的时间投入；

(5)建立可见的质量度量体系，让产品和代码质量反馈持续可见。

关于敏捷测试中是否需要使用测试用例，很多人觉得测试用例是在执行无用功。对于只是又书写了一遍需求的测试用例来讲，这样的用例当然没有用。对于敏捷测试，在写测试用例时我们必须要花很短的时间写出高质量的测试用例。在我认为敏捷的测试用例就是以简洁的语言写出所有测试点，甚至可以不要期望结果。因为对于一个有一年以上测试经验的测试人员来说，在项目开发前期已经通过参与需求分析和需求定义活动已经对测试用例的期望结果有非常的了解，亦或者期望结果在需求中找到。如果为了严谨，可简单写明结果。如果没时间可在后期敏捷测试过程中工作量不饱满时补上也未尝不可。同时敏捷测试用例必须在敏捷测试过程中不断得到更新，在我们测试过程中、思考过程中完成测试用例的更新，因为敏捷测试用例简洁的特点不会花太多时间。

2.3敏捷测试沟通

在测试过程中，测试发现的缺陷需要及时通知缺陷的相关人员，使其在尽可能短的时间内获知缺陷的存在。因此对于测试人员与开发人员的沟通问题也非常重要，如果测试人员觉得自己提出的缺陷别人可能会有疑义或者别人不仔细研读并不能直观地理解其意，那么最好在记录缺陷时详细记录发现缺陷时的测试环境、测试约束、测试步骤、测试数据信息等内容，这样在与开发人员进行沟通时能够更方便的还原缺陷。另外测试人员最好在缺陷后面写明自己的想法，同样开发人员在处理测试人员提交的缺陷时同样如此，对于有不同看法的缺陷一定要加上注释说明原委。在此基础上再进行沟通，我想剩下的问题不会太多，不会耽误双方太多时间，这样得沟通更易于让人接受、效率更高。测试人员之间的沟通与交流同样重要，每个测试人员对需求可能都有不同的理解，沟通可以使他们对需求的理解更趋于一直，更高效的发现问题。测试人员间相互查看对方提交的缺陷，同样是一种更有效的沟通和交流方式，可以发现别人看问题的不同角度，从而取长补短共同进步。总之在不影响别人工作的情况下尽可能与其他人做充分的沟通也是敏捷测试中的重要部分。

3敏捷测试管理

敏捷测试的管理同样是一个非常重要的部分，敏捷测试过程管理应该包括以下内容：

3.1测试计划

敏捷测试并不需要为每次迭代准备特别详细的测试计划文档，但最好能够在测试计划中描述(1)在本次迭代中哪些内容是需要被测试的；(2)本次迭代中会安排哪些类型的测试；(3)测试通过的质量标准是什么。同时测试计划应尽可能的简洁，以清晰、易懂为原则。

3.2测试设计

‰对于每个迭代中新增或是发生变化的功能，敏捷测试采用探索性测试的方法来设计测试。对于稳定的部分，敏捷测试采用自动化测试的方式建立可接受的质量度量框架。

3.3测试执行

测试过程中有不同的测试方式，不同的测试方式其侧重点有所不同。根据测试的自动化程度不同，测试方式主要包括以下几种：

3.4反馈与提高

在产品发布以后，可以说敏捷项目告一段落。但是为了不断提高测试能力、不断提高测试有效性，测试工程师还需要对在测试过程中收集的数据进行缺陷分析。将缺陷进行分类整理，采用合理的分析方法找出造成缺陷的真实原因，并对其原因进行分类整理。如果有可能建立缺陷资料库，对不同类别的缺陷建立缺陷资料库供敏捷团队进行学习，在整个团队中分享测试知识，包括敏捷开发人员对缺陷原因的认识。如果有可能的话，敏捷测试工程师应根据已有知识体系，建立更多纬度的自动化测试。在已定义的产品中，追溯缺陷对应的需求，建立需求-缺陷追踪矩阵。结合缺陷描述进行需求重定义，使得能需求清晰定义，不断提高产品的可测试性。

4总结

关于敏捷测试的一个不成熟的定义：一种面临迅速变化的需求和频繁迭代，迅速制定出与当前迭代高度适应的测试策略，快速做好测试准备并执行测试，尽早的发现优先级较高的缺陷、在有限的时间内完成覆盖率较高、测试较充分的测试。有效执行敏捷测试的关键因素包括以下信息：

(1)共享质量目标：开发和测试团队共享同样的质量目标，当然也共享同样的质量责任，每个工程师在测试方面都同样承担任务。

(2)以任务而非角色为重点来安排工作：敏捷测试需要一个紧密联系的开发和测试团队，因此不要将任务限定在具体的角色上。

(3)保证产品质量度量持续可见：“简单”意味着整个团队的目标是开发客户可用的软件，如果能让整个团队看到“我们的产品距离可用标准还有多少”，对敏捷过程来说是非常有利的。

(4)关注产品质量的提升，测试周期的缩短，而不是仅专注于发现缺陷。

(5)在产品中内建可测试性：为产品建立更好的自动化测试不仅仅依赖于测试工程师的工作，更重要的是，产品本身内建的可测试性。