软件测试是保证软件产品质量的方法，它能够让APP运行稳定，核心功能正常，所以对于一个互联网的公司来说，软件测试环境是非常必要的。
互联网公司产品迭代速度非常迅速，需求变更也较为频繁，于是软件测试和传统软件行业的测试方式也有许多不同，在传统软件行业中，为了最大限度的保证软件质量，测试的流程往往非常繁琐，整个产品从研发到测试再到发布往往会经历非常长的时间周期，这种测试方式不太适合追求快速更新的互联网软件。所以，为了适应这种迭代速度，我们会在测试工作中引入故障模型。
1.故障模型的必要条件
故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。测试人员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。它具有一定的形式和足够的信息对错误进行预测，因此对测试人员来说，构造一个准确的故障模型，是选择测试策略、设计测试用例和测试执行的基础。
在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。
一个成熟的故障模型必须具备下列条件：
1）该模型是符合实际的：大多数系统中存在的故障都可以用该模型来表示；
2）模型下的故障个数是可容忍的：模型下的故障个数一般和系统的规模是成线性关系；
3）模型下的故障是可以测试的：存在一个算法，利用该算法可以检测模型中的每一个故障。
2.故障模型的实际应用
在实际工作中，我主要会建立以下几种常用的故障模型。
（1）输入型故障模型
主要是对用户的各种输入进行建模，因为用户的输入是无法预期的，可能的组合状态也是千变万化。软件功能除了能让正确的输入得到正确的输出之外，还必须对非法和不合逻辑的输入进行处理，防止因数据异常造成不可挽回的错误。
典型的建模方法有：
◆ 使用非法数据：从输入数据的类型、长度、边界值等方面考虑，测试软件是否允许不正确的输入进入系统并进行处理，是否有错误处理代码，代码是否正确。
◆ 使用默认值输入：检测软件中所使用的变量是否初始化，是否将非法数据默认为合法边界内的某个合理值。
◆ 使用特殊字：检测软件是否正确处理了特殊字符和数据类型。
◆ 使用使缓冲区溢出的合法输入：输入超过允许的最大长度的数据，检测软件是否检查字符串/缓冲区的边界。
◆ 使用可能产生错误的合法输入组合：测试多个输入值的组合，确认这些值的组合是否会互相影响而引起软件失效。
◆ 重复输入相同的合法输入序列：检测软件是否考虑了循环处理的边界。
（2）输出型故障模型
软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。
例如：
◆ 通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证；
◆ 可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误；
◆ 强制修改输出的属性、查看输出结果，测试初始化代码和修改代码是否同步；检查用户界面刷新情况，在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。
在大多数的软件中，功能输出的正确与否直接决定了软件实现的好坏，输出型故障模型所覆盖的故障也占有相当大的比例。因此，我们在测试过程中应建立这种故障模型，从故障结果进行分析，判断造成故障的影响因素。
（3）流程型故障模型
这是一种程序控制流的故障模型，是对在程序中同样占很大比例的循环结构和分支结构建立的模型。循环故障主要包括永不循环故障和死循环故障，这主要是由循环条件错误引起的。
循环条件的错误中包括变量错误和运算符错误，在未执行循环之前，循环变量的初值设置出错以致永不循环；进入循环以后，循环变量的值不作修改以致发生死循环。
而分支故障则包括判定条件故障和谓词结构故障，由于判定条件的出错或者变量初值设置错误而导致不执行分支结构；对于进入了分支结构的执行，可能因为谓词的错误而提前退出分支结构。
由此可知，流程型故障模型很可能是由一串连续的故障所组成的。因此在软件功能测试中，我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。
（4）资源型故障模型
资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下，运行被测程序进行测试。此类故障模型的建立通常需要辅助测试工具进行环境的模拟。
当磁盘负荷到达一定程度或可用物理资源十分有限时，系统进程十分容易进入“死锁”状态或出现不可恢复的错误。产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。显然，由于资源有限，不可能为所有要求资源的进程无限制地提供资源。
但是，可以采用适当的方法，以达到消除或规避“死锁”的目的。因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。所以我们应该建立这种故障模型，并给出相应的测试用例。
以上这几种故障模型的建立对于故障定位、故障分析是非常有用的，在此基础上建立故障模型资源库，可以较为快速地对软件设计测试用例并且进行测试。
当然实际的软件测试工程中，由于软件功能的多样性，软件故障同样也存在多样性，所以还有很多其他的故障模型有待于进一步细化和探讨。
作者简介：曾航，英文名Henry，校导网测试工程师，拥有3年硬件测试经验与3年软件测试经验，曾经在法国工作2年，熟悉国内外主流软硬件测试流程。