基于敏捷测试的技术研究[1]

　　基于敏捷测试的技术研究[1]   软件测试

　　随着敏捷开发过程流行，敏捷测试方法也开始受到更多的关注。同时，软件测试用例的选择和生成也是软件测试中的一个重要研究领域，测试用例的质量将直接决定软件测试的科学性和有效性。本文基于集成测试框架FIT(Framework for Integrated Test)，并结合两两组合覆盖的测试用例自动生成技术，实现从接口参数边界值的确定，到以HMTL形式显示集成测试结果过程的半自动化过程。

　　1 研究背景

　　随着敏捷开发的流行，传统的软件测试也在发生着翻天覆地的变化。传统的软件测试已不能适应当前的开发方式，急需新的理论和方法论来寻求改变，并以此来推进软件工程的进步。本文将关注与敏捷测试相关理论与技术。

　　1.1 敏捷技术方法与分析

　　我们现在面对着飞速变化的业务和技术环境。在这样一个环境中，传统的软件开发方法所认为需求需要在项目初期分析清楚并且保持稳定的想法是行不通的。不能快速持续的将需求变化融合到软件中就意味着对业务环境反映迟钝，最终导致业务上的失败。同样，新技术不断地涌现，也要求软件产品的代码时刻处于一种良好的状态，能够适应各种调整。于是，敏捷开发过程应运而生。

　　2001年以Kent Beck，Martin Fowler，Robert C.Martin及Ward Cunningham等为首的一些软件工程的专家成立了“敏捷联盟”(Agile Alliance)，并提出了著名的敏捷宣言，即敏捷过程的价值观：

　　 人和交互重于过程和工具。

　　 可以工作的软件重于求全责备的文档。

　　 客户合作重于合同谈判。

　　 随时应对变化重于循规蹈矩。

　　这些价值观是专家们在求同存异的基础上对敏捷技术的最基本的总结，也是他们在敏捷技术方面达成的最大共识，其反映的是两个更深层的特点：

　　1) 敏捷型方法是“适应性”而非“预见性”

　　工程方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划， 然后依计划进行开发。这类方法在一般情况下工作良好，但(需求、环境等) 有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

　　2) 敏捷型方法是“面向人”的，而非“面向过程”的

　　工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法 则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的 工作提供支持。

　　敏捷联盟还以这4个价值观为原则，提出了敏捷过程的12条指导原则，以期能更好的指导人们了解敏捷过程。

　　敏捷开发过程，指的就是一种与传统的瀑布模型开发和CMM(Capability Maturity Model，软件开发的能力成熟度模型)所追求的严谨的文档制度截然相反的开发过程。这一开发过程注重开发团队和成员之间的关系而不是以开发的进程和使用的工具为重点，注重所开发的软件产品而不是追求广泛的文档编制，注重开发过程中与客户的协同工作而不是以签订合同的谈判为工作的核心，注重在开发过程中随时调整计划而不是同意完全遵循某一开发计划，以实现所谓开发过程的“敏捷”。

　　1.2 敏捷测试及其研究现状

　　敏捷方法的发展，打破了传统的瀑布开发模型，改变了整个软件开发过程中的角色和定位。由于在敏捷开发运动的初期，主要依靠开发人员来进行推动。很多测试人员不了解敏捷方法，仍然习惯了按照传统的瀑布模式进行软件测试，即按照V模型所指导的步骤进行测试，保证软件与需求、设计的相符合，但这样很容易形成了一种测试思维的定势。当“用户需求不明确”、“需求变化较快”时，沿用传统测试方法的测试人员将变的无所适从。

　　目前比较流行的敏捷测试方法有测试驱动开发和相关环境驱动测试等。还有很多国外知名专家按照“敏捷”的原理为软件测试开发了相应的测试框架，其中最著名的就是Kent Beck等提出的xUnit系列单元测试框架和Ward Cunningham等提出的Framework for Integrated Test(FIT)集成测试框架。xUnit系列提出的比较早，目前已有一套完善的测试工具和方法论来支持了，适用于各种语言的单元测试。FIT框架是当前国内外的研究重点，很多知名的测试专家如Lisa Crispin等都在如何使用FIT进行有效的软件测试方面得出了很多的研究成果。

原文转自：http://www.ltesting.net