敏捷开发中的软件测试.doc

重庆大学软件学院软件测试课程（论文）

敏捷开发中的软件测试

指导老师：张毅
学生：刘中保
学号：20102413020
1
目录
TOC\o"1-3"\h\z\uHYPERLINK\l"_Toc297411904"目录 PAGEREF_Toc297411904\h1
HYPERLINK\l"_Toc297411905"摘要 PAGEREF_Toc297411905\h2
HYPERLINK\l"_Toc297411905"正文 2
HYPERLINK\l"_Toc297411906"参考文献 4


摘要

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
对于传统的开发方法，开发团队会编写大量的详细的测试相关文档来指导以后的系统测试，这种方法的好处在于可以记录大部分的需求，如果项目人员变更也可以让新进成员很快地进入项目进程。但是测试文档最大的缺点就是不能很好地适应需求的变更。
而敏捷开发提倡的是代码即文档，它用大量的代码注释取代了文档，以达到高效快速的软件开发的目的。同样的，对于软件的测试也是直接体现在代码上。这样可以及时得应对无时不在的需求变更。但从另外一个方面来说，这种方法要求团队成员都必须对项目十分了解。这样应对团队变更就会稍逊一筹。

关键字：敏捷开发，软件测试，测试驱动1敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发最终的目标就是拥抱变化，以最快的速度对适应无所不在的变化。众所周知的是，软件开发过程中，需求永远是无法在需求分析阶段就得到完整的确认。因此传统的瀑布模型的开发方式已不可能适应快速变化的需求。但是敏捷开发却可以一些有异于传统软件开发方法的特性，做到对需求变化的快速适应。
Test-DrivenDevelopment，测试驱动开发。它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在StoryCard上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。
ContinuousIntegration，持续集成。在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。
Refactoring，重构。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者checkin代码之前，都要对所写代码进行重构，让代码达到cleancodethatworks。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。
Pair-Programm