【转】测试思想-测试设计 精简测试用例编写

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

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

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

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

怎么破?

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

思维导图编写用例为例:

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

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

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

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

 

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

 

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

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

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

 

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

 

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

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

 

6.  技巧

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

 

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

7.  例子

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

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

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

写在最后

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

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

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

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

时间: 2024-10-04 21:01:02

【转】测试思想-测试设计 精简测试用例编写的相关文章

精简测试用例编写

大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率.再细想想,这种核心作用的本质也就是一种“提醒”作用. 你可能会说“对呀,本来就是这样的呀,没啥问题呀”.我也觉得这个本身没错,那关键的问题是什么呢? 问题在于时间和可执行性. 话说,写用例.设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起.这不是我吹的,特别是互联网,大部分公司都采用敏捷开发模式,讲究快速,所以,时间往往是有限的,再加上很多公司对敏捷仅停留在概念阶段,以为“敏捷=快速”,把时间花

测试用例编写规范

一.测试用例编写准备 从配置管理员处申请软件配置:<需求规格说明书>和<设计说明书>:根据需求规格说明书和设计说明书,详细理解用户的真正需求,并且对软件所实现的功能已经准确理解,然后着手制订测试用例. 二.测试用例制定的原则 测试用例要包括欲测试的功能.应输入的数据和预期的输出结果.测试数据应该选用少量.高效的测试数据进行尽可能完备的测试:基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面: 1.    正确性测试:输入用户实际数据以验证系统是满足需求规格说明

【课程分享】软件测试之Web实战测试网上审批大厅项目(TestDirector应用、功能测试设计、报告编写)

我这里有个课程想和大家分享,有兴趣的朋友可以加我的QQ2059055336和我联系. 课程详细大纲介绍: 第一章:软件测试环境搭建培训              第一节:软件测试基础             第二节:tomcat+JDK的配置及测试环境搭建             第三节:Oracle的安装及使用             第四节:SQL基础培训 第二章:测试管理工具TestDirector培训 第一节:测试管理工具TestDirector的介绍            第二节:Te

SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?

测试人员设计测试用例的时候,面临的第一个问题就是测试用例的步骤是否越详细越好?或者如何把握测试用例的详细步骤?在这个问题上,赞成测试用例详细化的人肯定有不少,因为详细测试用例可以提供如下优点: 1)缺乏经验或者技能的测试人员,可以按照测试用例的步骤顺利开展测试执行工作.这是脚本化测试实践中的思维:有经验与技能的测试人员设计测试用例,而缺乏经验的人员去执行测试用例. 2)缺乏经验的测试人员,按照详细测试用例的步骤执行的过程,不仅可以帮助他们了解测试对象的功能与业务知识,也可以帮助他们了解测试设计技

按照所给的程序流程图,分别写出语句覆盖、分支覆盖的测试用例,以及它所覆盖的路径,根据程序流程图,写出代码,用JUnit生成单元测试,并利用前面设计的测试用例进行测试。

语句覆盖:路径:abc ,测试用例:x=3,y=2 分支覆盖:路径:aeg ,测试用例:x=4,y=-1 /** * 2016-04-09 * @author 吴思婷 * DoWork类用来根据程序流程图,写出代码(定义一个类和方法来实现) */ public class DoWork { public void doWork(int x,int y){ int k=0,j=0; if((x<4 || y>0)&&(y>1)){ y=y+1; } else { if(x&

用一测试面试题来探讨测试用例设计的六大思路

有这样一个面试题:在一个Web测试页面上,有一个输入框,一个计数器(count)按钮,用于计算一个文本字符串中字母a出现的个数.请设计一系列测试用例用以测试这个Web页面. <ignore_js_op> 有经验的测试人员可能会问面试官,字母a区分大小写吗?只统计英文字母的a吗?最长输入字符是多少,最少输入字符是多少?对输入的字符类型是否有限制,是否会自动清除不符合要求的字符?        所以第一步应该是明确需求,然后我们才开始进行思考如何设计测试用例.       通常说来,我们考虑一个测

2、编写单元测试用例,对用户注册功能的DAO层进行测试。(注意:测试用例应考虑成功和失败的情况)

我先对我做的测试进行说明: 对用户注册功能的DAO层进行测试,其实就是对UserDao中的saveUser(User user) 方法进行测试.我在我的测试方法中同时也用到了UserDao中的exitUser(String username)方法进行了测试.     /** * 测试用户注册(成功) */ @Test public void testUserReg(){ User user= new User(); user.setUsername("3137102332_罗文恺");

39.JAVA编程思想之外篇——JAVA图形化设计精简大全一文覆盖

39.JAVA编程思想之外篇--JAVA图形化设计精简大全一文覆盖 欢迎转载,转载请标明出处:http://blog.csdn.net/notbaron/article/details/51204948 目录 Java图形化界面设计--容器(JFrame)...1 Java基本类(JFC)...1 l     AWTAbstract Window Toolkit(AWT)抽象窗口工具包... 2 l     Swing包... 2 l     AWT和Swing的区别... 6 Swing基本框

在敏捷测试中如何设计用例

1.测试用例的粒度测试用例可以写得很简单,也可以写得很复杂.最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素.需要达到的质量目标.需要使用的测试方法等.而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等.测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题.另外,测