浅说《测试用例》----给测试新手的-阿里云开发者社区

开发者社区> 开发与运维> 正文

浅说《测试用例》----给测试新手的

简介:

在此之前我搜集一些关于测试用例的知识,后来在我们的QQ群里专门定了一期讨论,来探讨测试用例,毕竟这是一个很大的话题,很难做到面面俱到,但我会尽量全面,用通俗的语言来说测试用例。


注:我们这里要说的测试用例指功能测试用例。
一、什么是测试用例?

 测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
 通俗的讲:就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。

二、写测试用例有什么好处?
理清思路,避免遗漏

    这里是我们认为最重要的一点,假如我们测试的项目大而复杂,我们可以把项目功能细分,根据每一个功能通过编写用例的方式来整理我们测试系统的思路,避免遗漏掉要测试的功能点。

跟踪测试进展

    通过编写测试用例,执行测试用例,我们可以很清楚的知道我们的测试进度。

历史参考

    在我们所做的项目中,也许会有很多功能是相同或相近的,我们对这类功能设计了测试用例,便于以后我们遇到类似功能的时候可以做参考依据。

重复性

    我们测试一个系统不是一个人测一遍就算测完的,需要多人反复的进行测试,那么我们就需要测试用例来规范和指导我们的测试行为。

告诉领导,这事俺干过,不然别人怎么知道你测没测,测的全面不全面,拿测试用例给他们看呗!俺就是照着这个干活,呵呵!
三、测试用例的方法

 好吧,咱知道啥是测试用例了,也是知道为什么要写测试用例了,那到底应该怎么写?无从下手啊。我们在写测试用例之前,先学习几种方法,它是我们写测试用例的指导思想。
1.  等价类划分
     在某个输入域的子集合,在该子集合中,各个输入数据对于揭露程序中的错误都是等价的。假如有一个输入框要求输入1-10000个数,我们不可能用每一个数去试,我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。那么这个时候我们就可以随机的抽取一些数据来进行验证。如:10 、99、7777......
   等价类分:有效等价类和无效等价类
   输入框要求输入1-10000的数
   有效等价类:可以输入1-10000之间的数来验证,如:2、5、99、8495......
   无效等价类:可以输入1-10000之外的任意字符验证,如:20000、字母、下划线、特殊符号、空格、回车.....
2.  边界值
   边界值是对等价类的补充,测试工作经验告诉我们,大量的错误是出在输入输出的边界价上。我们还拿上面的例子,一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围,如:0、-1、-2、1000、10001.....等等,来判定是否超出了我们的范围。
3.  因果图
   因果图方法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。举个例子:原因:A=0,B=0,结果我就可以判定:A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了,我们为了以免遗漏,可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。
4.  错误推测法
 基于经验和直觉推测出系统可能存在的错误,从而有针对性的设计测试用例的方法。
  1. 其它
    设计测试用例的方法有很多,我们常用就上面几种,其它的方法还有:状态迁移图、流程分析法、正交验证法等等。

四、测试用例的格式与要素
一个测试用例应该包括:编号,标题,测试场景,测试步骤,预期结果。
当然还可加入一些它选项,如:优先级、测试阶段....

注:上面的格式取自《微软的软件测试之道》,它并不一定适合你,我只是让大家对测试格式有个了解。
关于测试用例的存放管理:

  1. 项目管理系统自带的用例管理,一般用例会与项目挂钩,有固定的格式,搜索、修改等功能,使用起来非常方便。如:禅道项目管理、QC、bugfree 等等都带的有用例管理功能。
  2. 通过worldExcel文档形式管理,这样的好处就是自己定义测试用例的格式。
    -----------------------测试用例例子--------------------------------------------------------

基础知识了解的差不多了,下面来看一个具体的测试用例。我们会有更深刻的认识。

注:这不是一个完整的测试用例,格式也不是固定必须这样的,你们可以根据自己的需求编写设计测试用例。

==========================================================================
------------------------------------我们还需要知道的,关于测试用例的-------------------------------
一、.我们在什么时候可以设计测试用例?

当根据客户的需求整理出项目需求分析文档时,我们就可以根据需求文档来编写测试用例了。但是,一般我们(国内大多小公司)项目需求文档都非常“简陋”,所以,很难根据需求文档设计测试用例。
我们只有等到项目开发人员把项目开发出来,给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话),我们根绝这些文档来设计测试用例。

二、测试用例的评审与更新

 我们设计的测试用例设计完成之后,是否完整?是否符合系统?符合客户要求?对用例做一个评审是必不可少。关于评审的方式,不同的公司有不同的流程。
 我们编写的测试用例也不是经过评审之后就不变了,随着需求的变更、功能的改进,测试用例当然也需要更新和变动。

三、什么情况下不适合写测试用例

 文件时间
   如果一个功能我很快就测试完了,而且只需要测试一遍,但我们设计测试用例时却比较麻烦,花时间也长。这个时候就没必要编写测试用例了。
 需求变动大且频繁
  需求的功能变动非常频繁,而且变动很大,之前编写的测试用例根本没法使用,必须要重新编写,这个时候也没必要去设计测试用例了。
 项目时间不允许
  这一项是不太厚道的做法,如果不是急需交付客户的话,尽量不要这样做;当然了,如果只是给客户展示或试用,可以在之后进行补充和完善测试用例。

不要编写不完整或别人看不懂的测试用例,那样就没有意义了。
============个人闲聊内容,欢迎指正========
四、停止软件测试的标准。

  语句覆盖最低不能小于80%,测试需求覆盖率达到100%,测试用例覆盖率达到100%,一、二级缺陷修复率达到100%,三、四级修复率达到80%。
  (上面一句是再网上找的,不是标准,只是个参考)
  bug等级:
  一级:非常严重的bug
  二级:严重的bug
  三级:一般性的bug
  四级:建议性问题

五、关于探索性测试

   完全的执行测试用例时一件非常枯燥的事情,个人在执行测试用例时会做一些,其它的非常规性的操作,看系统是否会有相应的处理和提示。我的一部分bug就是再这种非常规操作下发现的。
   当然了真正的探索性测试需要对产品的深入了解,以及软件开发技术有一定的深度和宽度。姑且把我们的探索性测试看成是瞎捣鼓吧!呵呵。

六、 交叉测试

 有木有发现,当我们第一遍测试系统时,会非常认真,但要我们测试第二遍时,我们不愿意像第一次那样认真的去测了,这不能说明我们不负责,而是每个人都有的心理现象。这个时候,我们可以和其它测试人员交换功能来测试,提高效率,而且更容易发现问题。

七、测试的目的

  1. 我们让它做的它必须会做。
  2. 我们不让它做的它必须不会做。
    可能你会发现有附加功能的时候,就是客户没有要求,我们加了这样的功能,可能加了这点功能系统看上去会更好。这时怎么办?算问题么?

作为开发人员,中规中矩的做东西最好,如果真的有非常好的功能要加的话,需要和客户沟通,然后写到需求里。毕竟多一点功能多一点风险。呵呵

作为测试人员,凡是不符合需求文档的都需要当问题点提出。责任分明,以免后续麻烦。

修改:
1.测试用例的格式的要素,去掉“实际结果”
2.关于测试方法“等价类划分”的解释。
谢谢“zdd”朋友的纠正。:)

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章