黑盒测试法也称功能测试或数据驱动测试,它是在已知产品所应具备的功能,经过测试来检测每一个功能是否都能正常使用,在测试时,把程序看做一个不能打开的黑盒子,在彻底不考虑程序内部结构和内部特性的状况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,而且保持外部信息(如数据库或文件)的完整性。面试
黑盒测试主要发现如下类型的错误:数据库
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把全部可能的输入都做为测试状况使用,才能以这种方法查出程序中全部的错误。实际上测试状况有无穷多个,人们不只要测试全部合法的输入,并且还要对那些不合法可是可能的输入进行测试。编程
黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序全部功能需求的输入条件。黑盒测试并非白盒测试的替代品,而是用于辅助白盒测试发现其余类型的错误。数组
整体来讲,黑盒测试有如下特色:安全
等价类划分法是把程序的输入域划分红若干部分(子集),而后从每一个部分中选取少数表明性数据做为测试用例。每一类的表明性数据在测试中的做用等价于这一类中的其余值。服务器
等价类划分法将程序全部可能的输入数据(有效的和无效的)划分红若干个等价类。而后从每一个部分中选取具备表明性的数据当作测试用例进行合理的分类,测试用例由有效等价类和无效等价类的表明组成,从而保证测试用例具备完整性和表明性。利用这一方法设计测试用例能够不考虑程序的内部结构,以需求规格说明书为依据,选择适当的典型子集,认真分析和推敲说明书的各项需求,特别是功能需求,尽量多地发现错误。等价类划分法是一种系统性的肯定要输入的测试条件的方法。
因为等价类是在需求规格说明书的基础上进行划分的,而且等价类划分不只能够用来肯定测试用例中的数据的输入输出的精确取值范围,也能够用来准备中间值、状态和与时间相关的数据以及接口参数等,因此等价类能够用在系统测试、集成测试和组件测试中,在有明确的条件和限制的状况下,利用等价类划分技术能够设计出完备的测试用例。网络
有效等价类指对于程序规格说明来讲,是合理的、有意义的输入数据构成的集合。利用有效等价类能够检验程序是否实现了规格说明预先规定的功能和性能。有效等价类能够是一个,也能够是多个,根据系统的输入域划分若干部分,而后从每一个部分中选取少数有表明性数据当作数据测试的测试用例,等价类是输入域的集合。数据结构
无效等价类和有效等价类相反,无效等价类是指对于软件规格说明而言,没有意义的、不合理的输入数据集合。利用无效等价类,能够找出程序异常说明状况,检查程序的功能和性能的实现是否有不符合规格说明要求的地方。编程语言
按区间划分:在输入条件规定的取值范围或值的个数的状况下,能够肯定一个有效等价类和两个无效等价类。
按数值划分:在规定了输入数据的一组值中(假定有n个值),而且程序要对每一个输入值分别处理的状况下,能够肯定n个有效等价类和一个无效等价类。
按数值集合划分:在规定输入数据必须遵照的规则的状况下,能够肯定一个有效等价类和若干个无效等价类。
按限制条件或规划划分:在输入条件规定了输入值的集合或规定了“必须如何”的条件下,能够肯定一个有效等价类和一个无效等价类。
按处理方式划分:在肯定已划分的等价类中各元素在程序处理中的方式不一样的状况下,则应将该等价类进一步地划分为更小的等价类。性能
一、依据经常使用的原则划分等价类
二、为每个等价类规定惟一的编号
三、设计一个新的测试用例,使其尽量多的覆盖还没有被覆盖的有效等价类,重复这一步,直到全部有效等价类都被覆盖为止。
四、设计一个新的测试用例,使其覆盖一个还没有被覆盖的无效等价类,重复这一步,直到全部的无效等类都被覆盖为止。
假设要输入一个日期,日期限定在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 | 无效输入 | ⑩ |
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。一般边界值分析法是做为对等价类划分法的补充,这种状况下,其测试用例来自等价类的边界。
根据大量的测试统计数据,不少错误是发生在输入或输出范围的边界上,而不是发生在输入/输出范围的中间区域。所以针对各类边界状况设计测试用例,能够查出更多的错误。
使用边界值分析方法设计测试用例,首先应肯定边界状况。一般输入和输出等价类的边界,就是应着重测试的边界状况。应当选取正好等于,刚刚大于或刚刚小于边界的值做为测试数据,而不是选取等价类中的典型值或任意值做为测试数据。
边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,所以在等价类的边界上以及两侧的状况设计测试用例。
边界值分析法与等价类分析法的区别:
一、边界值分析不是从某等价类中随便挑一个做为表明,而是使这个等价类的每一个边界都要做为测试条件。
二、边界值分析不只考虑输入条件,还要考虑输出空间产生的测试状况。入条件,还要考虑输出空间产生的测试状况。
一般状况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等状况下。利用边界值做为测试数据.
项 |
边界值 |
测试用例的设计思路 |
字符 |
起始-1个字符/结束+1个字符 |
假设一个文本输入区域容许输入1个到255个 字符,输入1个和255个字符做为有效等价类;输入0个和256个字符做为无效等价类,这几个数值都属于边界条件值。 |
数值 |
最小值-1/最大值+1 |
假设某软件的数据输入域要求输入5位的数据值,可使用10000做为最小值、99999做为最大值;而后使用恰好小于5位和大于5位的 数值来做为边界条件。 |
空间 |
小于空余空间一点/大于满空间一点 |
例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件做为边界条件。 |
在多数状况下,边界值条件是基于应用程序的功能设计而须要考虑的因素,能够从软件的规格说明或常识中获得,也是最终用户能够很容易发现问题的。然而,在测试用例设计过程当中,某些边界值条件是不须要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种:
一、数值的边界值检验:计算机是基于二进制进行工做的,所以,软件的任何数值运算都有必定的范围限制。
项 |
范围或值 |
位(bit) |
0 或 1 |
字节(byte) |
0 ~ 255 |
字(word) |
0~65535(单字)或 0~4294967295(双字) |
千(K) |
1024 |
兆(M) |
1048576 |
吉(G) |
1073741824 |
二、字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。以下列出了一些经常使用字符对应的ASCII码值。
字符 |
ASCII码值 |
空 (null) |
0 |
空格 (space) |
32 |
可输入的字符 |
33~126 |
0~9 |
48~57 |
A~Z |
65~90 |
a~z |
97~122 |
三、其它边界值检验:在不一样的行业应用领域,依据硬件和软件的标准不一样而具备各自特定的边界值。以下列出部分手机相关的边界值:
硬件设备 |
范围或值 |
手机锂电池电压 |
工做电压:3.6~4.2V; 保护电压:2.5~3V不等 |
手机正常使用温度 |
-25°C~+60°C |
一、若是输入条件规定了值的范围,则应取刚达到这个范围的边界值,以及刚刚超越这个范围边界的值做为测试输入数据。
二、若是输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少1,比最大个数多1的数做为测试数据。
三、根据规格中每一个输出条件,使用原则1,若是输出条件规定了值的范围,则应取刚达到这个范围的边界值,以及刚刚超越这个范围边界的值做为测试输入数据。
四、根据规格中每一个输出条件,使用原则2,若是输出条件规定了值的个数,则用最大个数、最小个数,比最小个数少1,比最大个数多1的数做为测试数据。
五、若是程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值做为测试用例。
六、分析规格说明,找出其余可能的边界条件。
错误推测法是指:在测试程序时,人们能够根据经验或直觉推测程序中可能存在的各类错误,从而有针对性地编写检查这些错误的测试用例的方法。
错误推测方法的基本思想: 列举出程序中全部可能有的错误和容易发生错误的特殊状况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 之前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的状况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的状况。可选择这些状况下的例子做为测试用例.
总之,就是进行错误的操做。
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卡,呼出无效号码(如一、88八、33333三、不输入任何号码等)
5) 网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字
功能测试用例库 |
|
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.因为系统繁忙,没法及时给出正确信息时,系统能够给出友好的错误页面,如:“请用户稍后再试”等提示信息 |
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各类组合、输入条件之间的相互制约关系。这样虽然各类输入条件可能出错的状况已经测试到了,但多个输入条件组合起来可能出错的状况却被忽视了。
若是在测试时必须考虑输入条件的各类组合,则可能的组合数目将是天文数字,所以必须考虑采用一种适合于描述多种条件的组合、相应产生多个动做的形式来进行测试用例的设计,这就须要利用因果图(逻辑模型)
一、因果图的介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称缘由),右结点表示输出状态(或称结果)。
3) C1表示缘由,一般置于图的左部;e1表示结果,一般在图的右部。C1和e1都可取值0或1,0表示某状态不出现,1表示某状态出现
二、因果图的关系
三、因果图的约束
输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件自己不可能同时出现。输出状态之间也每每存在约束。在因果图中,用特定的符号标明这些约束。
(1)、输入条件的约束有如下4类:
(2)、输出条件约束类型
输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。
因果图在软件测试用例设计过程当中,用于描述被测对象输入与输入、输入与输出之间的约束关系。因果图的绘制过程,能够理解为用例设计者针对因果关系业务的建 模过程。根据需求规格,绘制因果图,而后获得一个盘点表进行用例设计,一般理解因果图为断定表的前置过程,当被测对象因果关系较为简单时,能够直接使用判 定表设计用例,如若否则可以使用因果图与断定表结合的方法设计用例。
1) 分割功能说明书
分析需求规格说明书,将输入条件分红若干组,而后分别对每一个组使用因果图,这样能够减小输入条件组合的数目。
2)识别“缘由”和“结果”,并加以编号。
“缘由”是指输入条件或输入条件的等价类;“结果”是指输出条件或系统变换,如更新主文件就是一种系统变换。
每一个缘由和结果都对应与因果图中的一个结点,当缘由或结果成立(或出现)时,相应的节点的值记为1,不然记为0.
3)根据功能说明中规定的缘由和结果之间的关系画出因果图。
因果图的基本符号以下图所示:
图中左边的结点表示缘由,右边的结点表示结果。缘由和结果之间的关系有恒等、非、或、与,其含义以下。
在画因果图时,缘由在左,结果在右,由上向下排列,并根据功能说明中规定的缘由和结果之间的关系,用上述符号链接起来,必要时,可在因果图中加入一些中间结点。
4)根据功能说明在因果图中加上约束。
因果图中表示约束条件的符号以下所示:
5)根据因果图画出断定表
列出知足约束条件的全部缘由组合,写出各类缘由组合下的结果,必要时可在断定表中加上中间点,以下表所示:
缘由 |
容许的缘由组合 |
中间结点 |
各类缘由组合下中间结点的值 |
结果 |
各类缘由组合下的结果值 |
6)根据断定表设计测试用例
为上面断定表的每一列设计一个测试用例。
饮料自动售货机容许投入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)、为断定表的每一个有意义的列设计一个测试用例。
断定表是黑盒测试的方法之一,断定表是把做为条件的全部输入的各类组合值以及对应输出值都罗列出来而造成的表格。它可以将复杂的问题按照各类可能的状况所有列举出来,简明并避免遗漏。
所以,利用断定表可以设计出完整的测试用例集合。在一些数据处理问题当中,某些操做的实施依赖于多个逻辑条件的组合,即:针对不一样逻辑条件的组合值,分别执行不一样的操做。断定表很适合于处理这类问题。
1) 条件桩(Condition Stub):列出了问题得全部条件。一般认为列出的条件的次序可有可无。
2) 动做桩(Action Stub):列出了问题规定可能采起的操做。这些操做的排列顺序没有约束。
3) 条件项(Condition Entry):列出针对它左列条件的取值。在全部可能状况下的真假值。
4) 动做项(Action Entry):列出在条件项的各类取值状况下应该采起的动做。
5) 规则: 任何一个条件组合的特定取值及其要执行的相应操做。在断定表中贯穿条件项和动做项的一列就是一条规则。
优势:它能把复杂的问题按各类可能的状况一一列举出来,简明而易于理解,也可避免遗漏。
缺点:不能表达重复执行的动做,例如循环结构。
B. Beizer 指出了适合使用断定表设计测试用例的条件:
B. Beizer提出这5个必要条件的目的是为了使操做的执行彻底依赖于条件的组合。其实对于某些不知足这几条的断定表,一样能够借以设计测试用例,只不过尚需增长其它的测试用例罢了。
规则 选项 |
1 |
2 |
合并一、2 |
3 |
4 |
合并三、4 |
条件1 |
Y |
Y |
Y |
Y |
Y |
Y |
条件2 |
Y |
N |
- |
Y |
- |
- |
条件3 |
N |
N |
N |
N |
N |
N |
动做4 |
√ |
√ |
√ |
√ |
√ |
√ |
给出三个任意正数a、b、c判断其可否构成三角形及三角形按边分类的类型
一、 肯定规则的个数,先定义条件个数,以下:
三角形按照边分为:等腰三角形、等边三角形、通常三角形
根据分析,肯定条件以下:
a<b+c、b<a+c、c<a+b、a=b、b=c、c=a,故规则的个数有2的6次方64个
二、初始断定表
|
1~32 |
33~48 |
49~56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 |
a<b+c |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
b<a+c |
- |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
c<a+b |
- |
- |
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<b+c |
N |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
b<a+c |
- |
N |
Y |
Y |
Y |
Y |
Y |
Y |
c<a+b |
- |
- |
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 |
等边三角形 |
许多需求用状态机的方式来描述,状态机的测试主要关注在测试状态转移的正确性上面。对于一个有限状态机,经过测试验证其在给定的条件内是否可以产生须要的状态变化,有没有不可达的状态和非法的状态。可能不可能产生非法的状态转移等。对于被测系统,若咱们能够抽象出它的若干个状态,以及这些状态之间的切换条件和切换路径,那么就能够从状态迁移路径覆盖的角度来设计用例对该系统进行测试。状态迁移法的目标是设计足够的用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。
状态迁移法的思想是提供将多个状态的转换串联起来进行测试的思路。该方法适合测试各类状态的转换,并且这些状态转换的测试在实践中是易遗漏的。例如像手机、MP3等,均可以使用状态迁移法对使用状态的迁移(即用户使用场景的转换)进行测试。
被测系统的功能依赖于数据的状态,像常见的工做流系统(OA),对于这类软件状态迁移法就在合适不过了。
一、针对有限状态机的测试方法
二、给一个触发条件
三、常应用于WEb页面转换、自动化测试、通讯协议测试等
一、分析需求规格说明书,找出状态和触发条件(分析状态条件之间有哪些关系)
二、画出状态迁移图(设定一个初始状态、初始状态是相对而言的,状态用圆圈表示,条件用带有箭头的线段表示)三、经过状态图画出状态--事件表(四列,上一状态,条件,下一状态,表现的行为动做信息)
四、从状态转换树推导出测试路径
五、根据测试路径编写合法测试用例
六、编写非法测试用例
打印机初始处于就绪的状态下,能够接收打印的任务,进入打印状态,开始打印;在打印的过程当中,若是打印机出现故障,打印机将处于故障状态,等待修复故障;故障修复后,打印机恢复打印状态,继续打印原来的文档;在打印过程当中,若是纸张用完,打印机将暂停打印,处于缺纸状态,当放入印纸后,打印机会自动检测,恢复打印状态,继续开始打印;打印任务完成,打印机恢复就绪状态
步骤:
一、分析需求片断,找出全部状态以及状态之间的跳转条件
状态:就绪,打印,故障,缺纸
跳转条件:打印指令,出现故障,故障修复,缺纸 ,放入纸张,打印完毕
二、设定初始状态,画出状态迁移图。
三、生成状态时间表
上一状态 |
跳转条件 |
下一状态 |
表现 |
就绪状态 |
打印指令 |
打印状态 |
打印灯亮 |
打印状态 |
打印完毕 |
就绪状态 |
就绪灯亮 |
打印状态 |
缺纸 |
缺纸状态 |
缺纸灯亮 |
打印状态 |
出现故障 |
故障状态 |
故障灯亮 |
故障状态 |
故障恢复 |
打印状态 |
打印灯亮 |
缺纸状态 |
放入纸张 |
打印状态 |
打印灯亮 |
四、生成状态转换树
五、从状态树推导出测试路径:
就绪---打印---缺纸---打印
就绪---打印---故障---打印
就绪---打印---就绪
六、根据测试路径编写测试用例
七、添加非法的测试用例
好比直接就绪状态----故障状态或者 就绪----缺纸等
状态迁移法实际测试了被测系统各类状态的转换,这些状态转换的测试在实际工做中是容易遗漏的,只要可以将这些状态的转换测试到,是否采用状态迁移法并不重要,由于状态迁移法只是提供了一种将多个状态的转换串联起来进行测试的思路(思惟模式)。
实际工做中,在业务流程中都涉及到了复杂的业务场景(即业务状态的迁移)。而这些业务场景在需求规格中每每不可以彻底阐述清楚,容易出现遗漏。因此当被测系统的业务场景复杂时,在工程中应用这种针对状态迁移测试的思路完成对复杂业务场景的测试有时是颇有必要的。
利用因果图来设计测试用例时,做为输入条件的缘由与输出结果之间的因果关系,有时很难从软件需求规格说明中获得每每因果关系很是庞大,以致于据此因果图而获得的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减小测试的工时与费用,可利用正交试验设计方法进行测试用例的设计。
研究多因素多水平的一种设计方法。它是根据正交性从全面试验中挑选出部分有表明性的点进行试验,这些有表明性的点具有了“均匀分散,齐整可比”的特色,正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法,它是根据正交性,由试验因素的所有水平组合中挑选出部分有表明性的点进行试验,经过对这部分试验结果的分析了解全面试验的状况,找出最优的水平组合。
例如,要考察正常值、错误值和边界值对某软件界面的影响。每一个因素设置3个水平进行试验。A因素是正常值,设 A 一、A 2 、A 3 3个水平;B因素是错误值,设B1 、B 2 、B 3 3 个水平;C 因素为边界值,设C 一、C 2 、C 3 3个水平。这是一个3 因素 3 水平的试验,各因素的水平之间所有可能组合有27(即3^3)种。
全面试验:能够分析各因素的效应,交互做用,也可选出最优水平组合。但全面试验包含的水平组合数较多,工做量大,在有些状况下没法完成。
若试验的主要目的是寻求最优水平组合 ,则可利用正交表来设计安排试验。正交试验设计的基本特色是:用部分试验来代替全面试验,经过对部分试验结果的分析,了解全面试验的状况。正由于正交试验是用部分试验来代替全面试验的 ,它不可能像全面试验那样对各因素效应、交互做用一一分析;当交互做用存在时,有可能出现交互做用的混杂。虽然正交试验设计有上述不足,但它能经过部分试验找到最优水平组合,于是很受实际工做者青睐。
如对于上述 3 因素 3 水平试验 ,若不考虑交互做用,可利用正交表L9(33) 安排,它表示需做9次实验,最多可观察3个因素,每一个因素均为3水平,试验方案仅包含9个水平组合,就能反映试验方案包含27个水平组合的全面试验的状况,找出最佳的生产条件。
这种方法的优势是试验次数少,效果好,方法简单,使用方便,效率高。
(1) 肯定因素
这里的因素是指对软件运行结果有影响的软件
(2) 肯定因素的取值范围或集合(该步是为步骤3作准备的)
因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源。
(3) 肯定每一个因素的水平
根据因素的取值范围或集合 ,采用等价类划分、边界值分析以及其余软件测试技术,在每一个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有表明性的测试值。
(4) 选择正交表
根据肯定的因素和水平 ,选择适合的正交表。
若是没有合适的正交表可用或须要的测试用例个数太多 ,要对因素和水平进行调整。
(5) 测试结果分析
加上你认为可疑且没有在表中出现的组合。
将正交试验选择的水平组合,列成表格,称为正交表。
正交表的构成:
(1)、行数(Runs):正交表中的行的个数,即试验的次数,也是经过正交实验法设计的测试用例的个数
(2)、因素数(Factors):正交表中列的个数,即要测试的功能点。
(3)、水平数(Levels):任何单个因素可以取得的值的最大个数,即要测试功能点的输入值
(4)、L行数(水平数因素数),
正交表具备如下两个特色,即正交性。正交表必须知足这两个特色,有一条不知足,就不是正交表。
1)每列中不一样数字出现的次数相等。这一特色代表每一个因素的每一个水平与其它因素的每一个水平参与试验的概率是彻底相同的,从而保证了在各个水平中最大限度地排除了其它因素水平的干扰,能有效地比较试验结果并找出最优的试验条件。
2)在任意2列其横向组成的数字对中,每种数字对出现的次数相等。这个特色保证了试验点均匀地分散在因素与水平的彻底组合之中,所以具备很强的表明性。
--考虑因素(变量)的个数
--考虑因素水平(变量的取值)的个数
--考虑正交表的行数
--取行数最少的一个
例如:淘宝搜索宝贝,条件有宝贝评价(好评、中评、差评),所在地(江、浙、沪),价格范围(100如下,100~199之间,199以上),包邮(包邮、不包邮),假设这个需求是针对富二代的,那么利用正交试验法对此需求进行分析.
步骤:
一、划分需求子片断
二、找出因子和因子状态
因子:
评价
所在地
价格范围
包邮
状态:
好评、中评、差评
江、浙、沪
100如下,100~199之间,199以上
包邮、不包邮
三、构造因子状态表
因子/状态 |
评价 |
所在地 |
价格范围 |
包邮 |
状态1 |
好评 |
江 |
100如下 |
包邮 |
状态2 |
中评 |
浙 |
100~199 |
不包邮 |
状态3 |
差评 |
沪 |
199以上 |
|
四、根据因子状态表,进行加权筛选,生成因素分析表
根据分析:
针对评价方面,不多有人搜索差评的,因此差评的取值能够去掉;(删除评价因子中的一个状态)
针对富二代的,因此价格方面考虑的会比较少,因此价格能够去掉;(删除一个因子)
因子/状态 |
评价 |
所在地 |
包邮 |
状态1 |
好评 |
江 |
包邮 |
状态2 |
中评 |
浙 |
不包邮 |
状态3 |
|
沪 |
|
五、利用正交表构造测试数据集
各因子的状态数不统一,利用逻辑命令做出布尔图,所在地能够将某两个取值取或的关系,合成一个值。
因子/状态 |
评价 |
所在地 |
包邮 |
状态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 |
六、利用正交表每行数据构造测试用例。
如今的软件几乎都是用事件触发来控制流程的。像GUI软件、游戏等。事件触发时的情景造成了场景,而同一事件不一样的触发顺序和处理结果就造成了事件流。这种在软件设计方面的思想能够引入到软件测试中,能够生动地描绘出事件触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行。
在测试一个软件的时候,在场景法中,测试流程是软件功能按照正确的事件流实现的一条正确流程,那么咱们把这个称为该软件的基本流;而凡是出现故障或缺陷的过程,就用备选流加以标注,这样的话,备选流就能够是从基本流来的,或是由备选流中引出的。因此在进行图示的时候,就会发现每一个事件流的颜色是不一样的。
基本流就是按照正确的事件流来实现的流程。备选流就是出现故障或缺陷的过程。场景就是若干事件流首尾拼接构成一个测试场景。来看一个场景图:
一、根听说明,描述出程序的基本流及各项备选流
二、根据基本流和各项备选流生成不一样的场景
三、对每个场景生成相应的测试用例
四、对生成的全部测试用例从新复审,去掉多余的测试用例,测试用例肯定后,对每个测试用例肯定测试数据值
咱们都在当当网或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 |
例子:分析ATM取款机的场景流程,并设计测试用例和测试数据
基本流 |
插入磁卡,ATM验证帐户正确,输入密码正确,经过验证,输入取款金额,取出金额,取卡 |
备选流1 |
帐户不存在或者受限制 |
备选流2 |
密码不正确,还有输入机会 |
备选流3 |
密码不正确,没有输入机会 |
备选流4 |
卡中余额不足 |
备选流5 |
ATM机中余额不足 |
备选流6 |
超过每日最大提款限额 |
备选流7 |
输入金额非100的倍数 |
根据基本流和备选流来肯定场景: