面向敏捷开发的软件测试技术

刘先博　沈小仑

摘要：近年来，随着信息技术的迅猛发展，快速变化的市场对软件产品的生命流程提出了更新更高的要求：一方面要求新的软件产品能尽快发布以抢占市场，另一方面要求软件产品能够快速变更来保持市场占有率，崇尚生产率的敏捷方法学应运而生，敏捷方法学强调以提高生产率为目标，推崇通过周期性的高度迭代来保证软件产品的能力和质量，得到越来越多的应用。

关键词：软件测试；敏捷开发；敏捷测试

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）18-0070-03

1.传统测试

典型的传统测试包括v模型，w模型，H模型等，以v模型为例，如图1所示，测试发生在开发之后的一个阶段，测试过程与开发过程相对应。

测试的过程即为计划测试-设计测试-实现测试-执行测试，通过迭代实现整个测试流程，在测试过程中，传统测试要求流程规范，文档齐全，根据软件需求总结、测试所有的功能点，直到软件没有大的bug。在传统v模型测试过程中，需求、功能、设计和编码的开发活动随时间而进行，而相应的测试活动即针对需求、功能、设计和编码的测试，开展的次序却正好相反，可以看到，底层代码设计最后被开发却最先被执行，反之，软件设计过程中的需求是最早开发，相应的验收测试到最后进行。如此，往往需求阶段隐藏的错误会一直到最后验收测试时才被发现，导致整个软件开发测试过程需要推倒重来，极大影响软件生产效率。相较而言，由Evolutff公司提出的w模型更科学，可以看作是v模型的改进版，在软件开发的每个阶段都进行测试，能更早的发现软件问题，软件测试w模型如图2所示，但是w模型软件测试仍然需要与软件开发保持顺序关系，只有在上一个阶段的开发任务完成之后才能进行下一个阶段的测试任务，无法支持敏捷开发这种需要高度迭代的软件开发模型。

2.敏捷测试

2.1敏捷测试的定义

敏捷测试没有明确定义，不能简单理解为更快的测试或者使用更少的资源（时间，物力）来实现相同的测试任务，一般而言，敏捷测试伴随于敏捷开发，2001年2月，17位当时被称之为轻量级方法学家编写和签署敏捷宣言（Agile Manifesto，Beck eta1.）正是标志着敏捷方法的开始，随后适应市场需求的敏捷开发越来越流行，随之而来，敏捷开发中的测试问题也被逐渐重视起来，如果只是将过去的传统测试方法生硬地应用于敏捷开发，由于敏捷开发的短周期，高迭代的特性，测试工作将几近无法正常进行，并且传统测试与开发保持的顺行关系将不能发挥测试应有的作用。敏捷测试就是改变传统测试方法，适应敏捷开发，对传统测试进行裁剪和增加而采用的新的测试流程，敏捷测试针对敏捷开发过程中迭代产生的新功能进行不断验证测试，同时对原有功能进行回归测试。如图3所示，在敏捷中，需要尽早测试，强调要能够及时、持续地对软件的质量问题进行回归反馈。

2.2敏捷测试的特点

1）支持变化，因为敏捷开发的特点就是高度迭代，根据客户提出的新的需求不断将产品开发推向更正确的发展方向，在这个过程中就要求测试也能够不断对软件新的变化做出验证。

2）拥抱客户参与，客户代表作为团队中最了解业务的人将帮助开发团队快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务方面他们需要客户代表的帮助，同时测试团队积极与客户沟通，了解客户需求，在测试过程中有更好的针对性。

3）“一张纸测试”，敏捷测试以提高生产率为目标，强调快速迭代，高质量产出，因此传统测试过程中的严格文档要求在敏捷测试中不作要求，测试人员与开发人员、客户密切沟通，崇尚“一张纸”测试计划，对传统的测试流程进行裁剪，减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、测试人员、客户的交流。

4）提倡自动化测试，敏捷测试中每次迭代后都需要对原有功能进行回归测试，对新增加的功能进行验证测试，鉴于敏捷开发的高迭代性特点，敏捷测试的工作量很大，这就要求敏捷测试积极拥抱自动化测试，尽量减少开发过程中高迭代部分回归测试部分的测试时间，重复部分测试应尽量用自动化测试实现。

