基于敏捷测试的技术研究

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

　　1 研究背景

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

　　1.1 敏捷技术方法与分析

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

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

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

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

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

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

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

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

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

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

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

　

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