测试设计|测试用例评审
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
测试用例评审作为测试用例设计过程中必要步骤,可以指数级提升测试用例的质量。为什么这么说呢?下面我们就聊一聊测试用例评审活动。
我们借用 5W1H的模型 ,让各位看官能够更清晰了解测试用例评审活动。
WHY
测试用例评审的目的
首先谈谈Why,也就是测试用例评审的目的,简单的总结一下:
1. 提高测试用例覆盖率 :在评审过程中,项目组中各个角色看待问题的角度不完全一致,所以可以根据各个角色提出的意见和建议,再次考虑测试方法扩充测试用例的全面性,保证测试 用例的覆盖率,从而保证产品质量。
2. 保证测试用例的有效性 :在评审过程中向项目组各个角色阐述测试人员对需求的理解,保证测试用例是得到各个角色认可的有效的用例,减少在测试过程中引起的冲突和争议。
3. 提前发现问题 :在评审过程中,测试人员以及项目组其他成员会对需求进行再一次的确认,可以提前发现需求问题,需求实现问题等,避免在转入测试阶段后再发现,减低修改成本。
WHO
测试用例评审相关人员
接下来是Who,测试用例评审相关的人员。既然是测试活动中的一环,那测试用例评审的主导人(发起人)肯定是测试人员;其他的参与人员:产品经理,对应需求开发人员,对应需求的其他测试人员,项目运营人员,需求的业务方,需求关联的项目组其他成员都是必不可少的。至于为什么加上对应需求?是为了精确人员,减少测试用例评审带来的成本消耗。
HOW
测试用例评审的形式
我们继续看How,测试用例评审的形式。 一般测试用例会采用三种形式:
a.召开评审会议,与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
b. 通过邮件与相关人员沟通确认。
c. 通过IM等交流工具与相关人员进行确认。
选取方式的时候一般遵循以下原则:
a. 正常迭代用例进行会议评审。
b. 紧急需求可选择使用非会议方式评审。
c. 少量优化类需求可选择非会议方式评审。
d. 方式只是手段,得到项目各个角色对于用例的反馈才是目的。
e. 无论采取哪种评审方式,在用例评审前1-2天需要把设计好的测试用例给到项目各个相关角色。
WHEN
测试用例评审的时间节点
用例评审应该在什么时间点进行(When)?两个时间节点: 在用例初步设计完成后进行评审;在用例评审完成并更新后进行确认。
WHAT
测试用例评审的内容
用例评审评审的内容(What):
a.用例是否覆盖需求需要包含的测试点。
b.用例优先级安排是否合理。
c.用例是否具有很好的可执行性。
d.用例是否包含了必要的异常场景(测试用例应当包含百分之二十的正向用例和百分之八十的异常用例)。
e.用例是否从用户角度设计场景和使用流程
以上就是中通科技测试团队用例评审活动的大体步骤和内容。
但是理论和实践之间总是存在着巨大的鸿沟:很多产品线,总是有或大或小的缺陷遗漏到了线上。线上故障分析的时候,有部分比例的线上故障能追根溯源到用例评审环节。用例评审环节本可以发现这些问题的,但总是有各种原因,放过了。 中通科技测试团队在这方面做了一些探索:我们成立了一个跨团队用例评审专家团。
提前拿到各个团队的用例评审时间。
交叉安排不同的测试专家去旁听用例评审活动。
测试专家提前拿到需要评审的用例和需求。
现场专家不发表观点,只记录整个过程。
过程记录事前设计好了模板。
模板内容非常全面 有参与人员,开发产品的投入度,提问的次数等等。
阶段性分析反馈数据,找到共性问题。
通过这种实际参与的方式去发现用例评审存在的痛点,总结下来大致存在以下几个痛点。
用例评审效率低
评审是在做需求讨论,而不是在进行用例评审
单次会议时长太长无法进行有效的评审和意见收集
用例评审参与度低
参与人员不按时参加
与会成员不关注用例情况
多数开发都带着电脑来参加,一直在低头看自己电脑
用例内容不规范
用例照搬PRD
场景类用例缺失
反向异常,并发,安全,兼容性用例缺失
讲解过程没有重点,按顺序念
GUIDE
踩坑改进指南
针对以上存在的痛点,中通科技测试团队总结经验教训,整理出了一份 踩坑改进指南 ,具体如下:
用例评审会议节奏控制:
评审需要控制时间,尽量控制在0.5小时之内,不要超过1小时,提升评审效率可以参以下几点:
对于特别重要的需求,并且需求很多,可以分多次评审,一次一个专题。
根据需求的内容和大小采取多种用例评审方式结合的方式进行。
用例评审前,存在需求不明确的,会议之前多沟通,测试人员多找产品确认,并要求产品及时给与回复并更新好文档。
评审时技术实现跟需求有争议的,2分钟之内没有结论的,及时中断,记录下来,会议后再进行讨论并更新文档。
评审前,测试人员将用例给到项目组各个成员。冒烟用例、疑问用例,高亮不同色系区别出来,要求开发,产品评审前阅读确认测试用例,带着疑问参与用例评审。
只详细评审冒烟用例+有疑问的用例,这个疑问包括但不限于:测试人员在需求文档之外扩展的场景,测试人员怀疑开发人员容易遗忘的场景,测试人员认为容易存在问题的用例。
测试人员互相帮忙,一个主讲测试用例,另一个记录改动点。提高评审效率。
用例评审开始前,先简单一两句话阐述下这个需求的重点。
评审时,测试人员讲场景时,主要讲用例的检查点是什么,不需要描述步骤。
提高参会人员的参与度:
参加用例评审会议时,除了主评审测试人员,产品和开发不要带电脑。
测试人员在过检查点时,主动与产品及开发互动,经常提问,经常确认。
对于参与度一直不高的团队,评审时可以邀请开发负责人或者业务线负责人。
评审后持续跟进:
第一时间整理测试用例,把修正的内容重新整理补全。
会上未确定的内容,会后继续跟进,直到确定结果。
没有任何有疑问的地方了,再做个简单的用例评审会议总结(如修正了哪些功能点,补全了哪些?哪些模块功能有变动?哪些功能推迟到下一期做?等)。
更新后的用例及时同步到项目组各个角色。
测试用例改进:
欢迎关注科技中通,我们后续将进行测试用例改进系列分享。
聊到这儿,测试用例评审相关的事情我们基本上就结束啦,你可能会疑惑,5W1H中剩下的Where哪里去了?其实Where就是大家的所在的工作地啦。
为某个业务目标,而编制的一组由测试输入,执行条件以及预期结果组成的案例
在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。
必须掌握:用例编号(如何命名)、所属模块、用例标题(验证谁在什么情况下,去做什么,最后结果是什么)、优先级、前置条件、操作步骤、测试数据、预期结果、实际结果
了解内容:通过否、bugID、编写人员、编写时间、测试人员、测试时间、备注
测试用例覆盖所有的用户需求
测试用例要简单明了
各类型的测试用例要齐全
用最少的用例覆盖最多的需求
等价类划分 是把所有可能输入的数据分为若干个区域,然后从每个区域中取少量有代表性的数据进行测试即可。
等价类 :何为等价类,某个输入域的集合,在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类。
有效等价类:指符合《需求规格说明书》,输入合理的数据集合
无效等价类:指不符合《需求规格说明书》,输入不合理的数据集合
取值范围型: 输入学生成绩 0-100
恒等类型 : 只有一个结果是正确的,其他都是错误的 例如 彩票的特等奖
布尔值型: 通过是否来进行选择,如同意协议
枚举类型: 给出选项内容,只要符合其中任意一个就可以 例如选择学历
规则类型: 给定要求,满足要求的就可以,比如邮箱
在任意文本输入框中可以填写的字符类型: 中文、英文、特殊符号、空格、数字。
定义:边界值分析 是取稍高于或稍低于边界的一些数据进行测试。
原因: 程序开发循环体时的取数可能会因为<,<=搞错。
上点: 是指边界上的点,无论此时的域是开区间还是闭区间,开区间的话,上点就是在域外,闭区间的话,上点就是在域内。
离点: 是指离上点最近的点,这里就跟是闭区间还是开区间就有关系了,如果是开区间,那么离点就在域内,如果是闭区间,那么离点就在域外。(开内闭外)
遵循的原则:开内闭外 开区间往中间找,闭区间往外找
内点: 域内的任意点都是内点。
0<=x<=10 左上点 0左离点 -1右离点 11 右上点 10 内点 5
0<x<10 左上点 0 左离点 1 右离点 9 右上点 10 内点 5
0<=x<10 左上点 0 左离点 -1 右离点 9 右上点 10 内点 5
因果图法比较适合输入条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出。
1、确定原因、结果、中间过程
2、连接因果图
3、标明约束条件
4、输出测试用例
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充。
输入一串数字,程序可自动从小到大排序
邮箱格式@符合的全角以及半角情况
测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用 例:
无SIM 卡插入时进行呼出(非紧急呼叫)
插入已欠费SIM卡进行呼出
射频器件损坏或无信号区域插入有效SIM卡呼出
网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等)
网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字
最重要的是要思考和分析测试对象的各个方面,多参考以前发现的bug的相关数据,总结的经验,个人多考虑异常的情况、反面的情况、特殊的输入,以一个攻击者的态度对待程序,就能设计出比较完善的测试用例来。
设计测试用例时,分析和表达多输入条件下执行不同操作的黑盒测试方法。
注意: 该方法和因果图法相似。
1、确定原因和动作
2、排列组合
3、标明结果关系
4、输出测试用例
日本人提出
使用工具:正交表
正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析,实现通过少数的实验次数找到较好的生产条件,以达到最高生产工艺效果。
这种试验设计法是从大量的试验点中挑选适量的具有代表性的点,利用已经造好的表格—正交表来安排试验并进行数据分析的方法。
正交表能够在因素变化范围内均衡抽样,使每次试验都具有较强的代表性,由于正交表具备均衡分散的特点,保证了全面实验的某些要求,这些试验往往能够较好或更好的达到实验的目的。
正交实验设计包括两部分内容:第一,是怎样安排实验;第二,是怎样分析实验结果。
在一个界面中有多个控件,每个控件有多个取值,控件之间可以相互组合,不可能(也没有必要)为每一种组合编写一条用例,如何使用最少最优的组合进行测试。——正交排列法
一、等价类划分法
所谓「等价」,就是具有相同属性或者方法的集合,这个集合中某个个体所表现的特征与其他个体完全一致。
由此可知,等价类划分就是将所有可能的输入数据,划分成若干个等价类,然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,分为有效等价类和无效等价类。
例如,规定的用户名长度区间为4~8个字,那么它的有效等价类是用户名长度在[4,8],无效等价类为用户名长度大于8位,或用户名长度小于4位。
二、边界值
测试经验告诉我们,在测试有时会涉及到大量的数据,遍历所有数据会使测试效率低下,如果是手工执行,更加难以覆盖所有数据。这时更有效率的做法是,先划分等价类,再从等价类中选择部分参数测试,边界值是等价类所有可选参数中最容易出问题的地方,所以我们一般会选择边界值作为测试的重点,边界值法的应用步骤如下:
1.先根据等价类法划分有效等价类和无效等价类,确定上点、离点及内点。上点是边界上的点,离点是离上点最近的点,内点则是边界有效范围内的任意一点。同样以用户名长度为4~8位为例,4和8为上点,3和9为离点,6则为内点。
2.设计一个新的测试用例,使其尽可能地覆盖所有尚未覆盖的有效等价类,直到所有有效等价类完全覆盖。
3.设计一个新的测试用例,使其仅覆盖一个无效等价类,直到所有无效等价类都被覆盖。
三、判定表法
判定表又称策略表、决策表,能表示输入条件的组合,以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,具体又明确地表达复杂地逻辑关系和多种条件组合情况。
判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件,动作桩则是所有可能的操作以及产生的结果。
判定表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。其缺点是判定表的建立过程较烦杂,当条件过多时,需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。
四、正交试验法
正交试验法是研究多因素、多水平组合的一种实验法,它是利用正交表来对实验进行设计,通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子,影响试验因子的取值或输入的成为水平。
在设计测试用例时,采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤:
1)分析测试需求,获取因子和水平
2)根据因子和水平选择合适的正交表
3)替换正交表中的因子和水平,获取试验次数
4)根据经验或者其他因素补充试验次数
5)细化输出获得测试用例
以上是一些常见的测试用例设计方法,希望能够解答你的问题。
可以采用软件测试常用的基该方法:等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例,并最终实现暴露隐藏的缺陷,全凭测试设计人员的丰富经验和精心设计。
编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。 软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果(含判断标准)、测试结果、测试时间、测试人员等。
扩展资料
测试用例设计一般遵循以下原则:
(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。
(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外,还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
(3)连贯性。用例组织有条理、主次分明,尤其体现在业务测试用例上;用例执行粒度尽量保持每个用例都有测点,不能同时覆盖很多功能点,否则执行起来牵连太大,所以每个用例间保持连贯性很重要。
(4)可判定性。测试执行结果的正确性是可判定的,每一个测试用例都有相应的期望结果
(5)可操作性。测试用例中要写清楚测试的操作步骤,以及与不同的操作步骤相对应的测试结果。
一、等价类划分法
所谓「等价」,就是具有相同属性或者方法的集合,这个集合中某个个体所表现的特征与其他个体完全一致。
由此可知,等价类划分就是将所有可能的输入数据,划分成若干个等价类,然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,分为有效等价类和无效等价类。
例如,规定的用户名长度区间为4~8个字,那么它的有效等价类是用户名长度在[4,8],无效等价类为用户名长度大于8位,或用户名长度小于4位。
二、边界值
测试经验告诉我们,在测试有时会涉及到大量的数据,遍历所有数据会使测试效率低下,如果是手工执行,更加难以覆盖所有数据。这时更有效率的做法是,先划分等价类,再从等价类中选择部分参数测试,边界值是等价类所有可选参数中最容易出问题的地方,所以我们一般会选择边界值作为测试的重点,边界值法的应用步骤如下:
1.先根据等价类法划分有效等价类和无效等价类,确定上点、离点及内点。上点是边界上的点,离点是离上点最近的点,内点则是边界有效范围内的任意一点。同样以用户名长度为4~8位为例,4和8为上点,3和9为离点,6则为内点。
2.设计一个新的测试用例,使其尽可能地覆盖所有尚未覆盖的有效等价类,直到所有有效等价类完全覆盖。
3.设计一个新的测试用例,使其仅覆盖一个无效等价类,直到所有无效等价类都被覆盖。
三、判定表法
判定表又称策略表、决策表,能表示输入条件的组合,以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,具体又明确地表达复杂地逻辑关系和多种条件组合情况。
判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件,动作桩则是所有可能的操作以及产生的结果。
判定表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。其缺点是判定表的建立过程较烦杂,当条件过多时,需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。
四、正交试验法
正交试验法是研究多因素、多水平组合的一种实验法,它是利用正交表来对实验进行设计,通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子,影响试验因子的取值或输入的成为水平。
在设计测试用例时,采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤:
1)分析测试需求,获取因子和水平
2)根据因子和水平选择合适的正交表
3)替换正交表中的因子和水平,获取试验次数
4)根据经验或者其他因素补充试验次数
5)细化输出获得测试用例
以上是一些常见的测试用例设计方法,希望能够解答你的问题。
定义: 把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,用少量代表性的测试数据,取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
1)确定等价类
有效等价类: 满足输入条件的
无效等价类: 不能满足输入条件的 超出范围的数值
空值
特殊字符
有空格(前、中、后)
2)生成测试用例
每个等价类编写一个测试用例;
设计一条测试用例,尽可能多地覆盖所有还未被覆盖的有效等价类;
设计一条测试用例,覆盖一条还未被覆盖到的无效等价类。
等价类划分的六大原则:
1)输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
例如:手机号码由11位数字组成
有效:11位符合电话号码规则的数字
无效:1、小于11位数字;2、大于11位数字
2)在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可以确立一个有效等价类和一个无效等价类。
3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型,一个布尔量具有两种状态:true和false
4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
例如:
输入条件说明输入为:中文、英文、数字三种之一,则分别取这三种值作为三个有效等价类,另外把这三种字符以外的任何字符作为无效等价类
5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
例如:输入条件说明每个学生可选修1~3门课程
有效:选修1~3门课程
无效:1、未选修课程
2、选修课程超过3门
6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
等价类划分法要点:长度、类型、字母、汉字、特殊字符、空、空格
二、边界值分析法
边界值分析方法是对等价类划分方法的补充。
使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是着重测试边界的情况。选取正好等于,刚刚大于或刚刚小于边界值的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
1)如果输入条件规定了一个输入值范围,那么应针对范围的边界设计测试用例,针对刚刚越界的情况设计无效输入测试用例;
比如:需求规定输入的数字在0~100范围内,此时测试数据应该有一下几类:
a.刚刚等于边界:0、100;
b.刚刚超出边界范围:-1、101:;
c.刚刚在范围内:1、99
2)如果输入条件规定了输入值的数量,那么应针对最小数量输入值、最大数量输入值,以及比最小数量少一个、比最大数量多一个的情况设计测试用例;
例1:输入手机号码有:
a 输入11位合法数字;b 输入10 位合法数字;c 输入12位合法数字
例2:输入6~8位数字密码:
a 输入6位数字;b 输入8位数字c 输入5位数字;d 输入9位数字
3)如果程序输入或输出是一个有序序列,则应该特别注意该序列的第一个和最后一个元素。
三、错误推测法
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。需要多实践,且在实践时多积累常见问题。
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如, 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
四、因果图法
因果图法适用于描述对于多种输入条件组合的测试方法。(有多步输入操作)
根据输入条件的组合、约束条件和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适用于检查程序输入条件涉及的各种组合情况。
例题:有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币,按下“可乐”、“雪碧”、“红茶”按钮,相应的饮料就送出来。若投入的是两元硬币,在送出饮料的同时退还5角硬币。
分析:
输入条件:a 投入1元5角硬币 b 投入2元硬币
1 按“可乐”按钮 2 按“雪碧”按钮 3 按“红茶”按钮
中间状态:1 已投币 2 已按按钮
输出结果:A 送出可乐 B 送出雪碧 C 送出红茶 D 退还5角硬币
测试用例:
1)投币1元5角,按“可乐”按钮,送出可乐
2)投币1元5角,按“雪碧”按钮,送出雪碧
3)投币1元5角,按“红茶”按钮,送出红茶
4)投币2元,按“可乐”按钮,送出可乐,退5角硬币
5)投币2元,按“雪碧”按钮,送出雪碧,退5角硬币
6)投币2元,按“红茶”按钮,送出红茶,退5角硬币
输入组合:投硬币+按按钮
结果组合:送出饮料+退钱
前面我们用了7篇介绍了5种测试用例设计方法,分别是 等价类划分法 、 边界值分析法 、 因果图法 、 判定表法 、 正交实验法 。5种方法各有利弊,根据我多年测试经验,综合使用多种设计方法比使用一种设计方法更有效,设计出来的测试用例覆盖率更高。另外,我们在设计测试用例的时候需要根据任务说明、需求说明、选定的测试策略以及自身因素来综合考虑具体选择哪些设计方法对当前的测试工作更有效!
接下来我为大家分享一个我认为合理有效的策略,该策略原型来源于梅尔斯的《软件测试的艺术》,根据我的经验做了稍微改变以及说明,供大家参考:
1.如果规格说明中包含输入条件组合的情况。
a.如果输入条件较少,应优先考虑因果图分析法;
b.如果输入条件较多,测试用例量过大,则应优先考虑正交实验法。
2.在任何情况下都应使用边界值分析方法。
边界值分析可以产生一系列补充的测试条件。事实上,我们在实际工作中边界值分析法是一个必不可少的重要的设计方法。但是缺点也显而易见,他不能担起测试用例设计的重任,必须与其他设计方法结合使用。
3.应为输入和输出确定有效和无效等价类。
a.等价类划分法可以同边界值分析法一样与其他测试用例结合使用,在必要情况下对上面确认的测试用例进行补充
b.另外,为其他设计方法提供技术支持,比如:在正交表构建过程中,我们确定因素水平就会用到等价类划分法和边界值分析法。
4.使用错误推测法补充更多的测试用例。
这个方法主要是根据规范、经验、常识等提取/增补测试用例。
5.针对上述测试用例集检查程序的逻辑结果。
此处会用到白盒测试用例设计方法,比如:判定覆盖、条件覆盖、判定/条件覆盖或者多重条件覆盖准则。(这些设计方法我们往后放放,暂时先忽略这部分)
要注意的是:使用上述策略并不可能发现所有的错误,但实践证明,这是一个有效的且合理的方案。
另外,关于测试用例还有一些点需要大家注意。
1.一个测试用例必须包含前置条件(背景)、测试输入、测试输出(期望结果);
2.测试用例的粒度越小越好;粒度小的测试用例具有如下优点:
a测试用例的覆盖边界定义更清晰
b.测试结果对产品问题的指向性更强
c.测试用例间的耦合度最低,彼此之间的干扰也就最低
d.测试用例可读性比较高,信息含量越小,可读性越高
3.测试用例必须描述简洁清晰;
a.测试用例必须描述清晰。因为测试用例并不是给自己用的,而且测试用例大多数不是一次性的,所以我们必须要描述清晰,保证下次可用,他人可用。
b.测试用例必须简洁。通常,我们的工作周期都是有限的,且现在迭代更新速度越来越快,所以我们在编写测试用例的时候要注意在描述清晰的前提下,使用简洁的语言。
4.测试用例必须要持续更新;
a.需求大多数情况不是永恒不变的,所以我们在需求发生了改变的时候或者在测试时候发现测试用例描述不准确,不完全时就要及时修改测试用例,以保障测试用例的准确性;
b.测试用例都是人工设计出来的,设计者可能对需求的理解或者功能知识点的理解存在偏差,这样就会造成设计出来的测试用例不准确甚至不正确,这时候我们就需要有辨别是非的能力,且发现测试用例错误后要及时修订,以免造成二度损失/二度浪费。
5.测试用例集合必须是一个“完备”的集合,保证需求中的每个功能点都被覆盖到;这里要注意的是,测试用例要覆盖所有的功能点,而不是要做完全测试;
a. 完全测试: 对产品进行穷尽测试,把所有可能以及所有可能的组合均测试一遍
b. 覆盖所有的功能点: 要求覆盖需求中所有显性功能点(需求说明书提到的)、隐性功能点(没有提到,但是是约定俗成的或者常识性的点,比如我们在测试身份证号码的文本框时候,需求说明书可能只会写:合法允许保存,不合法文本框后提示非法用户,此处不会给出身份证号码具体什么是合法,什么是非法;那么这个点就是隐性功能点;再比如:密码框必须是密文,很多需求中也不会强调,但是我们在测试时候一定要设计这个点的测试用例),我们可以对所有数据通过等价类划分和边界值分析法提取出有代表性数据来做测试即可。
6.只有在深入理解软件需求、甚至架构设计后,我们才有可能设计出“完备”的测试用例集 ;因此,我们在设计测试用例之前一定要好好研究软件需求(对于初级测试人员来讲,大家只要做好这点即可)、架构设计、实际设计等。
7.先正常再异常,且一定要对异常进行测试。 这个很重要,很多人不是忽略了异常情况,就是次序混乱,导致测试用例遗漏或者重复。
8.最最重要的一点,我们在测试用例设计之前一定要先对需求进行测试! 这个就是在需求分析、需求评审阶段测试一定要参与进去,测试参与到项目的时间越早越好。
好了,今天到此结束。如有任何问题请留言及时与我沟通,我会尽快回复大家!谢谢大家~我们下次再见!