南京理工大学-软件敏捷开发作业

基于敏捷开发的软件测试技术研究与应用

摘要：传统软件开发方法越来越不能够满足口益复杂和多变的软件需求。敏捷软件开发方法由于具有支持变化、高度迭代、重视沟通和客户反馈的特性，有效地解决了传统软件方法的不足，因此越来越多的软件开发团队将敏捷开发方法应用到软件开发的实践中来。敏捷软件开发方法得到了迅速的发展。软件测试作为软件质量保证的基础，敏捷测试也相应成为软件开发团队关注的焦点。

本文分析了敏捷软件开发的主要特点和传统软件测试模型在应用上的不足，讨论了软件测试技术在新的敏捷开发环境中的应用，探讨了敏捷测试面临的主要问题。以提高敏捷开发方法的软件测试效率为目的，提出了一种适合敏捷开发方法的软件测试模型:改进的敏捷增量测试模型。改进的敏捷增量测试模型和传统的敏捷增量测试模型的区别是将验证测试和拓展测试都放在当前迭代的计划内完成，从而使开发和测试保持了同步，便于软件项目的管理;同时在每一迭代周期增加了集成测试，便于及早地发现软件模块的问题，降低了软件在交付给用户后发现BUG的几率。

关键词：敏捷开发方法；软件测试模型；敏捷测试

A Research and Application on Software Testing

Technology for Agile Development

Abstact: Traditional software development methods become much zarder to meet the increasingly complex and changing software requirements. While agile software development methods can solve this problem well because they adapt to the change,they are highly iterative, and they think highly of communication and customer feedback. Therefore, more and more software development teams apply agile development methods to the practice of software development. Thus, agile software development methodology has been continuously developing. Agile testing has been put focus by software development team because of software testing as a cornerstone of software quality.

This paper analyzes the disadvantages of the main characteristics of agile software development and the insufficient of traditional software testing model's deficiencies in the application. It discusses software testing technology in the new application of agile development environment and has a quick test of the main problems which the agile tests are facing. The paper aims to improve the efficiency of software testing. It proposes an agile software testing model which is suitable for agile development methods:improved agility incremental test model. The improved agility incremental test model is to put both the verification test and the expanding test in current iteration planning, which is different from the traditional incremental test model. In this way, the development can keep pace with the testing. And it is easy for the management of software projects. At the same time,integration testing is

increased in each iteration cycle. It is easy for us to discover the problem of software modules earlier. The chance that the user will find the bug can be reduced after the software was delivered to the user. Key Words:agile development methods;software testing model;agile testing

1 概述

在敏捷开发过程中，软件测试是至关重要的。随着近年来敏捷开发方法的迅速发展，敏捷测试技术也得到了广泛的关注。传统的软件测试技术己不能适应当前的开发方式，急需新的理论和方法来寻求改变，并以此来推进软件工程的发展。本文选择关注与敏捷测试相关的理论和技术，着重研究在敏捷开发过程中所应用的测试技术，同时分析了敏捷软件开发的主要特点和传统软件测试模型在新的敏捷开发环境下的不足，讨论了软件测试技术在新的敏捷开发环境中的应用，探讨了敏捷测试面临的主要问题。

本文的主要内容如下:1.分析敏捷方法的核心理念以及其与传统开发方法的区别，着重分析敏捷方法的几个代表，并针对研究与其相关的软件测试技术。

2.简要分析几种常见的软件测试技术和测试模型，提出了传统测试模型的不足之处。

3.分析敏捷开发方法的特点，研究敏捷测试的过程，提出了一种改进的敏捷增量测试模型。

2 典型的敏捷增量模型

2.1 典型的敏捷增量测试模式基本原理

