测试的目标是要发现错误，因此在编写测试用例的时候也要遵循这个目标，尽量在软件的最薄弱环节多编写测试用例。虽然测试时有很多单个输入变量、多个输入变量的组合，但优秀的软件测试人员不会依靠运气，他们有着丰富的经验和直觉，可以从中找到哪些是需要进行测试的，哪些不需要测试，哪些操作可能会引起软件失效。把这些测试人员的经验和直觉尽量归纳和固化，就形成了一些故障模型。故障模型指明了故障是如何以及为什么会在软件执行时引起软件失效。在测试过程中，我们可以按照这些故障模型所提供的缺陷类型和寻找该类缺陷的方法找到尽量多的缺陷。
1、输入非法数据
1.1 缺陷产生原因
开发人员通常用以下3种技术来处理非法输入：
◆ 防止不正确的输入进入被测软件。过滤掉不正确的输入，只允许合法输入通过界面。
◆ 输入了不正确的数据后，软件提示错误信息，拒绝不正确的输入。
◆ 允许不正确的输入进入系统并进行处理，软件失效时调用异常处理程序，显示一些错误信息。
可见开发人员除了编写主要的功能代码外，还必须编写对非法输入的检查代码，这些代码经常被遗忘，或者编写完这部分代码后，开发人员很少认真检查，导致处理非法输入经常出错。
1.2 如何发现这类问题
进行测试时从输入值的属性出发，一般考虑以下三点：
◆ 输入类型：键入无效的类型常会产生错误信息。
◆ 输入长度：对于字符型，键入太多的字符常会引出错误信息。
◆ 边界值：输入边界值或超过边界值的数据。
1.3 测试方法小结
◆ 应用场合：GUI的输入。
◆ 测试方法：分别从输入数据的类型、长度、边界值等方面进行考虑。
◆ 测试信息检查：
● 错误信息和错误要一致。
● 错误信息的内容为空，用户不知道为什么出错。
● 显示的错误信息是给开发人员调试使用的，例如“Error 5-unknown data”，开发人员可以通过该信息很容易找到错误类型，但是用户根本不明白，不知道做错了什么。
◆ 测试知识储备：牢记各基本数据类型的边界值。
2、输入默认值
2.1 缺陷产生原因
一旦软件中使用了变量，就必须赋给初始值，如果在赋值之前就使用了这些变量，软件就会失效，正确地使用变量的顺序是：声明变量à给变量赋值à使用变量。通常会由于以下两个原因使变量的默认值不正确：
◆ 给变量赋值这一步经常会被开发人员不经意地路过。
◆ 开发人员有时不确定到底要赋什么初始值，就随便给了一个值，但用户并不认可该值，这种情况下，软件并不一定会失效，但对用户的使用会带来很多不便。例如某程序把打印默认输出份数设置为2份，会给用户造成很大麻烦。
2.2 如何发现这类问题
确定应用软件中所使用的数据有以下一些基本原则：
◆ 查找选项按钮、配置面板、安装屏幕等。这种屏幕上显示的数据常常在应用程序的许多地方用到。
◆ 查阅源代码的数据声明部分（如果可以得到）。
◆ 确定了要测试的数据，可以通过以下操作来强制使用或不使用默认的值：
● 接受软件显示的默认值。有时软件需要用户输入一个值，如果没有输入任何值，软件就可能失效。这时可以只是简单的单击“确定”按钮来接受默认值，完成这个功能测试。
● 键入空值。删掉默认值，使输入域变成空值。
● 将默认值改为另一个值，这样会使应用程序以不同的值来运行。
● 将输入值改为另一个值，然后再变以空值。
一个好的软件会这样处理以上情况，将输入的不合法内容默认为合法边界内的某个合理值，或者返回错误提示信息。
2.3 测试方法小结
◆ 应用场合：需要有默认值的地方。
◆ 测试方法：分别从选项按钮、配置面板、安装配置、开始界面等方面进行考虑，强制使用或不使用默认值等。
◆ 测试知识储备：全面理解需求规格说明书中对默认值的要求；同时深刻理解被测软件的行业背景。
3、输入特殊字符集
3.1 缺陷产生原因
应用程序接受字符串输入，如果程序没有针对特殊输入进行特殊编程，那么就有可能导致程序
挂起，主要包括以下3种情况：
◆ 字符集包括普通字符和特殊字符。例如，ASCII字符集包括普通字符和特殊字符。应用程序有时只能处理普通字符，当输入特殊字符时就会出现错误。
◆ 实现应用程序的程序设计语言有特定的处理一些字符和字符串的方法。例如，C语言把\n、++和&这样的字符用于特殊目的。如果将这些字符串键入到对话框中，程序必须进行错误处理，否则容易产生错误。
◆ 应用程序有时也使用设置名称、系统对象和程序的保留字符串集合。只要在程序中使用了这些字符串，就可能导致失效。
3.2 如何发现这类问题
◆ 根据被测软件所处的操作系统、使用的程序设计语言、字符集等信息列出表格，通过测试小组的讨论，标明应用表格中的哪些字符和数据类型作为输入来测试。
◆ 根据经验，软件很少会因为这种操作而崩溃，通常它会挂起没有响应。
3.3 测试方法小结
◆ 应用场合：需要接受字符输入的地方。
◆ 测试方法：根据被测软件的具体情况输入非法字符。
◆ 测试知识储备：尽可能多地了多地了解字符集、程序设计语言和操作系统中的保留字符串及其特定含义，可以使我们更好地分辨这类缺陷。
4、输入使缓冲区溢出的数据
4.1 缺陷产生原因
开发人员没有考虑传送给内存缓冲区的字符串的大小。如果缓冲区只能保留固定长度的字符串，输入更长的字符串就会改写其他的内存存储单元，引起操作系统强制性地终止应用程序。
4.2 如何发现这类问题
当应用程序允许输入字母、数字时，通过GUI控件（如文本框），或者通过API调用的参数来进行这种测试。
◆ 首先弄清楚要测试的输入域的长度，输入最大字符串测试。
◆ 输入一个比最大字符串长的字符串，应用程序可能出现错误提示信息，提示不允许输入；或者输入了更长的字符串使应用程序崩溃。
4.3 测试方法小结
◆ 应用场合：需要接受字符输入的地方。
◆ 测试方法：根据被测软件的具体情况输入最大字符串或输入一个比最大字符串更长的字符串。
◆ 测试知识储备：尽可能多地和开发人员讨论，以了解和确定输入域的合理长度。
5、输入产生错误的合法数据组合
5.1 缺陷产生原因
测试多个输入值的组合，每个输入值已被单独测试过，但是这些值的组合可能会互相影响而引起软件失效。
5.2 如何发现这类问题
首先要确定测试哪些输入组合，并弄清楚它们之间的“关系”。如果具备以下任一特性，就可以认为这些变量是有“关系”的。
◆ 描述的是有关单个内部数据结构的属性和内容。例如，输入面板需要用户输入列表的“行”和“列”，这时测试人员要输入单个内部数据结构“列表”的属性“行和列”。
◆ 一起用在了一个计算中，也就是将多个输入用做一个内部计算的操作数，因此这些输入变量具有了相互“关系”。
5.3 测试方法小结
◆ 应用场合：输入值之间存在依赖关系。
◆ 测试方法：输入可能是存在问题的组合值。
◆ 测试知识储备：尽可能多的内部数据结构的属性和内容，并与开发人员探讨，以确定输入的数据值。
6、产生同一个输入的各种可能输出
6.1 缺陷产生原因
单个输入产生多种输出的情况与先前的输入和被测系统的状态都有关系。例如，在文字处理程序中单击“关闭”按钮，如果文件被编辑且未被保存，程序将提示是否保存文件。如果文件已被保存过，则文件直接关闭。
6.2 如何发现这类问题
测试人员必须具有关于被测系统软件的业务方面的知识，具备各种程序文档，明确一个输入可以产生何种输出。我们可以据此列出关于程序输入与输出的一个列表，然后进行测试。
6.3 测试方法小结
◆ 应用场合：同一输入对应多个输出的情况。
◆ 测试方法：测试输入对应的每一个输出。
◆ 测试知识储备：全面理解需求规格说明书中的内容，找出输入与输出之间的关系。
7、输出不符合业务规则的无效输出
7.1 缺陷产生原因
有时开发人员也可能对业务了解不深刻，对有些问题也是一知半解，因此编写出的软件就会产生不符合业务逻辑的问题。另外在绝大多数情况下开发人员会忽略处理没有遵循一般规则的输入，如果不对这些特殊情况进行编程处理，软件就会产生错误的结果。
7.2 如何发现这类问题
◆ 测试人员应该尽可能地学习的涉及问题的领域。
◆ 有时在列举出无效输出后，也很难知道哪些输入组合能强制这些输出产生。这时测试人员必须先要确定哪些输入与输出有关，然后用产生意外结果的输入组合进行测试，测试过程中要注意输入执行顺序，用不同的顺序执行可能得到不同的结果。如果不能强制无效的输出产生，就说明软件没有这方面的缺陷。
7.3 测试方法小结
◆ 应用场合：强制产生不符合业务背景的知识。
◆ 测试方法：列举出所有的无效输出，然后逐一测试。
◆ 测试知识储备：全面理解需求规格说明书中的内容，熟悉行业背景知识。
8、输出属性修改后的结果
8.1 缺陷产生原因
输出常常具有可修改的属性，如颜色、形状、维数及大小等，用户可以修改这些属性。在这种情况下，开发人员必须编码、设立初始或默认属性值，然后编码允许用户编辑这些属性。当用户改变了这些属性后，内部的相应变量值也随着变化，再次进行处理时，这些值没有被重新恢复为默认值，输出的属性就被强制改变了。
8.2 如何发现这类问题
该测试方法可以使用在那些输出具有可编辑性、可修改性的功能中。测试人员首先要仔细了解能够产生的输出，特别要注意具有可编辑属性的输出。测试人员的任务就是强制每个输出产生，并编辑其属性，然后再次强制输出产生。
8.3 测试方法小结
◆ 应用场合：输出的结果，可以由用户修改属性得出。
◆ 测试方法：强制每个输出产生，并编辑其属性，然后再次强制产生输出。
◆ 测试知识储备：全面理解需求规格说明书中的内容，了解能够产生的输出。
9、屏幕刷新显示
9.1 缺陷产生原因
通常GUI软件会产生刷新问题，因为GUI在对窗口进行覆盖、移动和调整大小时，必须刷新屏幕才能使对象重新显示。但是如果经常刷新，容易减慢应用程序的运行速度；如果不刷新，又会影响用户对程序的使用，使用户必须停止工作，去寻找刷新的方法才可以继续工作。所以开发人员有时候不能很好地确定什么时候需要刷新，需要刷新多大范围的区域，这就发生了令人烦恼的刷新问题。
9.2 如何发现这类问题
测试刷新问题的方法是增加、删除称移动屏幕上的对象，这样会使某些对象重新显示。如果不能正确、及时地进行重新显示，就产生了软件缺陷。我们可以通过以下几个方法来检查刷新：
◆ 从起始位置移动对象。先移动一点，然后增加移动幅度；先移动一次或两次，然后多次移动，确保覆盖了所有区域。
◆ 从覆盖对象的边界开始一点点覆盖，使其中一个对象遮住别一个对象。
◆ 使用不同类型的对象。如果应用程序支持多种类型的对象，如文本对象、图形对象等，就把这些不同对象混在一起使用。
9.3 测试方法小结
◆ 应用场合：一个对象包含在另一个对象中，拖动被包含对象时，可能出现刷新问题。
◆ 测试方法：增加、删除和移动屏幕上的对象。
◆ 测试知识储备：全面理解需求规格说明书中的内容，了解程序中对象之间的关系。
10、数据结构溢出
10.1 缺陷产生原因
所有数据结构的大小都有上限。一些数据结构会逐步增加长度以充满机器内存容量或磁盘空间，而其它数据结构具有固定的上限。开发人员经常对有关数据结构的内容进行编码，忘记结构本身的物理局限。
10.2 如何发现这类问题
◆ 确定数据结构的界限，尝试将过多的值输入数据结构。应该特别注意界限为数据类型的边界256、1024、32768等上溢的测试。
◆ 对于下溢的测试，可以尝试多删除一个数据，例如当结构为空时，尝试再删除，或者添加一个数据，尝试删除两个数据时的情况。
10.3 测试方法小结
◆ 应用场合：程序中存在数组。
◆ 测试方法：尝试将过多的值输入数据结构，测试上溢；对于下溢的测试，可以尝试多删除一个数据。
◆ 测试知识准备：全面理解需求规格说明书中的内容，确定数据结构的界限。
11、数据结构不符合约束
11.1 缺陷产生原因
在编程过程中对内部数据结构都有所约束，包括大小、维数、类型、形状、屏幕上的位置等。我们测试的重点就是用户能够设置的属性，这些属性使用了一组参数来约束。在建立数据项和随后对数据项进行修改的任何时刻都要对数据属性的约束进行检查。初始化代码中修改后的代码有错误，在修改错误的时候只修改了初始化部分，而忽略了对其他部分的修改，使得其修改不完全，不彻底。
11.2 如何发现这类问题
◆ 确认候选数据，并列出其可修改的属性。对每个属性列出有效值的允许范围、约束的条件等。
◆ 确定所有可修改属性的功能位置。
◆ 对数据进行初始化，改变每个属性以确定是否正确进行了约束。
如果数据约束遭到破坏，可能导致系统崩溃，或者表现为响应时间延迟，错误信息不正确以及使用错误数据产生的无效输出。
11.3 测试方法小结
◆ 应用场合：应用程序内部的数据结构存在约束。
◆ 测试方法：破坏内部数据结构的约束。
◆ 测试知识储备：全面理解需求规格说明书中的内容，确定内部数据结构的所有约束。
12、操作数与操作符不符
12.1 缺陷产生原因
几乎每个运算符都有它无效的操作数，对于具体的操作符，开发人员在使用它们时，必须编写错误检查代码。例如：除以零的问题。
12.2 如何发现这类问题
找到程序中包含的数据或输入（即操作数）的计算（即操作符）、数学表达式（即操作符和操作数的组合）及对图形的操作。另外，对多个操作数进行组合也更容易发生错误。例如，字符和数字都可以使用“+”操作符。对字符通过“+”把它们连成一串；对数字通过“+”来进行加法运算。如果系统尝试把字符和数字相加，即进行相互矛盾的操作，就会引起软件失效。
12.3 测试方法小结
◆ 应用场合：需要进行数值计算的程序或图形操作的程序。
◆ 测试方法：对于数值计算考虑操作数和操作符之间的限定关系，对于图形计算还要考虑各种输入数据之间的组合关系。
◆ 测试知识储备：全面掌握被测软件中操作符对操作数的要求。掌握不同的操作符和操作数具有的不同的有效和无效的取值范围。
13、递归调用自身
13.1 缺陷产生原因
函数有时会递归调用自身，如果不限制执行次数，递归就会出现问题，它不断地调用自身，很快地占用机器资源，最终产生溢出，使程序崩溃或挂起。产生这类问题的主要原因是开发人员没有编码来保证循环和递归调用的终止，通常是在循环的开始或结束时缺少检查条件。
13.2 如何发现问题
在软件中寻找可以使用递归调用的功能。这时可以制作一个列表，标明软件中可能嵌入递归的功能的列表，然后自己引用自己来检查程序是否能正确处理。
13.3 测试方法小结
◆ 应用场合：需要和其它对象进行交互的地方。
◆ 测试方法：考虑对象的自我交互或复制。
◆ 测试知识储备：全面掌握被测软件的需求。
14、计算结果溢出
14.1 缺陷产生原因
当所有的输入和数据都有效时，计算的最终结果也可以是无效的。所有变量都有值域范围，有时开发人员在执行计算时会忘记检查这些上限。
14.2 如何发现这类问题
一次又一次地执行计算或使用很大或很小的输入和数据进行计算，重点测试数据类型的初始值或边界值附近的值。
14.3 测试方法小结
◆ 应用场合：应用程序执行能够导出待产生结果并进行内部存储的计算。
◆ 测试方法：强制数据产生上溢或下溢。
◆ 测试知识储备：全面掌握被测软件的需求，了解计算变量的上下限。
15、数据共享或关联功能计算错误
15.1 缺陷产生原因
通常对孤立的功能进行测试时不会发生很多缺陷，而当把单独的功能和同一软件中的其它功能结合时，就可能出现很多软件缺陷。这种缺陷的产生往往是在两个或更多的功能使用了共享数据集，而每个功能允许使用的数据范围不同引起的。例如，一个功能可能会将某数据项设置为特定大小，然而另一个功能却允许该数据项的大小可以超过第一个功能的处理能力。开发人员根本没考虑到该数据项在其它功能处也可以修改，他们只是编码保证在该功能中数据的合法性，而当使用该数据时，没有再编码来检查可以使用的范围；而此时，另一个功能修改了共享数据，当再使用这些数据时就产生了缺陷。
15.2 如何发现这类问题
当应用程序在同一时间完成一个以上的功能或当一个以上的功能在同一时间处于运行状态时，就可以使用该方法进行测试。利用一个功能影响输入、输入数据或另一个功能的计算。在测试前要确定哪些功能是相互依赖或共享数据的：
◆ 能应用同样输入的每个功能。如果这些功能有相互重叠的输入域，就可能存在交互问题。
◆ 有类似的输出产生功能。如果某些功能结合起来产生单个输出，就说明这些部件之间存在关系，应该被一起测试。
◆ 一个功能被包含在另一个功能的计算中。例如要测试鼠标选取对象的功能，不仅要测度鼠标选取屏幕上的文本的功能，还可以把包含超链接文本、粗体、斜体、符号及图形元素放在一起，测试鼠标选取这些元素的功能。
15.3 测试方法小结
◆ 应用场合：一个以上的功能在同一时间处于运行状态。
◆ 测试方法：以点代面，重点测试某一功能，对可能与这个功能相连的其它功能附带测试。
◆ 测试知识储备：全面掌握被测软件的需求，在测试之前对被测功能之间的依赖关联有所掌握，另外还需要对共享数据有所掌握。
16、文件系统超载
16.1 缺陷产生原因
开发人员可能会忘记编写代码处理满状态的文件系统，忽略了诸如CreateFile，WriteFile等操作系统API的错误检查代码，没有这样的代码，当显示满状态的文件系统时，API调用就会失败，软件就会在没有任何警告的情况下崩溃。
16.2 如何发现这类问题
创建满容量或近乎满容量的文件系统，然后强制执行各种通过输入或输出访问文件系统的操作；或者打开足够多的文件，打开文件时会强制备份创建的副本，从而占用双倍的存储空间，这种操作达到一定程度时，会达到该系统的容量，于是就能测试应用程序处理超载状态的文件系统的能力。（通常通过磁盘配额实现）
16.3 测试方法小结
◆ 应用场合：系统较大，运行时需要较大的空间。
◆ 测试方法：强制磁盘系统满容量或容量小于等于被测软件运行时所需容量后，运行被测软件或利用测试工具模拟磁盘状况。
◆ 测试知识储备：全面掌握被测软件的需求，了解被测软件处理超载状态的文件系统的能力。
17、介质忙或不可用
17.1 缺陷产生原因
当多个应用程序同时访问硬盘（或其它存储器），操作系统为提供多请求服务会慢下来，并且必须对应用程序进行编程以处理这些延迟，当延迟变得很长时，没有对这些错误进行响应的应用程序就会出现错误。
17.2 如何发现这类问题
通过启动大量应用程序，强制它们都打开并保存文件使文件系统处理繁忙状态；或者同时下载大量文件也可以使后台拥挤；检查被测软件能否正确处理这种情况，应用程序应该给出错误信息或等待批示，提示用户正在处理。
17．3测试方法小结
◆ 应用场合：应用程序的运行需要消耗大量内存或运行时需要其它相关软件同时运行。
◆ 测试方法：启动大量程序或利用测试工具模拟磁盘状况。
◆ 测试知识储备：全面掌握被测软件的需求，了解被测软件运行时对系统的要求。
18、介质损坏
18.1 缺陷产生原因
◆ 损坏的介质可能会使操作系统传回错误代码，这些错误代码没有在应用程序中编程处理。
◆ 操作系统不能检测出所有这样的错误，操作系统自己也有错误或者损坏的介质损坏了部分操作系统。
18.2 如何发现这类问题
使用损坏了的介质，例如，刮伤、灰尘、磁干扰等。检查应用程序对错误的处理能力，应用程序可以对错误进行处理或者将问题告诉用户，并要确保用户数据文件不丢失、为损坏。
18.3 测试方法小结
◆ 应用场合：应用程序对安全的要求较高，对灾难恢复的要求较高。
◆ 测试方法：用实际损坏介质的方法测试应用程序。
◆ 测试知识储备：全面掌握被测软件的需求，了解被测软件运行时对系统的要求。
19、文件名不合法
19.1 缺陷产生原因
操作系统本身具有自己的文件命名规范，例如，Dos的8.3格式。在Windows中，文件名不能超过255个字符，并且文件名不可以含有/ \ : < > ? * |这8个字符，以及AUX、COM1、COM2、COM3、COM4、CON、LPT1、LPT2、LPT3、LPT4、NUL及PRN这些操作系统保留字。
开发人员在应用程序中使用不相同的规则管理文件名，当应用程序和操作系统使用的文件名命名规则不一致的时候，就会发生问题。
19.2 如何发现这类问题
◆ 保存文件为操作系统不允许的文件名，例如，文件名中含有/ \ : < > ? * |这8个字符，测试应用程序是否不允许输入包含这些字符的文件名。
◆ 输入一些应用程序不允许使用的文件名，例如，使用过长的、含有特殊字符的、可能相互作用的字符作为文件名，检查应用程序能否识别该文件。
19.3 测试方法小结
◆ 应用场合：几乎所有涉及需要输入文件名功能的应用程序。
◆ 测试方法：输入操作系统不允许的文件名和应用程序不允许使用的文件名。
◆ 测试知识储备：全面掌握被测软件的需求，了解操作系统和应用程序对文件名的要求。
20、更改文件访问权限
20.1 缺陷产生原因
在操作系统中，可以设置不同用户对不同的文件具有不同的访问权限（如读写、只读等）。程序员必须在访问文件的函数中考虑文件的访问权限，例如在每个文件写入之前检查文件的访问权限。如果没有进行检查，就会导致程序出错。另外，如果文件访问失败，程序员必须要有正确的错误的代码，以保证程序可以正确捕获所产生的错误。
20.2 如何发现这类问题
◆ 打开两个应用程序，关闭同一个文件。例如，把同一个应用程序的不同版本安装在同一机器上，在不同版本的应用程序中打开和关闭同一文件，或试着在某个应用程序中打开在另一个程序中已打开的文件，这可能导致文件访问权限的冲突。
◆ 打开一个文件，在操作系统中修改文件的访问权限。有些操作系统允许权限高的用户控制一般用户已经打开的文件。
20.3 测试方法小结
◆ 应用场合：需要对文件进行读写操作的应用程序。
◆ 测试方法：修改文件访问权限或使用低权限的用户访问文件。
◆ 测试知识储备：全面掌握被测软件的需求，了解读写文件所需的权限。
21、文件内容受损
21.1 缺陷产生原因
开发人员编写代码来读取和写入文件，他们也编写代码来调用系统API得到文件指针，并打开和关闭文件。由于某些原因，这些系统API会失败或传回异常返回值。如果开发人员没有编写代码来验证传回的预期返回值，则应用程序会由于无法处理异常而失败。
21.2 如何发现这类问题
◆ 手工损坏文件。从应用程序已创建的某个完整文件开始对其进行编辑，改变文件格式和内容。
◆ 使用测试工具。模拟CRC（循环冗余校验）错误，或强制文件API返回无效的返回码。
21.3 测试方法小结
◆ 应用场合：需要对文件格式和内容进行校验的应用程序。
◆ 测试方法：手工损坏文件或利用测试工具模拟CRC错误。
◆ 测试知识储备：全面掌握被测软件的需求，了解文件读写需要的权限。
