软件测试方法——黑盒测试
1、黑盒测试概念
黑盒测试法也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试主要发现以下类型的错误：
- 基于规格说明的功能错误
- 基于规格说明的构件或系统行为错误
- 基于规格说明的性能错误
- 面向用户的使用错误
- 黑盒接口错误
2、黑盒测试特点
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
总体来说，黑盒测试有以下特点：
- 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；
- 测试人员不需要了解软件的实现细节，包括特定的编程语言；
- 从用户的视角进行测试，很容易被理解和接受；
- 有助于暴露任何规格不一致或有歧义的问题；
- 没有清洗和简明的规格，测试用例很难设计；
- 不能控制内部执行路径，会有很多内部程序路径没有被测试到；
- 不能直接针对特定的程序段，这些程序可能非常复杂（因此可能隐藏更多的问题）
3、黑盒测试方法
3.1、等价类划分法
等价类划分法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。
3.1.1、等价类划分法的应用
等价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。
由于等价类是在需求规格说明书的基础上进行划分的，并且等价类划分不仅可以用来确定测试用例中的数据的输入输出的精确取值范围，也可以用来准备中间值、状态和与时间相关的数据以及接口参数等，所以等价类可以用在系统测试、集成测试和组件测试中，在有明确的条件和限制的情况下，利用等价类划分技术可以设计出完备的测试用例。
3.1.2、有效等价类划分
有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明预先规定的功能和性能。有效等价类可以是一个，也可以是多个，根据系统的输入域划分若干部分，然后从每个部分中选取少数有代表性数据当做数据测试的测试用例，等价类是输入域的集合。
3.1.3、无效等价类划分
无效等价类和有效等价类相反，无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。
3.1.4、等价类划分的方法
按区间划分:在输入条件规定的取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。
按数值划分:在规定了输入数据的一组值中（假定有n个值），并且程序要对每个输入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类。
按数值集合划分:在规定输入数据必须遵守的规则的情况下，可以确定一个有效等价类和若干个无效等价类。
按限制条件或规划划分:在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类。
按处理方式划分:在确定已划分的等价类中各元素在程序处理中的方式不同的情况下，则应将该等价类进一步地划分为更小的等价类。
3.1.5、等价类划分的原则
1、依据常用的原则划分等价类
2、为每一个等价类规定唯一的编号
3、设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有有效等价类都被覆盖为止。
4、设计一个新的测试用例，使其覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等类都被覆盖为止。
3.1.6、等价类划分实例
假设要输入一个日期，日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。
1)划分等价类并编号,下表等价类划分的结果
| 输入等价类 |
有效等价类 |
无效等价类 |
| 日期的类型及长度 |
①6位数字字符 |
②有非数字字符 ③少于6位数字字符 ④多于6位数字字符 |
| 年份范围 |
⑤在1990~2049之间 |
⑥小于1990 ⑦大于2049 |
| 月份范围 |
⑧在01~12之间 |
⑨等于00 ⑩大于12 |
2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：
| 测试数据 | 期望结果 | 覆盖有效等价类 |
| 200211 | 输入有效 | ①、⑤、⑧ |
3)为每一个无效等价类设计一个测试用例，设计结果如下：
| 测试数据 | 期望结果 | 覆盖无效等价类 |
| 95June | 无效输入 | ② |
| 20036 | 无效输入 | ③ |
| 2001006 | 无效输入 | ④ |
| 198912 | 无效输入 | ⑥ |
| 200401 | 无效输入 | ⑦ |
| 200100 | 无效输入 | ⑨ |
| 200113 | 无效输入 | ⑩ |
3.2、边界值分析法
3.2.1、概念
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
3.2.2、边界值分析法应用
根据大量的测试统计数据，很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
3.2.3、边界值分析法与等价值划分法的区别
边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。
边界值分析法与等价类分析法的区别：
1、边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2、边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。入条件，还要考虑输出空间产生的测试情况。
3.2.4、边界值分析
通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。利用边界值作为测试数据.
| 项 |
边界值 |
测试用例的设计思路 |
| 字符 |
起始-1个字符/结束+1个字符 |
假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。 |
| 数值 |
最小值-1/最大值+1 |
假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。 |
| 空间 |
小于空余空间一点/大于满空间一点 |
例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。 |
3.2.5、内部边界值
在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种：
1、数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。
| 项 |
范围或值 |
| 位（bit） |
0 或 1 |
| 字节（byte） |
0 ~ 255 |
| 字（word） |
0~65535（单字）或 0~4294967295（双字） |
| 千（K） |
1024 |
| 兆（M） |
1048576 |
| 吉（G） |
1073741824 |
2、字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。如下列出了一些常用字符对应的ASCII码值。
| 字符 |
ASCII码值 |
| 空 (null) |
0 |
| 空格 (space) |
32 |
| 可输入的字符 |
33~126 |
| 0~9 |
48~57 |
| A~Z |
65~90 |
| a~z |
97~122 |
3、其它边界值检验：在不同的行业应用领域，依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值：
| 硬件设备 |
范围或值 |
| 手机锂电池电压 |
工作电压：3.6~4.2V； 保护电压：2.5~3V不等 |
| 手机正常使用温度 |
-25°C~+60°C |
3.2.6、边界值分析原则
1、如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围边界的值作为测试输入数据。
2、如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据。
3、根据规格中每个输出条件，使用原则1，如果输出条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围边界的值作为测试输入数据。
4、根据规格中每个输出条件，使用原则2，如果输出条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试数据。
5、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
6、分析规格说明，找出其他可能的边界条件。
3.3、错误推测法
3.3.1、概念
错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
总之，就是进行错误的操作。
3.3.2、错误推测法的应用
1. 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
2. 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：
1) 程序是否把空格作为回答
2) 在回答记录中混有标准答案记录
3) 除了标题记录外，还有一些的记录最后一个字符即不是2也不是3
4) 有两个学生的学号相同
5) 试题数是负数
3. 例如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：
1) 输入的线性表为空表；
2) 表中只含有一个元素；
3) 输入表中所有元素已排好序；
4) 输入表已按逆序排好；
5) 输入表中部分或全部元素相同。
4. 例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：
1) 无SIM 卡插入时进行呼出（非紧急呼叫）
2) 插入已欠费SIM卡进行呼出
3) 射频器件损坏或无信号区域插入有效SIM卡呼出
4) 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
5) 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字
3.3.3、网上常见的用例参考
| 功能测试用例库 |
|
| 1.输入验证 |
|
| 输入验证主要包括：数字输入验证、非法字符输入验证、输入长度验证、必填项验证和信息提示 |
1.数字输入验证：分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值。不合法的输入，系统给出必要的判断提示信息 |
| 2.字符输入验证：分别输入单字节字符、双字节字符、大小写字符、特殊字符、空白值、空值。不合法的输入，系统给出必要的判断提示信息 |
|
| 3.日期、时间输入验证：分别输入任意字符、任意数字、非日期格式的数据、非正确日期(错误的闰年日期)、空值、空白值。不合法的输入，系统给出必要的判 断提示信息。注：有些系统会不让输入当日以后或者以前的日期、时间；有些系统会通过JavaScript来自动填写日期时间，这时需要注意是否能否人工主 观填写输入 |
|
| 4.多列表选择框：测试是否能否多选，列表框中的数据是否能否显示完全。当列表框的数据过多时，需要对数据有一定格式的排序 |
|
| 5.单列表下拉框：测试是否能否手工输入，下拉框中的数据是否能否显示完整。当下拉框的数据很多时，需要对数据有一定格式的排序。如果下拉框数据值过多时，下拉框可能会超出IE显示范围，此种情况不能够被接收 |
|
| 6.大文本输入框(textArea)：虽然它能够满足大数据量的输入，但最好能够显示地标明输入字符的长度限制，并且应该结合“字符输入验证”进行。需要注意的是，应该允许标点的存在 |
|
| 7.文件输入框输入验证：该输入框主要用做文件上传操作。在测试过程中，应该注意输入文件的扩展名。从测试角度来看，要求开发人员必须对扩展名进行输入限 制，并且在适当的地方输入格式提示。当输入是空值等不合法的输入时，系统给出必要的判断提示信息。另外，对于上传的文件大小应该做限制，不宜太大 |
|
| 8.输入字符长度验证：输入字符的长度是否超过实际系统接收字符长度的能力。当输入超出长度时，系统给出必要的判断提示信息 |
|
| 9.必填项验证：输入不允许为空的时候，系统需要有提示用户输入信息功能 |
|
| 10.格式、规则输入验证：当输入需要一定的格式时，系统需要有提示用户输入信息功能。比如身份证号码可以输入18位或者15位，部分身份证最后一位为字母，身份证上生日与身份证号码有一定规则 |
|
| 11.系统错误定位的输入验证：当输入存在问题时，被系统捕获到，此时页面上的光标能够定位到发生错误的输入框 |
|
| 12.单选框、多选框的输入验证：单选框需要依次验证单选框的值是否都有效；多选框需要依次验证多选框的值是否都有效 |
|
| 13.验证码验证：做验证码输入验证时，先结合“字符输入验证”进行测试，然后注意的地方是，当利用IE回退或者刷新时，显示的验证码应该和实际系统验证码一致。如果验证码以图片形式显示，但图片由于其他原因(如网络)不能看到或者显示不完整，系统应该允许进行重新获取，最好不要做整个页面刷新 |
|
| 2.操作验证(CZ) |
|
| 该用例库主要针对页面操作 |
1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确 |
| 2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确 |
|
| 3.检查按钮的功能是否正确：如增、删、改、查等功能是否正确 |
|
| 4.重复提交表单：一条已经成功提交的记录，用IE回退后再提交，看看系统是否做了处理 |
|
| 5.多次IE回退：检查多次使用IE回退的情况，在有回退的地方，回退，回到原来页面，再回退，重复多次，看是否出错 |
|
| 6.快捷键检查：是否支持常用快捷键，如Ctrl+C、Ctrl+V、Backspace等，对一些不允许输入信息的字段，如选人、选日期对快捷方式是否也做了限制 |
|
| 7.回车键检查：在输入结束后直接回车键，看系统处理如何，能否报错 |
|
| 8.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开，对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能否做到 |
|
| 9.其他验证：在页面上图片的大小不宜太大，需要第三方软件支持时，应该给出必要的信息，比如需要jre的支持，但用户机器还没有安装jre，那么此时在页面上应该有显著的标志来提醒用户进行安装 |
|
| 3.登录模块测试用例 |
|
| 该用例库主要针对登录模块。需要结合“访问控制验证(FWKZYZ)”用例库 |
1.登录名输入：进行“输入验证”。需要注意登录名是否区分大小写和空格 |
| 2.密码输入：进行“输入验证” |
|
| 3.提交操作：结合“访问空值验证(FWKZYZ)”。当输入正确的登录名和密码后，该用户能够进入到指定的正确页面。当输入的登录名和密码有误时，系统限制其登录，并且给出适当的提示信息。当遇到错误时，应该进行“错误页面测试” |
|
| 4.重设操作：当进行重设操作时，当前页面上所有输入项被清空 |
|
| 4.增加操作测试用例(ZJ) |
|
| 该用例库主要针对增加操作 |
1.添加输入内容，进行“输入验证” |
| 2.应该限制重复增加，具体操作：利用网络传输以及服务器的延迟，多次单击“增加”按钮，经常在数据库发现重复提交的数据 |
|
| 3.当增加成功或者失败后，应该有必要的信息提示 |
|
| 4.文件数据的增加：有些增加包含了数据库数据的增加，和一些文件的增加，此时的数据会保存在两个地方，所以测试时，需要对相关的数据做全面的验证 |
|
| 5.文件数据验证：进行“输入验证”值“文件输入框输入验证”。注意：当上传的文件为中文文件名时，上传到服务器后，可能会出现乱码现象。现在一般的做法是将原文件名替换成字母和数字的组合，以克服汉字文件名的弊端，另外，可以增加文件的安全性 |
|
| 5.删除操作测试用例(SC) |
|
| 该用例库主要针对删除操作 |
1.选择需要删除的数据字段。有时候系统会根据ID来删除，有时候系统会根据名称来删除，测试的时候应该多注意，一般要求按照ID来删除，因为根据名称来删除，名称可能会存在重名问题 |
| 2.应该限制重复删除。具体操作：利用网络传输以及服务器的延迟，多次单击“删除”按钮，经常在数据库中发现重复提交的数据 |
|
| 3.当删除的数据还有文件时，西药去验证存在数据库中的数据，以及硬盘下的文件是否都被同时删除 |
|
| 4.当数据被删除成功或者失败后，要有响应的信息提示 |
|
| 5.进行“操作验证” |
|
| 6.修改操作测试用例(XG) |
|
| 该用例库主要针对修改操作 |
1.打开需要修改的数据页面，注意与增加页面相比，只能修改部分数值，例如关键字等是不能被修改的，并且二者数据应该是一致的 |
| 2.增加页面上的输入限制与修改页面的输入限制应该一致 |
|
| 3.修改成功或者失败后，应该有相应的信息提示 |
|
| 7.查询操作测试用例(CX) |
|
| 该用例库主要针对查询操作 |
1.条件输入查询，先进行条件输入框的“输入验证” |
| 2.条件组合查询，将多个条件进行组合查询，结果可以通过数据库验证。需要注意的是，整个数据查询和条件查询数据结果条数要一致，另外，如果遇到某天的查询时间段，有的数据库认为一天不包括零点零分，有的数据库认为包括 |
|
| 3.所有查询结果，必须进行一定顺序的排列，可以按照ID或按照名称来排列 |
|
| 4.当查询成功或者失败后，系统应给出必要的信息提示 |
|
| 8.翻页操作测试用例(FY) |
|
| 该用例库主要针对翻页操作 |
1.当数据量很大的时候，需要进行分页显示，每页显示的行数最好不要超过20行，每页列表上最好有序号标识，行与行之间颜色要有一定区分，这样有利于用户的查找 |
| 2.翻页按钮应该包括：首页、前一页、后一页、尾页、当前X页、共X页，这些常用按钮和显示，并且按钮都能正常翻页 |
|
| 3.翻页按钮的每页显示的数据要准确，确保没有查不出来的数据，最好的做法就是和数据库结合起来验证 |
|
| 4.页面太多，翻页数据不能全部显示时，系统应该有完善的应对机制，比如值显示当前页的前三页和该页的后三页的页数码 |
|
| 5.当翻到某页时，系统应该有明显的标识，标出该页面所处的页码 |
|
| 9.错误页面测试(CW) |
|
| 错误页面是在遇到系统异常的情况产生的友好界面 |
1.当系统遇到致命错误时，不能将服务器的调试信息出现在页面上，因为这样做会带来不安全，应该给出一个合适的提示信息 |
| 2.由于系统繁忙，无法及时给出正确信息时，系统可以给出友好的错误页面，如：“请用户稍后再试”等提示信息 |
|
3.4、因果图
3.4.1、概念
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）
3.4.2、因果图涉及的概念
1、因果图的介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
3) C1表示原因，通常置于图的左部；e1表示结果，通常在图的右部。C1和e1均可取值0或1，0表示某状态不出现，1表示某状态出现
2、因果图的关系
- 恒等：若c1是1，则e1也是1；否则e1为0。
- 非：若c1是1，则e1是0；否则e1是1。
- 或：若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入。
- 与：若c1和c2都是1，则e1为1；否则e1为0。“与”也可有任意个输入。
3、因果图的约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
（1）、输入条件的约束有以下4类：
- E约束（互斥）：a和b中至多有一个可能为1，即a和b不能同时为1。
- I约束（包含）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
- O约束（唯一）；a和b必须有一个，且仅有1个为1。
- R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
- M约束（屏蔽）：表示若a是1是，b必须为0，既不可出现a=1且b=1的情况。
（2）、输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
3.4.3、因果图的应用
因果图在软件测试用例设计过程中，用于描述被测对象输入与输入、输入与输出之间的约束关系。因果图的绘制过程，可以理解为用例设计者针对因果关系业务的建 模过程。根据需求规格，绘制因果图，然后得到一个盘点表进行用例设计，通常理解因果图为判定表的前置过程，当被测对象因果关系较为简单时，可以直接使用判 定表设计用例，如若不然可使用因果图与判定表结合的方法设计用例。
3.4.4、因果图测试用例设计方法
1) 分割功能说明书
分析需求规格说明书，将输入条件分成若干组，然后分别对每个组使用因果图，这样可以减少输入条件组合的数目。
2）识别“原因”和“结果”，并加以编号。
“原因”是指输入条件或输入条件的等价类；“结果”是指输出条件或系统变换，如更新主文件就是一种系统变换。
每个原因和结果都对应与因果图中的一个结点，当原因或结果成立（或出现）时，相应的节点的值记为1，否则记为0.
3）根据功能说明中规定的原因和结果之间的关系画出因果图。
因果图的基本符号如下图所示：
图中左边的结点表示原因，右边的结点表示结果。原因和结果之间的关系有恒等、非、或、与，其含义如下。
在画因果图时，原因在左，结果在右，由上向下排列，并根据功能说明中规定的原因和结果之间的关系，用上述符号连接起来，必要时，可在因果图中加入一些中间结点。
4）根据功能说明在因果图中加上约束。
因果图中表示约束条件的符号如下所示：
5）根据因果图画出判定表
列出满足约束条件的所有原因组合，写出各种原因组合下的结果，必要时可在判定表中加上中间点，如下表所示：
| 原因 |
允许的原因组合 |
| 中间结点 |
各种原因组合下中间结点的值 |
| 结果 |
各种原因组合下的结果值 |
6）根据判定表设计测试用例
为上面判定表的每一列设计一个测试用例。
3.4.5、实例
饮料自动售货机允许投入5角和1元的硬币，用户可通过“橙汁”和“啤酒”按钮选择饮料，售货机中无零钱找时提示灯亮。当用户投入5角硬币并押下“橙汁”或“啤酒”按钮后，售货机送出相应的饮料。当用户投入1元硬币并押下“橙汁”或“啤酒”按钮后，如果售货机有零钱找，则送出相应的饮料，并退还5角硬币；如果售货机没有零钱找，则饮料不送出，并且退还1元硬币。
（1）、分析规格说明，列出原因和结果
根据规格说明，反映原因的输入条件有：投入1元硬币，投入5角硬币，押下“橙汁”按钮，押下“啤酒”按钮。反映结果的输出条件有：退还1元硬币，退还5角硬币，送出“橙汁”饮料，送出“啤酒”饮料。由于“售货机有零钱找”是在投入1元硬币时判断是否能找零钱的依据，所以也可把它看作是一个输入条件，即原因。与之对应的结果是售货机指示灯亮（或暗）。
因此，本例的原因和结果如下：
原因：
1——售货机有零钱找
2——投入1元硬币
3——投入5角硬币
4——押下橙汁按钮
5——.押下啤酒按钮
结果：
21——售货机〖零钱找完〗灯亮
22——退还1元硬币
23——退还5角硬币
24——送出橙汁饮料
25——送出啤酒饮料
（2）、所有原因节点列在左边，结果结点列在右边，画出因果图，如下图所示：
其中中间结点的含义如下：
结点11表示投入1元硬币且押下饮料按钮。
结点12表示押下“橙汁”或“啤酒”按钮。
结点13表示应找5角硬币且售货机有零钱找。
结点14表示钱已付清。
（3）、在因果图中加上约束条件
由于原因2和3不能同时发生，原因4和5也不能同时发生，所以需加约束条件E，如上图。
（4）、根据因果图画出判定表
根据因果图画出判定表如下：
其中阴影部分表示不可能出现的原因条件组合，此外当原因2,3,4,5均为0时，表示既没有投硬币也没有押按钮，此时表示售货机处于无人使用状态，因此也不必为他们设计测试用例。
（5）、为判定表的每个有意义的列设计一个测试用例。
3.5、判定表/决策表驱动法
3.5.1、判定表驱动法概念
判定表是黑盒测试的方法之一，判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
3.5.2、判定表的组成
1) 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2) 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3) 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4) 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
5) 规则： 任何一个条件组合的特定取值及其要执行的相应操作。在判定表中贯穿条件项和动作项的一列就是一条规则。
3.5.3、优点缺点
优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
缺点：不能表达重复执行的动作，例如循环结构。
3.5.4、适用条件
B. Beizer 指出了适合使用判定表设计测试用例的条件：
- 规格说明以判定表形式给出,或很容易转换成判定表。
- 条件的排列顺序不会也不影响执行哪些操作。
- 规则的排列顺序不会也不影响执行哪些操作。
- 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
- 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了。
3.5.5、判定表的建立步骤
- 确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有 clip_image006种规则。
- 列出所有的条件桩和动作桩。
- 填入条件项。
- 填入动作项。得到初始判定表。
- 简化判定表（合并相似规则（相同动作））,如下表所示，左侧的两列均可以合并为右侧一列
| 规则 选项 |
1 |
2 |
合并1、2 |
3 |
4 |
合并3、4 |
| 条件1 |
Y |
Y |
Y |
Y |
Y |
Y |
| 条件2 |
Y |
N |
- |
Y |
- |
- |
| 条件3 |
N |
N |
N |
N |
N |
N |
| 动作4 |
√ |
√ |
√ |
√ |
√ |
√ |
3.5.6、判定表建立实例
给出三个任意正数a、b、c判断其能否构成三角形及三角形按边分类的类型
1、 确定规则的个数，先定义条件个数，如下：
三角形按照边分为：等腰三角形、等边三角形、一般三角形
根据分析，确定条件如下：
a
|
|
1~32 |
33~48 |
49~56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
| a |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| b |
- |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| c |
- |
- |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| a=b |
- |
- |
- |
N |
N |
N |
N |
Y |
Y |
Y |
Y |
| b=c |
- |
- |
- |
N |
N |
Y |
Y |
N |
N |
Y |
Y |
| a=c |
- |
- |
- |
N |
Y |
N |
Y |
N |
Y |
N |
Y |
| 一般三角形 |
|
|
|
√ |
|
|
|
|
|
|
|
| 等腰三角形 |
|
|
|
|
√ |
√ |
|
√ |
|
|
|
| 等边三角形 |
|
|
|
|
|
|
|
|
|
|
√ |
| 非三角形 |
√ |
√ |
√ |
|
|
|
|
|
|
|
|
| 不成立 |
|
|
|
|
|
|
√ |
|
√ |
√ |
|
上述判定表已经是合并相同规则后的表格，经过简化后（去除不可能条件）得到最终判定表如下：
|
|
1~32 |
33~48 |
49~56 |
57 |
58 |
59 |
61 |
64 |
| a |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
| b |
- |
N |
Y |
Y |
Y |
Y |
Y |
Y |
| c |
- |
- |
N |
Y |
Y |
Y |
Y |
Y |
| a=b |
- |
- |
- |
N |
N |
N |
Y |
Y |
| b=c |
- |
- |
- |
N |
N |
Y |
N |
Y |
| a=c |
- |
- |
- |
N |
Y |
N |
N |
Y |
| 一般三角形 |
|
|
|
√ |
|
|
|
|
| 等腰三角形 |
|
|
|
|
√ |
√ |
√ |
|
| 等边三角形 |
|
|
|
|
|
|
|
√ |
| 非三角形 |
√ |
√ |
√ |
|
|
|
|
|
| 不成立 |
|
|
|
|
|
|
|
|
根据上述判定表，得到用例如下：
| 用例编号 |
a |
b |
c |
预期结果 |
| T01 |
4 |
1 |
2 |
非三角形 |
| T02 |
1 |
4 |
2 |
非三角形 |
| T03 |
1 |
2 |
4 |
非三角形 |
| T04 |
3 |
4 |
6 |
一般三角形 |
| T05 |
3 |
4 |
3 |
等腰三角形 |
| T06 |
4 |
3 |
3 |
等腰三角形 |
| T07 |
3 |
3 |
4 |
等腰三角形 |
| T08 |
3 |
3 |
3 |
等边三角形 |
3.6、状态迁移法
3.6.1、状态迁移法概念
许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态。可能不可能产生非法的状态转移等。对于被测系统，若我们可以抽象出它的若干个状态，以及这些状态之间的切换条件和切换路径，那么就可以从状态迁移路径覆盖的角度来设计用例对该系统进行测试。状态迁移法的目标是设计足够的用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。
状态迁移法的思想是提供将多个状态的转换串联起来进行测试的思路。该方法适合测试各种状态的转换，而且这些状态转换的测试在实践中是易遗漏的。例如像手机、MP3等，都可以使用状态迁移法对使用状态的迁移（即用户使用场景的转换）进行测试。
3.6.2、使用状态迁移法的条件
被测系统的功能依赖于数据的状态，像常见的工作流系统（OA），对于这类软件状态迁移法就在合适不过了。
1、针对有限状态机的测试方法
2、给一个触发条件
3、常应用于WEb页面转换、自动化测试、通信协议测试等
3.6.3、状态迁移图法设计用例步骤
1、分析需求规格说明书，找出状态和触发条件（分析状态条件之间有哪些关系）
2、画出状态迁移图（设定一个初始状态、初始状态是相对而言的，状态用圆圈表示，条件用带有箭头的线段表示）3、通过状态图画出状态--事件表（四列，上一状态，条件，下一状态，表现的行为动作信息）
4、从状态转换树推导出测试路径
5、根据测试路径编写合法测试用例
6、编写非法测试用例
3.6.4、具体实例
打印机初始处于就绪的状态下，可以接收打印的任务，进入打印状态，开始打印；在打印的过程中，如果打印机出现故障，打印机将处于故障状态，等待修复故障；故障修复后，打印机恢复打印状态，继续打印原来的文档；在打印过程中，如果纸张用完，打印机将暂停打印，处于缺纸状态，当放入印纸后，打印机会自动检测，恢复打印状态，继续开始打印；打印任务完成，打印机恢复就绪状态
步骤：
1、分析需求片段，找出所有状态以及状态之间的跳转条件
状态：就绪，打印，故障，缺纸
跳转条件：打印指令，出现故障，故障修复，缺纸 ，放入纸张，打印完毕
2、设定初始状态，画出状态迁移图。
3、生成状态时间表
| 上一状态 |
跳转条件 |
下一状态 |
表现 |
| 就绪状态 |
打印指令 |
打印状态 |
打印灯亮 |
| 打印状态 |
打印完毕 |
就绪状态 |
就绪灯亮 |
| 打印状态 |
缺纸 |
缺纸状态 |
缺纸灯亮 |
| 打印状态 |
出现故障 |
故障状态 |
故障灯亮 |
| 故障状态 |
故障恢复 |
打印状态 |
打印灯亮 |
| 缺纸状态 |
放入纸张 |
打印状态 |
打印灯亮 |
4、生成状态转换树
5、从状态树推导出测试路径：
就绪---打印---缺纸---打印
就绪---打印---故障---打印
就绪---打印---就绪
6、根据测试路径编写测试用例
7、添加非法的测试用例
比如直接就绪状态----故障状态或者 就绪----缺纸等
3.6.5、总结
状态迁移法实际测试了被测系统各种状态的转换，这些状态转换的测试在实际工作中是容易遗漏的，只要能够将这些状态的转换测试到，是否采用状态迁移法并不重要，因为状态迁移法只是提供了一种将多个状态的转换串联起来进行测试的思路（思维模式）。
实际工作中，在业务流程中都涉及到了复杂的业务场景（即业务状态的迁移）。而这些业务场景在需求规格中往往不能够完全阐述清楚，容易出现遗漏。所以当被测系统的业务场景复杂时，在工程中应用这种针对状态迁移测试的思路完成对复杂业务场景的测试有时是很有必要的。
3.7、正交实验法
3.7.1、正交实验法概念
利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地，合理地减少测试的工时与费用，可利用正交试验设计方法进行测试用例的设计。
研究多因素多水平的一种设计方法。它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
例如，要考察正常值、错误值和边界值对某软件界面的影响。每个因素设置3个水平进行试验。A因素是正常值，设 A 1、A 2 、A 3 3个水平；B因素是错误值，设B1 、B 2 、B 3 3 个水平；C 因素为边界值，设C 1、C 2 、C 3 3个水平。这是一个3 因素 3 水平的试验，各因素的水平之间全部可能组合有27(即3^3)种。
全面试验:可以分析各因素的效应，交互作用，也可选出最优水平组合。但全面试验包含的水平组合数较多，工作量大，在有些情况下无法完成。
若试验的主要目的是寻求最优水平组合 ，则可利用正交表来设计安排试验。正交试验设计的基本特点是:用部分试验来代替全面试验，通过对部分试验结果的分析，了解全面试验的情况。正因为正交试验是用部分试验来代替全面试验的 ，它不可能像全面试验那样对各因素效应、交互作用一一分析；当交互作用存在时，有可能出现交互作用的混杂。虽然正交试验设计有上述不足，但它能通过部分试验找到最优水平组合，因而很受实际工作者青睐。
如对于上述 3 因素 3 水平试验 ，若不考虑交互作用，可利用正交表L9(33) 安排，它表示需作9次实验，最多可观察3个因素，每个因素均为3水平，试验方案仅包含9个水平组合，就能反映试验方案包含27个水平组合的全面试验的情况，找出最佳的生产条件。
这种方法的优点是试验次数少,效果好,方法简单,使用方便，效率高。
3.7.2、正交实验法步骤
(1) 确定因素
这里的因素是指对软件运行结果有影响的软件
(2) 确定因素的取值范围或集合(该步是为步骤3做准备的)
因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源。
(3) 确定每个因素的水平
根据因素的取值范围或集合 ,采用等价类划分、边界值分析以及其他软件测试技术,在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值。
(4) 选择正交表
根据确定的因素和水平 ,选择适合的正交表。
如果没有合适的正交表可用或需要的测试用例个数太多 ,要对因素和水平进行调整。
(5) 测试结果分析
加上你认为可疑且没有在表中出现的组合。
3.7.3、正交表
将正交试验选择的水平组合，列成表格，称为正交表。
正交表的构成：
(1)、行数(Runs)：正交表中的行的个数，即试验的次数，也是通过正交实验法设计的测试用例的个数
(2)、因素数(Factors)：正交表中列的个数，即要测试的功能点。
(3)、水平数(Levels)：任何单个因素能够取得的值的最大个数，即要测试功能点的输入值
(4)、L行数(水平数因素数)，
正交表具有以下两个特点，即正交性。正交表必须满足这两个特点，有一条不满足，就不是正交表。
1）每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。
2）在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中，因此具有很强的代表性。
3.7.4、如何选择正交表
--考虑因素（变量）的个数
--考虑因素水平（变量的取值）的个数
--考虑正交表的行数
--取行数最少的一个
3.7.5、正交表实验法应用实例
例如：淘宝搜索宝贝，条件有宝贝评价（好评、中评、差评），所在地（江、浙、沪），价格范围（100以下，100~199之间，199以上），包邮（包邮、不包邮），假设这个需求是针对富二代的，那么利用正交试验法对此需求进行分析.
步骤：
1、划分需求子片段
2、找出因子和因子状态
因子:
评价
所在地
价格范围
包邮
状态:
好评、中评、差评
江、浙、沪
100以下，100~199之间，199以上
包邮、不包邮
3、构造因子状态表
| 因子/状态 |
评价 |
所在地 |
价格范围 |
包邮 |
| 状态1 |
好评 |
江 |
100以下 |
包邮 |
| 状态2 |
中评 |
浙 |
100~199 |
不包邮 |
| 状态3 |
差评 |
沪 |
199以上 |
|
4、根据因子状态表，进行加权筛选，生成因素分析表
根据分析：
针对评价方面，很少有人搜索差评的，所以差评的取值可以去掉；（删除评价因子中的一个状态）
针对富二代的，所以价格方面考虑的会比较少，所以价格可以去掉；（删除一个因子）
| 因子/状态 |
评价 |
所在地 |
包邮 |
| 状态1 |
好评 |
江 |
包邮 |
| 状态2 |
中评 |
浙 |
不包邮 |
| 状态3 |
|
沪 |
|
5、利用正交表构造测试数据集
各因子的状态数不统一，利用逻辑命令作出布尔图,所在地可以将某两个取值取或的关系，合成一个值。
| 因子/状态 |
评价 |
所在地 |
包邮 |
| 状态1 |
好评 |
江 |
包邮 |
| 状态2 |
中评 |
浙 |
不包邮 |
| 状态3 |
|
沪 |
|
找最接近的阶数相应的正交表，3因子 2状态，根据正交表构造测试数据集
| 因子/状态 |
评价A |
所在地B |
包邮C |
| 状态1 |
好评 A1 |
江或浙 B1 |
包邮 C1 |
| 状态2 |
中评 A2 |
沪 B2 |
不包邮 C2 |
把A、B、C换成对应的数据，B1是江浙两个取值
| Experiment Number |
评价A |
所在地B |
包邮C |
| 1 |
A1 |
B1 |
C1 |
| 2 |
A1 |
B2 |
C2 |
| 3 |
A2 |
B1 |
C2 |
| 4 |
A2 |
B2 |
C1 |
6、利用正交表每行数据构造测试用例。
3.7.6、常用正交表
3.8、场景法
3.8.1、场景法概念
现在的软件几乎都是用事件触发来控制流程的。像GUI软件、游戏等。事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计方面的思想可以引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
在测试一个软件的时候，在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个称为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。所以在进行图示的时候，就会发现每个事件流的颜色是不同的。
基本流就是按照正确的事件流来实现的流程。备选流就是出现故障或缺陷的过程。场景就是若干事件流首尾拼接构成一个测试场景。来看一个场景图：
3.8.2、用例设计步骤
1、根据说明，描述出程序的基本流及各项备选流
2、根据基本流和各项备选流生成不同的场景
3、对每一个场景生成相应的测试用例
4、对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
3.8.3、场景法案例一
我们都在当当网或china-pub华章网上书店都订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。
那么我们通过以上的描述，从中确定哪是基本流，哪些是备选流：
| 基本流 |
用户登录到网站，书籍的选择，进行订购，把所需图书放进购物车，等进行结帐的时候，登录自己的帐号，登录成功后，生成订单 |
| 备选流1 |
帐号不存在 |
| 备选流2 |
帐号错误 |
| 备选流3 |
密码错误 |
| 备选流4 |
无选购书籍 |
| 备选流x |
退出系统 |
根据基本流和备选流来确定场景：
| 场景1-购物成功 |
基本流 |
|
| 场景2-帐号不存在 |
基本流 |
备选流1 |
| 场景3-帐号错误 |
基本流 |
备选流2 |
| 场景4-密码错误 |
基本流 |
备选流3 |
| 场景5-无选购书籍 |
基本流 |
备选流4 |
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
| 测试用例ID |
场景/条件 |
帐号 |
密码 |
选购书籍 |
预期结果 |
| 1 |
场景1：购物成功 |
V |
V |
V |
成功购物 |
| 2 |
场景2：帐号不存在 |
I |
n/a |
n/a |
提示帐号不存在 |
| 3 |
场景3：帐号错误 |
I |
V |
n/a |
提示帐号错误，返回基本流步骤2 |
| 4 |
场景4：密码错误 |
V |
I |
n/a |
提示密码错误，返回基本流步骤3 |
| 5 |
场景5：无选购书籍 |
V |
V |
I |
提示选购书籍，返回基本流步骤5 |
我们看到以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。
| 测试用例ID |
场景/条件 |
帐号 |
密码 |
选购书籍 |
预期结果 |
| 1 |
场景1：购物成功 |
xu |
123456 |
《书》 |
成功购物 |
| 2 |
场景2：帐号不存在 |
zhang |
n/a |
n/a |
提示帐号不存在 |
| 3 |
场景3：帐号错误 |
zhou |
123456 |
n/a |
提示帐号错误，返回基本流步骤2 |
| 4 |
场景4：密码错误 |
xu |
123$%^ |
n/a |
提示密码错误，返回基本流步骤3 |
| 5 |
场景5：无选购书籍 |
xu |
123456 |
空 |
提示选购书籍，返回基本流步骤5 |
3.8.4、场景法案例二
例子：分析ATM取款机的场景流程，并设计测试用例和测试数据
| 基本流 |
插入磁卡，ATM验证账户正确，输入密码正确，通过验证，输入取款金额，取出金额，取卡 |
| 备选流1 |
账户不存在或者受限制 |
| 备选流2 |
密码不正确，还有输入机会 |
| 备选流3 |
密码不正确，没有输入机会 |
| 备选流4 |
卡中余额不足 |
| 备选流5 |
ATM机中余额不足 |
| 备选流6 |
超过每日最大提款限额 |
| 备选流7 |
输入金额非100的倍数 |
根据基本流和备选流来确定场景：
