敏捷开发与敏捷测试

敏捷开发与敏捷测试

摘要：敏捷开发是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。本文主要阐述了敏捷开发和敏捷测试的概念，敏捷开发测试的原则和敏捷开发的理念，着重介绍了敏捷测试用例设计，敏捷开发以及敏捷自动化测试。

关键字: 敏捷开发、敏捷测试、敏捷原则、敏捷理念、敏捷测试用例设计

Agility tests and Agile development

Guolei Liu

(China University of Petroleum (East China) College of Computer

and Communication Engineering, Qingdao 266555)

Abstract：Agile development is a process, not an event. It is a continuous application principle, mode and practice to improve structure of software and the readability of the process. It is committed to maintaining system design in any time as far as possible simple, clean and expressive.

Key words：Agility tests 、Agile development 、Agile principle 、Agile concept、Agile test case design

引言：敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑模型与快速原型法的影子，也许还有多改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。在敏捷开发的过程汇总，通常都会用到一些可以交流工作的软件，它主要是利用非常短的循环，使终端客户可以及时、快速地看到软件的的构建成果。

1.敏捷开发与敏捷测试的相关概念

敏捷开发：敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。迭代包括需求的开发和测试。目标随着从上一次的迭代中学到的东西、反馈以及商业机会而调整。在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受测试通过才算完成。敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。

在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。故敏捷开发有一下特点：

1.敏捷型开发方法是“适配性”而非“预设性”。传统型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法不具有普适性。而敏

捷型方法能在软件开发的过程中实时性的进行调整。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

2.敏捷型开发方法是“面向人”的(people-oriented) 而非“面向过程”的

(process-oriented)。它们试图使软件开发工作顺应人的天性、以人为中心。它强调软件开发应当是一项愉快的活动。

敏捷测试：敏捷测试的原则与上下文驱动测试（Context-Driven Testing）的原则有交集，两者都强调人的作用。敏捷测试是遵循敏捷宣言的一种测试实践：

1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。

2、重点关注持续迭代的测试新开发的功能，不再强调传统测试过程中严格的测试阶段。

3、建议尽早开始测试，持续进行回归测试保证之前测试过内容的正确性。

2.敏捷开发和敏捷测试的理念和遵循的原则

敏捷理念：

个体和交互比过程和工具更有价值；

能工作的软件比全面的文档更有价值；

顾客的协作比合同谈判更有价值；

及时响应变更比遵循计划更有价值

敏捷原则：

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，而XP中的一些原则又是源于众所周知的软件工程学。

核心原则：

◆主张简单当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。

图一敏捷开发

◆拥抱变化需求时刻在变，人们对于需求的理解也时刻在变。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

◆你的第二个目标是可持续性可持续性可能指的是系统的下一个主要发布版，或是你正

在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。

◆递增的变化没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。

◆令Stakeholder投资最大化你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

◆有目的的建模对于自己的artifact，首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。

◆多种模型开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，

图二敏捷开发

考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术。

◆高质量的工作没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

◆快速反馈从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

◆软件是你的主要目标软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

◆轻装前进你建立一个artifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。

补充原则：