获取负面测试用例的技术(2)

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

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

　　2.4.1. 故障家族

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

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

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

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

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

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

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

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

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

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

　　2.5. 并发

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

　　2.6. 用例和误用的用例

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

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