敏捷增量测试模型由Scott W. Ambler提出，Scott W. Ambler认为在敏捷开发方法中，软件测试是随着软件开发一起进入迭代周期的。整个软件产品的敏捷开发生命周期可以分为4个阶段，即初始阶段、项目的建设阶段、产品发布阶段和产品的维护阶段，其中软件测试的主要工作集中在软件项目建设阶段。这个过程可以用敏捷增量测试模型进行描述(如图1所示，N表示第N个迭代周期)。在敏捷增量测试模型中，软件测试被分成两个部分:验证测试和拓展测试。

图1 敏捷增量测试模型

验证测试就是对软件产品的有效性和关键的功能是否正确进行验证，测试人员通过开发完整的测试用例和测试脚本，确保软件产品的质量，并及时纠正软件产品的错误。验证测试除了包括测试人员的测试外，还包含了开发人员的单元测试，验证测试的测试任务用来保障本次迭代周期的软件产品的质量、基本的功能、非功能的任务，以及在迭代开始时制定的计划中承诺的各种需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。

拓展测试是对验证测试的补充，是为了使产品更完善的进入下一个迭代周期而进行的更广泛的测试活动。测试团队在完成软件产品主体的验证测试后进行拓展测试。拓展测试包含功能测试、文档测试和系统测试等。在迭代周期允许的情

况下，有些开发团队还会采用一些极端的测试活动，如探索测试。这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品，就好比“猴子敲键盘”一样，测试员使用各种手段来考验产品的稳定和正确性等。

2.2 典型敏捷增量侧试模型的不足

在经典的敏捷增量测试模型中，前一迭代周期的拓展测试被放在了本次迭代周期内。这是因为我们通常把拓展测试作为当前迭代的收尾工作，只是对当前迭代周期内软件测试的一种简化的回归测试，通常认为不会出现较大的软件错误，而在敏捷开发的高度迭代环境中不允许出现等待，所以开发团队往往会选择进入下一迭代周期，而不会等待这种补充性质的测试工作。因此典型的敏捷增量测试模型主要存在的不足是:

1.增加了开发风险。一旦出现验证测试不充分的现象，将增加开发成本。

2.不利于保持测试工作和开发工作的同步。

3.影响测试效果。迭代周期内做的测试计划，应该服务于本次迭代。

3 改进的敏捷增量测试模型

为了便于敏捷团队能够更及时解决当前问题，测试人员对上一迭代周期内软件产品的所有测试都应该计入上一迭代周期的测试计划，而不是当前迭代周期的测试计划。所以我们对经典的敏捷增量测试模型做出改进:在改进的敏捷增量测试模型中，我们将测试过程分为三部分，除了验证测试和拓展测试外，新增加了对前一迭代周期的集成测试。

在改进的测试模型中，验证测试和拓展测试都放在当前迭代的计划内完成(图2所示)。这样同一迭代周期内的开发任务和测试任务都被要求同步进行，有利于开发团队的沟通，共同制定下一迭代周期的开发计划和测试计划，平衡整个开发团队的任务进度，避免了开发风险。改进后的模型更能体现敏捷开发的特点。

图2 改进的敏捷增量测试模型

在改进的测试模型中新增了集成测试。因为在进入新的迭代周期时，开发人员先要进行测试驱动开发。经典的测试模型中测试人员当前做的拓展测试在新的模型内被要求在前一迭代周期内完成，所以新的模型中要求测试人员对之前迭代周期的软件产品进行小范围内的集成测试，并及时的记录下测试接口错误及其他的集成环境错误。这样调整后，由于集成测试并不被定义为当前迭代周期内的测试任务，只是适应敏捷开发的“等待性任务”，所以测试人员要以当前迭代周期内的测试计划为主，当能开始本次迭代周期内的工作时，可以随时停止集成测试

工作，并且对迭代周期内的集成测试不要求测试人员对于发现的错误立刻响应，但是要求测试人员对错误信息做详细记录，便于提高集成测试环节的效率。

