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进行有效的软件测试方面得出了很多的研究成果。
1.3 基于接口参数的测试用例自动生成算法
在软件测试工作中，由于输入、输出空间，特别是输入空间的无限性，使得无法对软件进行全面的测试。因此，如何从大量的输入数据中挑选适量的具有代表性、典型性的数据，特别是怎样用较少的测试用例对软件进行较全面的测试是测试人员面临的一大难题。
测试用例的选择无论是对黑箱测试还是对白箱测试都起着关键的作用，决定着软件测试的质量和效果。所谓测试用例选择就是指从所有的可用测试用例中选出少量典型的测试用例，以达到对测试域的最大限度覆盖。多年来，许多研究者对之进行了广泛而深入的研究，并取得了许多研究成果。常用的基于接接口参数的黑箱测试用例选择方法是对系统每个接口参数采用边际值分析法和等价类划分法等选取一组典型的值，然后在这些取值组合中随机选取一组测试用例，或者使用一些启发式方法从中进行筛选。但这些方法的缺点是带有主观倾向性，不具有普遍性。
2 基于敏捷测试的相关技术讨论
2.1 FIT框架及应用
在敏捷开发过程中，软件测试是至关重要的，尤其是在最为流行的敏捷开发过程：极限编程（XP）中显的更为突出。诚然，所有的过程都提到测试，但一般都不怎么强调。可是XP将测试作为开发的基础，要求每个程序员写一段源码时都得写相应的测试码。这些测试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的建造平台，为进一步开发提供了良好的基础。
但是，即使是单元测试工具JUnit也存在一些缺点：比如JUnit里要进行数据填充，但是数据经常改变，使维护工作变成了可怕的噩梦，测试不同的组合，需要不同的数据，这也许会使测试工作变得日益复杂。而目前的集成测试又缺乏有效的方法论，不能自动化，测试的质量比较依赖测试人员的水平。 Framework for Integrated Test（简称FIT）就是一个用于增强交流和协作的工具。FIT创建了一个在客户和程序员之间的反馈循环。FIT让客户和测试人员可以使用诸如Microsoft Office之类的工具来给出程序应当如何表现的例子——而无需成为直接编码的程序员。FIT自动针对实际的程序检测那些例子，这样就在业务世界和软件工程世界之间建立了一个简单而且有效的桥梁。
FIT给予了客户和程序员一个关于软件的精确交流的方法。客户所给的具体的例子让程序员能深刻理解将要构建的产品。程序员的对于装置的工作和软件可以让客户给出不同的例子进行试验来获取对于软件如何真正工作更深入的了解。这样通过一起工作，整个团队可以学会更多关于产品的内容并产生更好的结果。
2.2 测试用例自动生成技术
正交试验设计起源于科学试验，它由田口玄一博士在1949年创立，并于60年代初从日本传人中国。它应用依据Galois理论导出的正交表，从大量试验条件中挑选出适量的、有代表性的条件来合理地安排试验。运用这种方法安排的试验具有“均匀分散、整齐可比”的特点。“均匀分散”性使试验点均衡地分布在试验范围内，让每个试验点有充分的代表性；“整齐可比”性使试验结果的分析十分方便，可以估计各因素对指标的影响，找出影响事物变化的主要因素。
但正交试验设计仍然存在着一些有待解决的弊端：比如正交表难以构造，因素、水平过多时测试用例数目还是过多等。所以一些专家又提出一种基于对接口参数进行组合覆盖的黑箱测试用例自动生成算法模型，据此来得到一个对所有接口参数进行两两组合覆盖的测试用例表。这种方法有着类似正交试验设计的特点，实际上，在特定情况下，这种算法模型得出的测试用例表就是正交表。
3 技术实现的考虑
3.1 基于FIT框架对软件进行集成测试
使用基于FIT框架的开源FIT工具来实现真正的测试先行开发过程，并让客户、需求提报工程师、开发人员、以及测试人员进行协同工作，达到需求更精准、减少需求更改、测试数据与JUnit单元测试代码分离的目的，让这一切更简洁、更易于维护。
将根据以下步骤进行研究：
1) 使用FIT框架进行实际项目测试的实践，从中提炼出一套使用FIT框架进行集成测试的通用方法。
2) 通过实践，对FIT框架进行合理的改进和拓展，结合JUnit单元测试，现实单元测试和集成测试的无缝连接，达到提高软件质量的效果。
3) 在理论研究和实践的基础上，规约出适用于单元测试和集成测试的通用方法。
3.2 整合测试用例的自动生成技术至FIT
按照敏捷过程中“简单”原则，本课题将编写一个辅助接口测试的工具，用来自动产生少而有效的测试用例，以达到对测试域的最大限度覆盖。通过该工具产生的测试用例表，能符合FIT框架的要求，并可被FIT所执行而得到HTML形式的可视化的测试结果。通过这种方式，大大增加了测试的自动化。
为了实现该目标，将按照以下步骤进行研究：
1) 查看“正交试验设计方法”的原理及其资料，了解测试用例生成的规则。
2) 查阅两两覆盖测试用例生成的相关算法，并根据算法用程序实现，进行实践研究。
3) 根据实践研究，对两两覆盖测试用例进行改进，以期能更高效的实现测试用例的生成。
4) 修改依据改进后的算法实现的测试工具，使其输入输出符合FIT框架的要求。在此基础上，把此工具集成到FIT框架中。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/