软件测试极限测试.doc

软件测试：极限测试


20 世纪 90 年代出现了一种名为极限编程（XP，Extreme Programming）的新型 软件开发方法。一位名叫 Kent Beck 的项目经理设计了这种轻量、敏捷的开发过程， 并于 1996 年在戴姆勒· 克莱斯勒公司的项目中进行了首次测试。尽管此后还出现 了其他几种敏捷软件开发过程，但 XP 到目前为止最流行的敏捷软件开发过程。事 实上，现在已有众多的开源代码工具支持这种方法，这也证明了 XP 在开发人员和 项目经理中的流行程度。

开发 XP 是为了支持诸如 Java，Visual Basic 及 C#等编程语言的应用。这些面
向对象的语言使开发人员开发大型复杂应用的速度，比使用传统的 C，C++，
FORTRAN 或 COBOL 语言更快。使用后者开发程序常常需要构建通用的类库来支
持你的工作。诸如打印，排序，联网和统计分析等通用任务的实现方法并不是标准 的构件。而 C#和 Java 等编程语言都含有全功能的应用编程接口（API），消除或减 少了构建自定义类库的需要。

然而，伴随快速应用开发语言带来的好处，不利之处也随之而来。虽然开发人 员可以更快地开发应用程序，但其质量并未得到保证。程序运行时经常不能满足程 序规格说明的要求。XP 开发方法的目的是在短时间内开发高质量的程序。传统的 软件开发过程依然在发挥作用，但往往会花很多的时间，在竞争激烈的软件开发领 域里这就相当于损失了收入。

XP 模型高度依赖模块的单元和验收测试。总的来说，对每个无论多小的递增
的代码变更，都必须进行单元测试，以确保代码库满足其规格说明的要求。事实上， 测试在 XP 中的地位如此重要，以至于需要首先创建单元（模块）测试和验收测试， 然后才创建代码库。这种形式的测试被称为极限测试（XT，
Extreme Testing）。

极限编程基础


是一种相当新的软件开发过程，使开发人员可以快速地产生高XP 如前所述，



质量的代码。在这种情况下，我们可以将“质量”定义为代码库对其规格说明的满
足程度。XP 重视采取简单的设计、在开发人员和客户之间建立联系、不断地测试 代码库、重构以适应规格说明的变更，以及寻求用户的反馈。XP 更倾向于适合中 小规模的软件开发，这些软件的规格说明的变更非常频繁，接近实时的沟通也是可 能的。

XP 与传统的开发过程相比有几处不同。首先，它避免了大规模项目的综合症， 即在开始编码之前客户与编程小组碰头，设计软件的每一个细节，项目经理们都知 道这种做法的缺陷，因为为了反映新的业务谁则或市场情况，客户的规格说明和需 求必须不停地变更。举例来说，财务部门可能要求工资报表按处理时间，而不是按 支票号码进行排序，而营销部门可能会判断出，如果它没发电子邮件的话．用户将 不会购买某产品。XP 的策划阶段将重点放在收集应用程序需求，而不是设计程序 上。

XP 方法的另一个不同之处是避免了编写不需要的功能。如果客户认为某个功
能虽然需要，但并不是要求实现的，那么在软件发行时通常不包含此项功能。因此 我们可以将重点集中在正在进行的任务上，为软件产品增加价植。将精力集中在必 需的功能之上，有助于在短时间内开发出高质量的软件。

然而，XP 方法的主要不同之处是其将精力集中在测试上。在经历了一个非常
全面的设计阶段之后，传统的软件开发模型会建议首先编码，然后才生成测试接口， 但在 XP 方法中，我们必须首先生成单元测试用例，然后才编写代码通过测试。根 据本书第 5 章中讨论的概念，可以设计出 XP 环境中的单元测试。

XP 开发模型用 12 个核心实践来驱动该过程。表 8-l 总结了这些实践。简单来
说．这 12 个核心的 XP 实践可以归纳为 4 个概念：
1. 聆听客户和其他程序员的谈话。
2. 与客户合作，开发应用程序的规格说明和测试用例。
3. 结对编码。
4. 测试代码库。

表 8-l 中所列的由每个实践提供的注释都是可以自我解释的。然而，有两个更
XP
重要的原则，即计划和测试，有必要进一步讨论。一个成功的计划阶段为整个


的计划阶段与传统开发模型不同，通常将需求收集与应用设XP 过程奠定了基础，计结合起来。XP 中的计划重点是确定客户的应用需求，然后设计使用场景（或案 例需求）来满足客户的应用需求。通过生成使用场景，可以深入地洞悉应用程序的 目的和需求。此外，客户在一个开发周期的最后阶段执行验收测试时也可以用到这 些使用场景。最后，计划阶段带来的一个无