测试有例设计方法有:1. 等价类划分;2. 边界值分析法;3.错误推测法;4. 因果图方法;5. 正交试验设计法;6. 判定表法。其中,等价类是指某个输入域的子集合,在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。
一、测试有例设计方法
1. 等价类划分
等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
举例:我们要测试一个用户名是否合法,用户名的定义为:8位数字组成的字符。我们可以先划分子集:空用户名,1-7位数字,8位数字,9位或以上数字,非数字。然后从每个子集选出若干个有代表性的值。
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
举例:假定 X 为整数,10≤X≤100,那么 X 在测试中应该取的边界值为:10,11,99,100。
3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如,在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等,,这些就是经验的总结。还有,输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
举例:错误推测法没有固定的形式,依靠的是经验和直觉,很多时候,我们都会不知不觉的使用到。
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等-考虑输入条件之间的相互组合,可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例-这就需要利用因果图(逻辑模型)-因果图方法最终生成的就是判定表-它适合于检查程序输入条件的各种组合情况。
举例:某软件规格说明书包含这样的要求:名列前茅列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果名列前茅列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。
5. 正交试验设计法
有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
举例:某所大学通信系共2个班级,刚考完某一门课程,想通过“性别”、“班级”和“成绩”这三个查询条件对通信系这门课程的成绩分布,男女比例或班级比例进行人员查询。按照传统的方式,我们将会穷举所有的组合,来编写测试用例,组合个数是2*2*2=8。当组合条件不多的时候,穷举暂时没问题,但是,一旦条件多了,组合个数就会以指数形式增长。这个时候,就要用到正交表了,通过选出有代表性的测试实例,达到以少数代替全面的效果。
6. 判定表法
判定表法又称为策略表,基于策略表的测试,是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,会得到一个判断清晰的策略表。
举例:某公司的对客户分类标准如下:顾客每次订货额在 1000元以上(含1000元),信誉好的,订单设“优先”标志;信誉不好,但是老客户的,订单设“优先”标志;信誉不好,但是新客户的,订单设“正常”标志;每次订货额在 1000元以下,订单设“正常”标志。因为穷举了所有条件,所以可以说这个判断是100%正确的。下一步是对这个表进行合并优化。例如,从编号为1,2的列可以看出,顾客订单>=1000,信誉好,不管是新顾客还是老顾客,都设为优先,这样一来,我们就可以得到更清晰的逻辑判断,也可以更好的协助我们编写测试用例。而决策表,对于开发人员来说一样有用。
延伸阅读:
二、测试用例应注意的问题
测试环境搭建之后,根据定义的测试用例执行顺序,逐个执行测试用例。在测试执行中需要注意以下几个问题:
1.全方位的观察测试用例执行结果:
测试执行过程中,当测试的实际输出结果与测试用例中的预期输出结果一致的时候,是否可以认为测试用例执行成功了?答案是否定的,即便实际测试结果与测试的预期结果一致,也要查看软件产品的操作日志、系统运行日志和系统资源使用情况,来判断测试用例是否执行成功了。
2.加强测试过程记录:
测试执行过程中,一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异,一定要记录下来,作为日后更新测试用例的依据;如果软件产品提供了日志功能,比如有软件运行日志、用户操作日志,一定在每个测试用例执行后记录相关的日志文件,作为测试过程记录,一旦日后发现问题,开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境,为开发人员重现问题。
3.及时确认发现的问题:
测试执行过程中,如果确认发现了软件的缺陷,那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题,又无法定位是否为软件缺陷,那么一定要保留现场,然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷,测试人员给予配合;如果开发人员定位问题需要花费很长的时间,测试人员千万不要因此耽误自己宝贵的测试执行时间,可以让开发人员记录重现问题的测试环境配置,然后,回到自己的开发环境上重现问题,继续定位问题。
4.与开发人员良好的沟通:
测试执行过程中,当你提交了问题报告单,可能被开发人员无情驳回,拒绝修改。这时候,只能对开发人员晓之以理,做到有理、有据,有说服力。首先,要定义软件缺陷的标准原则,这个原则应该是开发人员和测试人员都认可的,如果没有共同认可的原则,那么开发人员与测试人员对问题的争执就不可避免了。此外,测试人员打算说服开发人员之前,考虑是否能够先说服自己,在保证可以说服自己的前提下,再开始与开发人员交流。
以上就是关于测试用例的有关内容希望对你有帮助。