大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。
话说,写用例、设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起。这不是我吹的,特别是互联网,大部分公司都采用敏捷开发模式,讲究快速,所以,时间往往是有限的,再加上很多公司对敏捷仅停留在概念阶段,以为“敏捷=快速”,把时间花在用例设计上简直就是一种浪费….这样一来,用来设计用例的时间有时候,真是少之又少。如果按传统方式,把用例写得很详细,各种前提条件,步骤,说明,预期结果,编写人,日期啥的,这个时间成本是很高的。
再说可执行性。经常看到一些人写用例写得很认真,很详细、具体,把每一步的操作都写了,还有一些人一个用例下来,十几个步骤,包含了n个验证点。这种用例的可执行性咋样呢?按我的经历来看,这种类型用例,在测试的时候,用例编写人自己都懒得看用例,完全是按自己的当前时间的想法来测试,而非用例编写人呢?同样的,他也不会完全按照上面的步骤来执行,人嘛,都喜欢按自己的方式来做事,谁会看一下用例步骤,然后操作一下呢?所以,最后的结果是,用例文档就是摆设,放在那里,没人看。
思维导图编写用例为例:
1.
这里的用例名,也就是我们的测试点、需求验证点。
这里对编写测试用例的人有个要求:语言组织能力+思维能力,尽量做到划分合理,且见名知意。
2.
3.
4.
对比上面的,这样写可能会给人有点“乱”的感觉,但是换个思路想,
这里实际是把预期结果、操作步骤当作是子验证点(即子用例),采用第一条规则,这里的子用例仅写了用例名,即提醒点,验证点。也就是说,这条用例是由一组子用例构成的。
注:用例粒度可粗可细,结合时间成本考虑,做到合理的划分即可。
5.
复杂情况下,一个用例包含多个操作步骤,这些操作步骤中,每个步骤可能都对应一个子测试点(预期结果)。如上,可以新增一个结点,填写预期结果,也可以和操作步骤写在同一个结点,以括号等不同方式进行区分,具体根据个人喜好或者大家达成共识的统一风格。
6.
根据具体情况,可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等),让人看得更明白
为了避免模块层级过多,可以不进行模块划分就不划分,当然也可以采用其它技巧,比如模块名称写成“大模块-子模块”的形式
7.
有的人可能会想,我们可以写“通用用例”呀,对,这个似乎是可行的,但是我想说的是:
1.
2.
写在最后
1、多去研究下产品,ui交互等,对产品有感觉,自然的不用需求说明,你也知道点击哪个功能会跳出啥结果。
2、假如用Xmind编写用例,最好能合理的划分模块,然后每个画布放一个模块,具体操作如下,右键中心主题 -> 插入 -> 从主题创建新画布
如下,点击不同模块,展示不同模块的用例,这样做的一个好处是啥呢?假如一个画布存放所用用例,可能因为内存的原因,操作时会出现“卡顿”的现象,有时候还打不开文件,保存时也很耗时。
3、用例不仅编写者自己看,别人也要看的,所以不管咋写,一定要让人看得懂。
文章转载:http://blog.sina.com.cn/s/blog_13cc013b50102vkux.html