2.3. 逆着已知的约束测试
大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束(参加Robinson+Robinson, [5]))就可以得到各种负面测试。例如：
• “The site is designed to be viewed with Internet Explorer 4.5 or later” – 负面测试可以使用IE3.0或Netscape.
• “No more than five users will use the system at the same time” –负面测试可以尝试6个，然后8。
概括来说，测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用，并且这种观察可能导致对系统的进一步了解。
2.4. 故障模式和结果分析
从对潜在的技术，实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的-特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时(例如银行，电话公司)可以采取行动的技术专家的组织而言，这些文档通常是测试的必要输出。 另一方面，对于更广泛的分布式软件包来说，这些信息也可以成为FAQ或故障诊断指南的一部分。
这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的，并且可能需要在代码的已提交版本里运行。
然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])这样的工具允许将普通性故障引入到运行在Windows的软件中。
2.4.1. 故障家族
有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析，系统设计文档，基础设施特有问题的知识能够帮助识别故障模式，并且因此为获取测试提供来源。
以下列表虽不详尽，但或许可以帮助引发更多的关于可能的故障想法。
• 外部资源：反应迟钝或缓慢的，莫明其妙或不恰当的反应。
• 协处理器故障：独特的间断处理器，多任务和递归
• 并发使用：资源锁定，请求已拒绝的锁定，死锁，锁定响应延迟
• 牺牲处理器Sacrificial processes：允许失败的处理器并且用可控方式恢复
• 文件系统：文件不能被找到，打开，读，写，权限变更，文件系统识别介质错误，介质移除，介质装满
• 网络：网络中断，网络忙碌/缓慢，传输段丢失、损坏、无序，处理器之间的对话被中断
• 内存：不足以给请求的分配，碎片
• 已达到的限制：排队，licences，线程，连接，数组大小，资源分配
2.5. 并发
测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据，数据库条目，文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源，简单，定制的工具可能有些帮助, 并且在他们选择的时候发布它。测试也应该检查第二个请求者最终得到了资源。更加复杂的测试将着眼于二个以上的请求, 排队, 超时和死锁。
2.6. 用例和误用的用例
用例，在实践中趋向于处理系统的‘happy path’。各种错误输入的覆盖，拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语，虽然不是偏僻的标准，但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计，并且允许一个正式的方法来测试选择和覆盖.
文章来源于领测软件测试网 https://www.ltesting.net/
