1.负面测试的目的

负面测试在BS7925-1中的英国标准定义是采用Beizer的定义，其定义负面测试为“旨在说明软件不能工作的测试”（原文：Testingaimed at showing software does not work）。它可以带出一系列补充性的和竞争性的目的。

发现导致重大失效、崩溃、破坏和安全漏洞的故障

观察和度量系统对外界问题的响应

揭露软件的弱点和开发的潜力

虽然有个一个公正的定义，但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语，有时甚至是各小组的。一个常见的方法，其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。

输入验证，拒绝和重新请求的功能（人工输入和外界系统）

内部数据验证和拒绝

应付缺乏的，缓慢的或坏掉的外界资源

错误处理功能，例如消息，日志，监视功能

恢复功能，例如故障恢复，回滚和恢复

2.获取测试用例的技术

负面测试不是一种测试设计技术，说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。

边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning

状态转换测试State Transitiontesting

逆着已知的约束测试Testagainst known constraints

故障模式和结果分析Failure Mode and Effects analysis

并发Concurrency

用例和误用的用例Use cases and mis-usecases

2.1.边界值分析和等价类划分

有两种基于输入和输出数据和系统行为期望的技术。

边界值分析（BVA：Boundary Value Analysis）利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。

这个方法用于产生三个数值－一个是边界本身，另外两个在前者的两边（尽可能的和数字相接近）。如果边界在有效和无效范围之间，使用无效数值的测试用例将成为一个负面测试用例。例如，使用66在只接受从18～65数值的年龄字段。

等价类划分（ECP：Equivalence Class Partitioning）着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里，使系统做同样的事情－这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试－例如，一个年龄字段可能被期望用相同的方法拒绝所有的负数。

ECP一般被延伸到包括非连续数值的集合，胜于连续的数值范围。要注意一些输入可能看上去等价，但是实际上出现很多不同的行为。例如，一个简单web的表单的输入是为空或者太长时可能会被拒绝，但是控制字符的正确组合可能危害潜在web服务器的安全。

2.2.状态转换测试

假设有一个状态转换图或者一个与其等价的理解，那么很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch测试，在一套已知的转换之后，那些不可到达的状态仍然是不可到达吗？图形工具，例如Compendium-TA[4]能够帮助你获得这样的测试。

2.3.逆着已知的约束测试

大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束（参加Robinson+Robinson，[5])）可以得到各种负面测试。例如：

“The site is designed to be viewed with Internet Explorer4.5 or later”?负面测试可以使用IE3.0或Netscape.

“No more than five users will use the system at the same time”?负面测试可以尝试6个，然后8。

概括来说，测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用，并且这种观察可能导致对系统的进一步了解。

2.4.故障模式和结果分析

从对潜在的技术，实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的－特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时（例如银行，电话公司）可以采取行动的技术专家的组织而言，这些文档通常是测试的必要输出。另一方面，对于更广泛的分布式软件包来说，这些信息也可以成为FAQ或故障诊断指南的一部分。

这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的，并且可能需要在代码的已提交版本里运行。

然而，象CannedHEAT和Holodeck(都出自the Florida Institute of Technology，[6])这样的工具允许将普通性故障引入到运行在Windows的软件中。

6.4.1.故障家族

有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析，系统设计文档，基础设施特有问题的知识能够帮助识别故障模式，并且因此为获取测试提供来源。

以下列表虽不详尽，但或许可以帮助引发更多的关于可能的故障想法。

外部资源：反应迟钝或缓慢的，莫明其妙或不恰当的反应。

协处理器故障：独特的间断处理器，多任务和递归

并发使用：资源锁定，请求已拒绝的锁定，死锁，锁定响应延迟

牺牲处理器Sacrificialprocesses：允许失败的处理器并且用可控方式恢复

文件系统：文件不能被找到，打开，读，写，权限变更，文件系统识别介质错误，介质移除，介质装满

网络：网络中断，网络忙碌/缓慢，传输段丢失、损坏、无序，处理器之间的对话被中断

内存：不足以给请求的分配，碎片

已达到的限制：排队，licences，线程，连接，数组大小，资源分配

2.5.并发

测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据，数据库条目，文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源，简单，定制的工具可能有些帮助，并且在他们选择的时候发布它。测试也应该检查第二个请求者终得到了资源。更加复杂的测试将着眼于二个以上的请求，排队，超时和死锁。

2.6.用例和误用的用例

用例，在实践中趋向于处理系统的‘happypath’。各种错误输入的覆盖，拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语，虽然不是偏僻的标准，但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计，并且允许一个正式的方法来测试选择和覆盖．