在敏捷测试流程中，测试人员需要参与单元测试，关注持续迭代的新功能，针对这些功能进行足够的验收测试，原有功能的回归测试则更多地用自动化测试来实现。以后与敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的品神，更重要的是能够及时、持续的对软件品质进行反馈，简单地说，敏捷测试就是持续地对软件质量问题进行及时的反馈。从确认客户需求开始，测试就开始进行，测试用例的设计、测试计划、测试执行，测试贯穿软件开发的整个流程。

2.3测试自动化

在敏捷测试中，使用自动化测试是必不可少的内容，在敏捷开发中，会有新的功能在每次迭代中不断被开发出来，这些新的功能属于必须充分测试的部分，同时，为了保证迭代软件产品本身的质量，确保在增加软件新功能的时候没有对原有软件产品造成破坏，还需要对软件产品进行综合测试，迭代频率越高，所需消耗的测试资源越多，而测试资源中的测试时间、测试人力和物力都是有限的，不可能一直全面地测试到软件的所有方面，自动化测试是保证不断迭代后继续保持软件质量不可缺少的途径。在敏捷项目的早期阶段因为进度和方案的变更开展自动化测试通常是很困难的，但是到后期迭代时，前期的用户故事已经稳定下来，测试人员就可以在前期手动的基础实现自动化测试。

自动化测试为迭代的回归测试提供服务，提高了回归测试的效率和质量，节约了大量的时间，在敏捷测试模型中，它归于系统综合测试阶段，能有有效保证迭代版本的质量和稳定性。

2.4典型敏捷测试的流程

敏捷测试主要包括两个部分：确认测试和综合测试，典型敏捷测试的流程可以用图4来表示。

确认测试是对迭代出软件新的功能的有效性进行确认验证，测试人员根据迭代之前制定的需求和计划对新发布的软件增加的功能开发出充分的测试用例，对其高优先级输出的部分进行充分测试，及时纠正新发布软件的错误，保证迭代版本软件质量。确认测试要做到持续测试，一旦某块新代码完成就可以对该块新代码进行测试，以使测试效率最大化。

综合测试是对确认测试的补充，包含完整的功能测试，测试人员完成对软件的确认测试后对软件进行补充测试，完成迭代软件的综合测试，证明迭代软件的稳定性和正确性以使软件产品完善的进入下一迭代流程。

典型敏捷测试存在的不足在于，本次迭代周期包含前一次迭代测试的综合测试部分，第N次迭代的综合测试发生在第N+1个周期，主观性地认为前一次迭代测试的综合测试不会出现较大的软件问题，而敏捷开发的高迭代性要求不允许出现等待，因此敏捷开发团队不会等待第N次迭代软件综合测试完全结束后才进行下一周期（N+1）的开发，这就增加了开发风险，同时本周期迭代的软件产品在下一周期才得到测试，影响测试效果。

2.5敏捷增量测试模型

为了改进典型敏捷测试模型的缺点，使敏捷团队能够及时解决当前迭代周期的问题，可以将典型敏捷测试的测试过程扩充为三个部分：确认测试，验证测试以及集成测试。

在改进型敏捷测试过程中，确认测试和综合测试都放在当前的迭代周期内完成，减少软件开发风险，增加集成测试则可以使测试人员对之前迭代周期的软件产品进行小范围内的集成测试，替代原敏捷测试模型中的对前一迭代周期进行综合测试的部分，不同的是，这里的集成测试只需及时记录下测试接口错误以及其他的集成环境错误，并不被定义为当前迭代周期内的测试任务，只是适应敏捷开发的“等待性任务”，所以测试人员以当前迭代周期内的测试计划为主，当能开始本次迭代周期内的工作时，可以随时停止集成测试工作，并且对迭代周期内的集成测试不要求测试人员对发现的错误立刻响应，但是要求测试人员对错误信息作详细记录，便于提高集成测试环节的效率。

3.总结

本文就时下流行的敏捷开发模式探讨了传统测试在敏捷应用中的不足，系统介绍了敏捷测试的特点及流程，并提出增量敏捷测试模型和具体测试方法，经实践证明，与传统的测试模型相比，能更早的发现并清除软件bug，在保证了软件产品质量的同时很大程度提高了软件产品的生产效率。