测试用例是每个测试从业者的必修课,下面可能讲的不正确,如有不对请谅解!
首先
问一个问题,你的测试用例你自己会回归吗?
第二个问题,你的测试用例别人会感兴趣吗,会使用吗?
第三个问题,你的用例可以复用吗?
自己从业经验来讲,我曾经负责一个ERP项目,项目执行路径比较多,数据也要求比较丰富,oracle、mysql、sqlServer,常用的库都会涉及到,写了近400多个用例,输入、步骤、输出。每一个写的都尽量完全,当我完成后打开那个用例给领导汇报的时候,我对自己的毅力也是惊叹。项目开发模型基本是螺旋模型,设计迭代目标、开发、测试、验收发版、上市。产品是需要长期维护的,下一个迭代会在上一个迭代的基础上继续开发。开发可能不需要继续关注上一迭代开发的功能,而测试是整个产品的质量保证官,代码耦合如果比较强,可能开发同事的一个出乎意料的更改会影响前面已经完善的功能。产品如果要是保持稳定,在整个开发周期,甚至到上市后工作仍然不会结束。
那么现在来答下一个迭代上一个迭代写的那么多用例你会回归吗?不能说100%,90%同学不会回归,甚至不会看那时候辛辛苦苦写下的用例。
回答第二个问题,你的用例别人感兴趣吗?答案我想也是否定的。用例一般来说都是输入输出的集合体,几乎没有人会去查看别人的用例,你要分享讲解可能会有人感兴趣。
回答第三个问题,你的用例可以复用吗?你的用例搬到其他项目可以起到指导作用吗?因为繁琐,所以基本无望。
那么结果是不是,既然没人看,没人用就不用在写用例了?答案是否定的。不仅要设计还要用心设计。下面我讲自己的经验可能不正确,有指导欢迎评论。
测试模型:y=f(x);y应该包括y1,y2,....yn,x1,x2...等也是对应的。
我们的黑盒功能测试,大多如此。输入x可以是文本、可以是一次点击、或是键盘的命令,对应着每一次的事件触发,服务请求。输出y可以是一个提示信息,页面跳转等。而我们的主要工作就是确认x这个集合盒多个x集合的链接动作的合计。不用计算也会发现这是没有办法穷举的。及时是一个简单的产品路径和输入也会千千万。
确定测试模型下面我们看怎么设计测试用例:我们常听到的设计用例的方式有等价类划分、边界值分析法、因果图法、判定表驱动分析法。
1、等价类划分法
定义:
等价类划分:把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。
等价类划分:有效等价类(合法)和无效等价类(非法)。
从标红的语句可以看出,重点有两个① 定位为输入域 ② 把输入域分为若干子集 ③挑出代表性数据
所以当我们用等价类划分法设计用例时 分为三步:
实例:假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。
1.划分等价类并编号,下表等价类划分的结果
输入等价类 | 有效等价类 | 无效等价类 |
日期的类型及长度 | ①6位数字字符 | ②有非数字字符 ③少于6位数字字符 ④多于6位数字字符 |
年份范围 | ⑤在1990~2049之间 | ⑥小于1990 ⑦大于2049 |
月份范围 | ⑧在01~12之间 | ⑨等于00 ⑩大于12 |
2.设计测试数据覆盖上面的标号
200211 输入有效 ①、⑤、⑧
测试数据 期望结果 覆盖的无效等价类
95June 无效输入 ②
20036 无效输入 ③
2001006 无效输入 ④
198912 无效输入 ⑥
200401 无效输入 ⑦
200100 无效输入 ⑨
200113 无效输入 ⑩
总结:等价类划分方法要求:第一步对输入域划分为有效和无效,针对每个单项再分类写出有效用例和无效用例的范围
第二步:分别在有效和无效用等价类中挑选代表整体的用例
在我们漫长的测试中我们会发现很多时候我们挑选不出最具代表性的等价类,这就需要我们积累了,对web测试和移动这种控件类型开发的测试,对每一种控件的输入要记录类似于特殊符号等代表性的字符,加入我们用例库,这样用例就有了复用的可能。
2、边界值分析
边界值分析:输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
有了等价划分后,边界值主要是根据等价类划分的边界代入模型,测试输入和输出的边界值会不会产生异常。
常用的例如:
1.字符长度:直接输入长度等于规定程度的最大值和最小值,字符和汉字的组合,包括直接复制超过长度的内容到输入框等的快捷键测试
2.整数的最大值和最小值,以及输出的运算得到超过整数的最大值
3.屏幕的边界值,浏览器的边界值
4.涉及到存储而且是存储到内容到数据库的 要测试大文本、图片、文件
5.任何控件都要测试空内容
6.白盒测试的第0次 1次 最后一次循环
有了边界值和等价类划分 基本已经足够覆盖我们的大多数控件。
3、因果图法
推荐思维导图软件xmind或者在线的prosess on也是可以的,帮助我们记录和分析结果。利用图表只管的表达出结果验证。
本地电脑没有写好的图,就不贴图了,和流程图差不多。
只讲一下用登录来讲:
根:root,登录(表面这个用例是用例做什么的)
第二层:用户名存在、密码错误,用户名不存在、密码存在,用户名存在、密码正确,用户名存在、密码存在
第三层:结果标识
注意:1、每一层都是一种明确的组合不要组合;2、如果测试边界值等非法操作等最好新建立一个分支;3、尽量不要超过5层
4、保存文件时按照模块或者用例保存,名称填写清晰.
4、判断表方法
是复制条件逻辑组合的利器,方便我们明确的标识出,多个条件的输入的逻辑【与】或者【或】的标识。
理论点讲:
1)条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
相信大家都用过京东或者其他收购二手物品网站的估价器,一步步选择有无磕碰、使用时间,能否开机等选项,最后得出结果,这就是一张判定表。简单说就是多个输入,对应一个输出的结果(当然结果可以有多种)。和y1...yn=f(x1,x2,x3..xn);也是完全匹配的。
回到开头提到的三个问题:
1、你的测试用例你自己会回归吗?
我们的测试用例我们不可能,也不会在每个阶段完全回归。所以对于用例我们要分类,做出计划,每个阶段要回归的用例:
分回归阶段:单元测试、集成测试、验收。
分功能:1、控件类型的用例 2、流程用例
分类划分每个阶段需要回归的用例,每轮回归后要做出应有的标识,经常出问题的逻辑复杂的点要定期回归。不用,
2、你的测试用例别人会感兴趣吗,会使用吗?
长篇大论 基本不会对你的用例感兴趣,但是如果分享主要分享的是判定表类和因果图的用例,这种对思维完善和引导作用的对于别人的工作量还是很有益处的,还有一些专项如弱网、弱电等的测试,可以作为测试项用例分享。
3、你的用例可以复用吗?
前面我讲过第一个问题,要分控件类,这类的用例是最有复用价值的,每个项目都会用到。专项测试用例也可以复用模板,这点和开发者的接口、父类差不多,有模板,再契合自己项目实际就可以形成一次适合我们项目的测试用例或者测试项目。
有问题欢迎大家评论!!