3. 输出型故障模型

　　软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证；可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误；强制修改输出的属性、查看输出结果，测试初始化代码和修改代码是否同步；检查用户界面刷新情况，在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。

　　在大多数的软件中，功能输出的正确与否直接决定了软件实现的好坏，输出型故障模型所覆盖的故障也占有相当大的比例。因此，我们在测试过程中应建立这种故障模型，从故障结果进行分析，判断造成故障的影响因素。

　　4. 计算型故障模型

　　对于部分软件程序，常需要进行大量的计算，因此该模型应该尽可能包括关于计算方面的各种错误。包括变量的定义与使用方面的错误；数据的冗余；数组变量的越界错误；数据类型不匹配的错误；还有数据操作方面错误，包括函数调用参数传递错误、赋值语句错误等。在建立计算型故障模型的时候，要定义数据并且对这些数据执行各种故障操作，尽可能使模型比较完善。体现在功能层面上，可以使用非法的操作数和操作符组合来验证计算要求的合法性、强制使计算结果溢出考虑数据结构存储的正确性、同时对数据进行操作检测数据共享性等方法来建立故障模型。

　　5. 流程型故障模型

　　这是一种程序控制流的故障模型，是对在程序中同样占很大比例的循环结构和分支结构建立的模型。循环故障主要包括永不循环故障和死循环故障，这主要是由循环条件错误引起的。循环条件的错误中包括变量错误和运算符错误，在未执行循环之前，循环变量的初值设置出错以致永不循环；进入循环以后，循环变量的值不作修改以致发生死循环。而分支故障则包括判定条件故障和谓词结构故障，由于判定条件的出错或者变量初值设置错误而导致不执行分支结构；对于进入了分支结构的执行，可能因为谓词的错误而提前退出分支结构。

　　由此可知，流程型故障模型很可能是由一串连续的故障所组成的。因此在软件功能测试中，我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。

　　6. 资源型故障模型

　　资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下，运行被测程序进行测试。此类故障模型的建立通常需要辅助测试工具进行环境的模拟。当磁盘负荷到达一定程度或可用物理资源十分有限时，系统进程十分容易进入“死锁”状态或出现不可恢复的错误。产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。显然，由于资源有限，不可能为所有要求资源的进程无限制地提供资源。但是，可以采用适当的方法，以达到消除或规避“死锁”的目的。因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。所以我们应该建立这种故障模型，并给出相应的测试用例。

　　7. 结论

　　故障模型的建立对于故障定位、故障分析以及生成相应的测试用例是非常有用的。本文在前人研究的基础上，仅仅从软件功能层面出发，提出了五种常用的故障模型。而在实际的软件测试工程中，由于软件故障原因的多样性，还有很多故障模型有待于进一步细化和探讨。