zoukankan      html  css  js  c++  java
  • 【转】测试思想-测试设计 精简测试用例编写

    大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。

        你可能会说“对呀,本来就是这样的呀,没啥问题呀”。我也觉得这个本身没错,那关键的问题是什么呢? 问题在于时间和可执行性。

         

    话说,写用例、设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起。这不是我吹的,特别是互联网,大部分公司都采用敏捷开发模式,讲究快速,所以,时间往往是有限的,再加上很多公司对敏捷仅停留在概念阶段,以为“敏捷=快速”,把时间花在用例设计上简直就是一种浪费….这样一来,用来设计用例的时间有时候,真是少之又少。如果按传统方式,把用例写得很详细,各种前提条件,步骤,说明,预期结果,编写人,日期啥的,这个时间成本是很高的。

    再说可执行性。经常看到一些人写用例写得很认真,很详细、具体,把每一步的操作都写了,还有一些人一个用例下来,十几个步骤,包含了n个验证点。这种用例的可执行性咋样呢?按我的经历来看,这种类型用例,在测试的时候,用例编写人自己都懒得看用例,完全是按自己的当前时间的想法来测试,而非用例编写人呢?同样的,他也不会完全按照上面的步骤来执行,人嘛,都喜欢按自己的方式来做事,谁会看一下用例步骤,然后操作一下呢?所以,最后的结果是,用例文档就是摆设,放在那里,没人看。

        怎么破?

        我的观点是:测试用例必须写,而且还要“精炼”:能不写的尽量不写,能“简写”的尽量简写----“精简”的思维->简而言之,当前面的部分,已经起到了足够的提醒作用时,后面部分就可以不写。这样做的好处是,不仅可以节省时间,而且还给执行用例的人留下一定的思考空间,有利于TA的成长。

    测试思想-测试设计 <wbr>精简测试用例编写

     

    思维导图编写用例为例:

    1.  一看用例名,就知道步骤及预期结果的,仅写用例名

    这里的用例名,也就是我们的测试点、需求验证点。

    这里对编写测试用例的人有个要求:语言组织能力+思维能力,尽量做到划分合理,且见名知意。

    2.  仅看用例名,不能预知操作步骤的,还须把操作步骤写出来

     

    3.  仅看用例名,不能预知预期结果的,还须把预期结果写出来

     

    4.  预期结果、操作步骤有时候都可简写:直接以备注、说明、提醒点替代

    对比上面的,这样写可能会给人有点“乱”的感觉,但是换个思路想,

    这里实际是把预期结果、操作步骤当作是子验证点(即子用例),采用第一条规则,这里的子用例仅写了用例名,即提醒点,验证点。也就是说,这条用例是由一组子用例构成的。

     

    注:用例粒度可粗可细,结合时间成本考虑,做到合理的划分即可。

     

    5.  针对一些步骤比较复杂的用例,步骤和预期结果都要写出来。

    复杂情况下,一个用例包含多个操作步骤,这些操作步骤中,每个步骤可能都对应一个子测试点(预期结果)。如上,可以新增一个结点,填写预期结果,也可以和操作步骤写在同一个结点,以括号等不同方式进行区分,具体根据个人喜好或者大家达成共识的统一风格。

     

    6.  技巧

    根据具体情况,可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等),让人看得更明白

     

    为了避免模块层级过多,可以不进行模块划分就不划分,当然也可以采用其它技巧,比如模块名称写成“大模块-子模块”的形式

    7.  例子

    测试思想-测试设计 <wbr>精简测试用例编写

    有的人可能会想,我们可以写“通用用例”呀,对,这个似乎是可行的,但是我想说的是:

    1.     用例设计是根据需求来写的,这里的“通用”部分其实并不多,仅小部分,而且单独把某个“点”拿出来考虑,有点类似“断章取义”,意义不大。

    2.     所谓的通用用例,本质上看,也就是设计方法的体现,与其去“记忆”这些会变化的“通用”,还不如多想想你的用例设计里面,哪里体现了、到了这些设计方法。

    写在最后

    1、多去研究下产品,ui交互等,对产品有感觉,自然的不用需求说明,你也知道点击哪个功能会跳出啥结果。

    2、假如用Xmind编写用例,最好能合理的划分模块,然后每个画布放一个模块,具体操作如下,右键中心主题 -> 插入 -> 从主题创建新画布

    测试思想-测试设计 <wbr>精简测试用例编写

    如下,点击不同模块,展示不同模块的用例,这样做的一个好处是啥呢?假如一个画布存放所用用例,可能因为内存的原因,操作时会出现“卡顿”的现象,有时候还打不开文件,保存时也很耗时。

    测试思想-测试设计 <wbr>精简测试用例编写

    3、用例不仅编写者自己看,别人也要看的,所以不管咋写,一定要让人看得懂。

  • 相关阅读:
    pat甲级 1155 Heap Paths (30 分)
    pat甲级 1152 Google Recruitment (20 分)
    蓝桥杯 基础练习 特殊回文数
    蓝桥杯 基础练习 十进制转十六进制
    蓝桥杯 基础练习 十六进制转十进制
    蓝桥杯 基础练习 十六进制转八进制
    51nod 1347 旋转字符串
    蓝桥杯 入门训练 圆的面积
    蓝桥杯 入门训练 Fibonacci数列
    链表相关
  • 原文地址:https://www.cnblogs.com/yanghj010/p/4707213.html
Copyright © 2011-2022 走看看