在我们新的增量测试模型中验证测试包含对需求的静态测试，开发人员做的单元测试，以及对迭代周期的验证测试，功能测试(仅限于对当前迭代功能)和重要的其他类型测试。通过了验证测试的产品就可以作为在迭代结束时发布了。而为了产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，我们需要针对性的做系统测试、压力、并发、安全甚至全球化的测试，这部分我们把它叫做拓展测试。还需要强调的是，为了保障产品的最终稳定，为了产品不会出现在代码重构后的质量回归现象，我们将回归测试放在这个阶段，用以涵盖对以往关键功能的再度验证。

在新的测试模型里，验证测试增加了“静态测试”，这部分测试是对测试人员最具挑战的部分。一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力，也得以发挥了团队的最大优势。根据项目实践经验，往往这个阶段会需要一个迭代周期1/4左右的时间。这同时也说明了静态测试在敏捷测试类型中的重要性。在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现。

对于静态测试的方法，我们通常使用RUP的Use Case，这是个很好的分析需求的方法，也是测试人员作为静态测试的使用的方法之一。对产品长期战略和业务的熟悉可以帮助测试人员更好的理解团队的用例设计，视图、模块等，也能够通过对比分析，直接找出某些设计中的缺陷，以提高设计的质量。项目的开发前期阶段，设计是占有非常重要的比例，而设计是直接影响产品质量的环节，因而确保这一阶段的质量对产品的品质提高起到决定性作用。针对开发出来的用例，设计者对用例的描述通常故事情节比较简单，缺乏完备和逻辑的缤密。而开发和测试需要的是详细的设计，这个用例设计和各种辅助的逻辑应该将用例定义的清晰和明确，例如边界条件，例外条件，数据的格式和其他性能指标的界定等等都需要涵盖。因此，测试人员应该领导团队帮助明确出测试用例的更多细节。

4 改进的敏捷增量测试模型的优势

本文主要通过改进软件测试模型和利用适合敏捷开发的测试框架实现测试的自动化来提高敏捷测试的效率。通过本方法实现了对软件开发过程的高效管理，实现了整个软件开发团队高效一致的协同工作。而对自动化测试的算法研究，以及如何有效的提高测试用例的完备性和可靠性的研究尚存不足。随着软件测试技术的不断发展，测试用例的自动化生成技术也成为测试团队的研究重点，一种高效的测试用例自动化生成策略，可以有效地降低测试成员的工作量，将测试人员从重复性的工作中解脱出来。所以在以后的研究工作中，将对自动化测试的算法和测试用例的自动生成技术以及测试用例的完备性及可靠性等问题作进一步的研究。

5 结束语

由于近看来，敏捷开发过程在软件开发界处理一个研究的热潮，其中自成体

系的方法论就多达十几种，具体的操作方法就更多了。作者受时间的限制很难将这些方法论逐个解析，本文只是从这么多敏捷的开发方法中选出了一些最能够让人接受的、最容易操作的方法投入到一个实际的企业应用系统的开发中使用，收到了很好的效果。这样的做法包括轻型计划、抚今迭代开发、简化设计、测试驱动、代码重构、持续性整合和及时的文档编写等。

在本文的参考文献中，不仅使用了国内外的学术专著，也使用了大量网络文档和网站内容，使得本文的时效性大大提高。其中杰出者，如:微软的MSDN和国内的UML China网站都提供了很大的帮助。

在敏捷开发过程方面有大量的英文专著，其中只有很少一部分被译成了中文。没有足够的时间能够详细地研究那些专著，不能不说是一个很大的遗憾。可以说作者对于敏捷开发过程的理解只是管中窥豹，只见一斑。

本课题在研究方法上是有一定不足的，由于本文所写的是一个实际的开发项目，因此对于时间上的要求非常高，并没有充分的时间比效各种不同场景下的效果，而是拿实际的情况和脑海中原来的情况作比较，因此得出的结论往往容易受到主观因素的影响。

由于作者水平有限，文章在论述和分析上难免存在疏漏和不完善的地方，欢迎各位读者批评指正。