一 测试用例(Test Case)
测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,最终形成文档。简单的认为,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软件需求。
1.1作用
- 指导测试的实施
测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试,并对测试情况记录在测试用例管理软件中。 - 规划测试数据的准备
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。 - 编写测试脚本的"设计规格说明书"
为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。 - 评估测试结果的度量基准
完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试
质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,
等等。 - 分析缺陷的标准
通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例
的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映
实施测试或变更处理存在问题。
1.2 重要性
软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标,每个软件产品或软件开发目的都需要有一套优秀的测试方案和测试方法。
影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等。因为有些因素是客观存在、无法避免的;有些因素则是波动的。不稳定的。例如开发团队是流动,有经验的开发人员走了,新人不断补充进来;每个开发人员的工作也会受情绪影响,等等。有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量,从而把人为因素的影响最小化。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。
因此,测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导,是软件测试必须遵守的准则,更是软件测试质量稳定的根本保障。
1.3要素(特点)
- 用例编号
- 测试项
- 测试标题
- 用例属性
- 重要级别:高中低
- 预置条件
- 测试输入
- 操作步骤
- 预期结果
- 实际结果
1.4 举例
- 手机开机
一台新的手机,按开机键,相当于输入了一组数据来测试,预置条件指的是开机的前提条件,比如 是否有电;预期结果就是能顺利打开手机,那么测试完毕后,是否达到了想要的需求(顺利开 机)。
通过上面的描述,我们不难看出,测试用例主要解决的问题是要测什么以及怎么测。 -
新浪用户注册
输入正确的手机号进行测试,即设计一个正例的测试用例
输入错误的手机号进行测试,及设计一个反例的测试用例
二 编写测试用例方法
2.1 等价划分法
-
定义
某个输入域的集合,在这个集合中每个输入条件都是等效的,如果其中一个的输入不能导致问题发生,那么集合中其它输入条件进行测试也不太可能发现错误。
等价类划分是一种重要的、常用的黑盒测试方法,不需要考虑程序的内部程序,只需要考虑程序的输入规格即可。它将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性
关于等价类划分的两个重要概念:
-
有效等价类:有效等价类是程序规格说明有意义,合理的输入数据。
比如用正确的用户名和密码来登录系统就是有效等价类。 -
无效等价类:无效等价类是程序规格说明无意义,不合理的输入数据。
比如用不存在的用户名和密码来登录系统就是无效的等价类。 -
适用场景
对于等价类这个方法,一般适用于有无限多种输入,我们不可能完成穷举测试,等价类可以使我们用较少的测试用例尽可能多的将功能覆盖。 -
案例
- 程序规定
输入三个正整数作为三边的边长构成三角形。请用等价类方法设计测试用例分别判断输入3个整数时的三角形为一般三角形、等腰三角形、等边三角形时情况: - 需求提取
1、 三条边需求:整数/3个数/非零数/正数
2、一般三角形的要求:二边之和大于第三边
3、等腰三角形:二边相等且满足二边之和大于第三 边
4、等边三角形:三条边相等 -
参考答案
- 程序规定
- 步骤
- 先确定有效和无效等价类,得到等价类表
- 有效等价类就是题目条件,设计一个测试用例,使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤,使得有效等价类均被测试用例所覆盖。
- 无效等价类先划分与条件相反的情况,设计一个测试用例,使其只覆盖一个无效等价类。重 复这一步骤使得所有无效等价类均被覆盖,再找到特殊情况(中文、英文、符号、空格、 空)
-
其他案例
-
计算1--100的整数之和(包括1和100)
一般是一个框输入正确的值,一个框输入错误的值,没有两个框都输入错误的值,因为更容易确定到底是那个框出现错误的值。
-
TIM登陆
测试要求是:测试QQ账号,账号的要求是 6---10位正整数。
-
手机号码
某城市电话号码由三部分组成,分别是:地区码:空白或是3位数字;前缀:非‘0’且非‘1’开头 的三位数字;后缀:4位数字。例子:1232341234
-
-
登录界面
用户名(昵称)长度为 3-19:以字母开头;登录名称:非空;密码: 非空;确认密码: 值 和密码相同。
-
总结
在测试文本框的程序时应该考虑如下情况:- 文本框要求输入长度
- 输入的类型
- 组成规则
- 是否为空
- 是否重复---区分大小写
- 是否去除空格
2.2 边界值分析法
-
定义
边界值分析法的理论基础是假定大多数的错误是发生在各种输入条件的边界上,如果在边界附近的取值不会导致程序出错,那么其它的取值导致程序错误的可能性也很小。
边界是对于输入等价类和输出等价类而言,稍高于其边界值及稍低于其边界值的一些特定情况。边界值分析法也是一种常用的黑盒测试方法。 -
案例
依据使用网站的登录页面举例
用户名:1—20个字符,包括1和20,其他不考虑 ; 密码:6个数字,其他不考虑 现要求用边界值分析法测试用户名和密码这两个输入框。
最常见的边界值BUG是因为在代码中将>写成≥,将<写成≤ 有效数据和无效数据的分界点,往往作为程序员编写程序的判断点,是程序员容易犯错误的 地方,也是测试人员重点测试的内容。
# 当用户输入大于0且小于100的数时打印“我爱你”
num = int(input('请输入大于0且小于100的数'))
# 边界值条件判断设置错误
if num >= 0 and num <= 100:
print('我爱你')
-
如何解决这类问题
找到测试数据的边界点,也就是有效等价类和无效等价类的边界点,对边界点数据专门进行测试。一般情况下,需要对边界值(0和100)以及边界值两边的数(-1和1以及101和99)分别进行测试。
对刚才等价划分法最后一个案例的测试用例进行补充和调整:
-
步骤
- 确定边界情况(输入或输出等价类的边界)
- 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试依据
- 边界值的取值依据输入范围区间不同而有所不同,但是都需要把上点值、离点值和内点值取到
- 上点:是指边界上的点,无论此时的域是开区间还是闭区间,开区间的话,上点就是在域外,闭区间的话,上点就是在域内。
- 离点:是指离上点最近的点,这里就跟是闭区间还是开区间就有关系了,如果是开区间,那么离点就在域内,如果是闭区间,那么离点就在域外
-
内点:域内的任意点都是内点。
-
其他案例
- 输入的参数值必须大于等于0同时小于100的整数
# 正确代码
num>-1或num=0 num<101或num<=100
# 错误代码 第一个条件选中了-1,后面的条件忽略了0
num>=-1或num>0或num>=1
# 错误代码 第一个条件选中了101,后面的条件忽略了100
num<=101或num<100或num<=99
-
使用边界值的方法设计添加标题的测试用例
标题长度>0 标题长度<=30
- 学生成绩
输入一个成绩n,判断是否及格(0到100整数)- 确定有效区间和无效区间
- 临界点:0、60、100
- 取值:-1、0、1、59、60、61、99、100、101;
-
具体测试用例
-
修改手机银行登录密码
-
修改手机银行登录密码
密码必须由字母与数字组合;密码长度在8~24之间(包含8和24)
-
总结
- 如果输入条件规定了值得范围,则应取刚好到这个范围的边界值,以及刚好超越这个范围边界的值和刚好小于这个范围边界的值作为输入数据;
- 两位整数加法器数的范围为-99—99,则应测试-98,-99,-100和98,99,100.
- 输入条件规定了值的个数
- 姓名姓名要求1—20个字符,需要测试0、1、2个字符和19、20、21个字符;
- 某商品信息查询系统,每页最多显示10条商品信息,我们就应该准备商品信息,使能够
查询出9、10条、11条、1条、0条商品记录
边界值和等价类区别:边界值分析不是从某等价类中随便挑一个作为代表,而是这个等价类的每个边界都要作为测试条件
常见的边界值:
- 文本框接收字符个数,比如用户名长度,密码长度等;
- 报表的第1行和最后1行;
- 数值元素的第1行和最后1行
- 循环的第1次、2次和倒数第1次、2次。
2.3 因果图法
-
定义
因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适用于检查程序输入条件的各种组合情况
特点:- 考虑输入条件的相互制约及组合关系
- 考虑输出条件对输入条件的依赖关系
核心: - 因果图法比较适合输入条件比较多的情况,测试所有的输入条件的排列组合。所谓的因就是输入,所谓的果就是输出。
-
背景
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况被忽视了。
如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。 -
因果图的基本图形符号
通常在因果图中,用C表示原因,用E表示结果-
恒等
若原因出现,则结果出现;若原因不出现,则结果不出现
若c=1,则e=1
若c=0,则e=0
比如:取钱、打印凭条
-
与
所有条件都为1(true)时结果才为1,如果有任何一个条件为0(false)(或者所有条件均为0)那么结果为0。(简化:全1为1,有0为0)
若几个原因都出现,则结果才出现;若其中一个原因不出现,则结果不出现。
若c1 = 1 并且 c2 = 1,则e1 = 1
若c1 = 0 或 c2 = 0,则e1 = 0
比如:在班级里面戴眼镜、男的、帅的、老师==>我
-
或
若几个原因中有一个出现,则结果出现;若几个原因都不出现,则结果不出现
若 c1 = 1 或 c2 = 1 或 c3 = 1,则e1 = 1
若 c1=c2=c3=0,则e1 = 0
比如:努力、认真、听话==>成绩好
-
恒等
-
非
取反,若原因出现,则结果不出现;若原因不出现,则结果出现
若c1=1,则e1=0
若c1=0,则e1=1
比如:搜索联系人,如果有就不提示错误,如果没就提示错误
-
因果图中的约束条件
-
互斥
E表示a,b,c三个原因不能同时成立;
-
包含
I 表示a,b,c中至少有一个条件成立
-
屏蔽
M 表示结果a是1,则结果b强制为0
-
唯一
O 表示a、b条件中有且仅有一个成立
-
要求
R 表示当a出现时b也必须出现
-
-
-
因果图法步骤
- 找出所有的原因,原因即输入条件或输出条件的等价类
- 找出所有的结果,结果即输出条件
- 明确所有输入条件之间的制约关系以及组合关系,即哪些条件不能组合到一起,哪些条件可以组合到一起
- 明确所有输入条件之间的制约关系以及组合关系,那些输出结果不能同时输出,哪些输出结果可以同时输出
- 找到什么样的输入条件组合会产生哪种输出结果
- 把因果图转换成判定表/决策表
- 为判定表/决策表中的每一列表示的情况设计测试用例
-
案例
交通一卡通自动充值软件系统需求
步骤1:了解需求,找出所有的输入条件(因)
- 投币50元
- 投币100元
- 充值50元
- 充值100元
输入条件1、2互斥输入条件3 、4互斥
根据输入条件得到的结论:- 不能组合的输入条件
- 条件1和条件2不能组合
- 条件3和条件4不能组合
- 可以组合的输入条件
- 条件1和条件3可以组合
- 条件1和条件4可以组合
- 条件2和条件3可以组合
- 条件2和条件3可以组合
- 123可以单独出现
步骤2:找出所以的输出结果(果)
a.成功充值并退卡
b.提示充值成功
c.找零
d.错误提示并退卡
输出结果a、d互斥,b、d互斥
根据输出结果得到的结论:
- 不能组合的输出
- 输出a和输出d不能组合
- 输出b和d不能组合
- 能组合的输出
- 输出a和b必须组合
- 输出a、b、c组合
- 输出c、d可以组合
- 输出d单独存在
情况一:输入条件1和条件3组合,输出a和b组合
根据因果图在制作出对应的决策表/判定表
情况二:输入条件1和条件4组合,输出c、d组合
根据因果图再制作出对应的决策表/判定表
情况三:条件2和条件3组合,输出a、b、c组合
根据因果图在制作出对应的决策表/判定表
情况四:条件2和条件4组合,输出a和b组合
根据因果图再制作出对应的决策表/判定表
情况五:条件1单独出现,输出c、d组合
根据因果图再制作出对应的决策表/判定表
情况六:条件2单独出现,输出c、d组合
根据因果图再制作出对应的决策表/判定表
情况七:条件3单独出现,输出d组合
根据因果图再制作出对应的决策表/判定表
情况八:条件4单独出现,输出d组合
根据因果图再制作出对应的决策表/判定表
2.4 判定表法
-
定义
因果图只是一种辅助工具,通过分析最终得到判定表,再通过判定表编写测试用例。但有时画因果图非常麻烦,影响测试效率,可以直接写判定表,进而编写测试用例。 -
组成
- 条件桩:所有条件
- 动作桩:所有输出(结果)
- 条件项:针对条件桩的取值
- 动作项:条件项的各种取值情况下的输出结果
-
判定表流程
- 列出所有的条件桩和动作桩
- 填入条件项
- 填入动作项、得到初始判定表
- 简化判定表(合并相似规则(相同动作))
-
案例
怎样成为一个好学生?遵纪守法的前提下,学习成绩好是一个好学生、品德高尚也是一个好学生;(只要违法乱纪就绝对不是一个好学生;成绩和品德有一项,再加遵纪守法也是好学生)
2.5 场景设计法(流程分析法)
-
定义
场景法就是模拟用户操作软件时的场景,主要用于测试系统的业务流程。当拿到一个测试任务时,我们并不是先关注某个控件的边界值、等价类是否满足要求,而是要先关注它的主要功能和物业流程是否正确实现,这就需要使用场景法来完成测试。
当业务流程测试没有问题,也就是该软件的主要功能没有问题时,我们在重点从边界值、等价类方面对控件进行测试。
在冒烟测试时也主要采用场景法进行测试 -
重要概念
- 基本流
通过业务流程输入都为正确的,能够最后达到目标的流程 - 备选流
按照通过实现业务流程时,因错误操作或异常输入,导致流程存在反复,但最终能够完成期望业务流程 - 异常流
通过实现业务流程时
通过实现业务流程时,因错误操作或异常输入,导致业务没有正确完成
- 基本流
-
背景
现在的软件几乎都是由事件触发来控制流程的,事情触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成时间流。
将这种在软件设计方面的思想引入到软件测试中,生动的描述出事件触发时的情景,有利于测试设计者测试用例,同时测试用例也更容易的得到理解和执行。
在使用场景法设计测试用例时,需要覆盖系统用例中的主成功场景和扩展场景,并且需要适当补充各种正反的测试用例和考虑出异常场景的情形。
当使用场景法测试程序没有问题时,可以再使用边界值、等价类方法对账号、密码进行更改细致、完整的测试。 -
案例
TIM登录,使用场景法测试 qq登录功能
- 输入正确的账号和密码后点击“登录”按钮,程序能正常登录
- 输入正确的账号,错误的密码后点击“登录”按钮,程序应给出错误提示
- 输入正确的账号,不输入密码,点击“登录”按钮,程序应给出错误提示
- 不输入账号和密码,直接点击“登录”按钮,程序给出错误提示“请您输入账号后登录”
- 不输入账号,输入正确的密码,点击“登录”,程序应给出错提示
- 输入错误的账号,正确的密码,点击“登录”按钮,程序应给出错误提示
2.6 正交试验法
-
定义
正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。当可能的输入数据或者输入数据的组合数量很大时,由于不可能为每个输入组合都创建测试用例,可以采用这种方法。 -
案例
某所大学通信系共2个班级,刚考完某一门课程,想通过“性别”、“班级”和“成绩”这三个查询条件对通信系这门课程的成绩分布,男女比例或班级比例进行人员查询:
根据“性别”=“男,女”进行查询
根据“班级”=“1班,2班”查询
根据“成绩”=“及格,不及格”查询
分析上述测试需求,有3个被测元素,被测元素我们称为因素,每个因素有两个取值,我们称之为水平值,所以全部测试用例个数是2 * 2 * 2 = 8
由于组合量太大,不可能为每一种组合都创建测试用例。如何采用最少的测试用例集合获得最大的测试覆盖率——采用正交排列法-
正交排列法
- 正交试验设计(科普)
是研究多因子多水平的一种设计方法,它是根据正交性从全面实验中挑选出部分有代表性的点进行试验,这些有代表性的点具备了“均匀分散,齐整可比”的特点,正交试验设计是一种基于正交表的、高效率、快递、经济的实验设计方法。
因子:所有参与实验的影响实验结果的条件称为因子
水平:影响实验因子的取值或输入称为水平 -
正交表的概念
一种特制的表,一般的正交表为:Ln(m^k)
n是表的行数,也就是需要测试组合的次数;k是表的列数,表示控件的个数(因素的个数,或因子个数);m是每个控件包含的取值个数(各因素的水平数,几个因素的状态数)
如L9(3^4):4个控件,每个控件三个取值,9为需要测试的组合个数。称为4因素3水平
利用正交表设计测试用例,我们得到的测试用例个数是n=3*(2-1)+1=4,对于三因素两水平的刚好有L4(2^3)的正交表可以套用,于是用正交表试验法得出4个测试用例如下:
4个测试用例与8个测试用例相比测试用例个数是减少了。因素数和水平数越大越能体现用正交表的好处。例如:对于一个四因素且每个因素均为三水平的试验,如果按照全面试验需要进行 3 * 3 * 3 = 81 次。但是如果用正交试验法选择L9(3^4)正交表,n = 4 * (3-1)+1 = 9次试验就可以覆盖。从这点可以说明用正交实验法能有效地、合理地减少测试测试用例和工时,节约测试成本。
优点:- 根据正交性从全面试验中挑选出部分有代表性的点进行试验,这些有代表性的特点具备了“均匀分散,整齐可比”的特点。通过使用正交试验法减少了测试用例,合理地减少测试的工时与费用,提高测试用例的有效性。是一种高效率、快速、经济的试验设计方法。
缺点: - 对每个状态点同等对待,重点不突出,容易造成在用户不常用的功能或场景中,花费不少时间进行测试设计与执行,而在重要路径的使用上反而没有重点测试。
- 根据正交性从全面试验中挑选出部分有代表性的点进行试验,这些有代表性的特点具备了“均匀分散,整齐可比”的特点。通过使用正交试验法减少了测试用例,合理地减少测试的工时与费用,提高测试用例的有效性。是一种高效率、快速、经济的试验设计方法。
- 正交试验设计(科普)
-
正交排列法
-
正交表生成工具allpairs
有时候会碰到因子的水平数不同的情况,如下:
这时候就需要借助工具来实现。
链接:https://pan.baidu.com/share/init?surl=fFR8iH62vwOeEHlLmK9hgw
提取码:fm9q
-
制作取值表(只列出数据即可,不用编号)
-
复制取值表的数据,放到文本文档中保存(注意不要更改任何格式,例如文件叫test.txt)
-
把文本文档放在allpairs文件中
- win + r 后输入cmd进入控制台
- 使用控制台代码进入allpairs文件夹(cd目录名称)
-
在控制台中输入allpairs.exe test.txt > chenggong.txt (chenggong是自己起的名称,用来存放生成的组合用例,可以自动生成,不必提前建好)
-
最终得出测试用例
2.7错误推断法
-
定义
错误推测法是指利用直觉和经验猜测出出错的可能类型,有针对性列举出程序中所有可能的错误和容易发生错误的情况,它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。 -
基本思想
基本思想是列举出肯能犯的错误或错误易发生的清单,然后根据清单编写测试用例;这种方法很大程度上是凭经验进行的,即凭人们对过去所作测试结果的分析,对所揭示缺陷的规律性作直觉的推测来发现缺陷。
采用错误推测法,最重要的是要思考和分析测试对象的各个方面,多参考以前发现的Bug的相关数据、总结的经验,个人多考虑异常的情况、反面的情况。特殊的输入,以一个攻击者的态度对待程序,才能够设计出比较完善的测试用例
总结
通常,在确定测试方法时,应遵循以下原则:
- 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
- 认真选择测试策略,以便能尽可能少的使用测试用例,发现尽可能多的程序错误
因为一次完整的软件测试过后,如果程序中遗留的错误过多并且严重,则表明该次测试是不足的,而测试不足则意味着让用户承担隐藏错误带来的危险,但测试过度又会带来资源的浪费。因此测试需要找到一个平衡点。
3.1 测试方法选择
- 拿到一个测试任务时,先关注它的主要功能和业务流程、业务逻辑是否正确实现,考虑使用场景法。
- 需要输入数据的地点,考虑采用等价类等类划分法,包括输入和输出条件的等价划分,将无线测试变成有限测试。
- 在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
- 如果程序的功能说明中含有输入条件的组合情况,则一开始就应考虑选用因果图和判定表法。
- 对参数配置类的软件,需要考虑参数之间的组合情况,考虑使用正交排列法选择较少的组合方式(最少的测试用例获得最大的测试覆盖率)
- 对照程序逻辑,检查已设计出的测试用例的覆盖程度。如果没有达到要求的覆盖标准,则应当再补充更多的测试用例
- 采用错误推断法再追加测试用例--依靠测试工程师的经验和智慧。
3.2 测试用例力度
测试用例可以写的很简单,也可以写的很复杂。
- 简单的测试用例
最简单的测试用例时测试的纲要,仅仅指出要测试的内容。
测试用例写的过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是需要把测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。 - 复杂的测试用例
最复杂的测试用例则会指定输入的每项数据,期待的结果即检验方法,具体到界面元素的操作步骤,指定测试的方法和工具等。
测试用例写得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。
大多数的测试团队编写的测试用例的力度介于两者之间
3.3 测试用例本质
测试用例的设计本质应该是在设计的过程中理解需求,检查需求,并把软件系统的测试方法的思想记录下来,以便指导将来的测试
- 基于需求的测试用例设计:
基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的
要把测试用例当成活的文档,因为需求是活的,善变的。因此在设计测试用例方面应该把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。
不要认为测试用例设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同阶段都要回来重新评审和完善测试用例。
3.4 测试用例评审
-
同行评审
测试用例的检查方式有很多,同行评审是其中最敏捷的一种。
“个体和交互比过程和工具更有价值”,这强调了测试用例设计者之间的思想碰撞,通过探讨、协作来完成测试用例的设计。 -
用户评审
“顾客的协作比合同谈判更有价值”。
如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场调查人员或相关领域专家)
四 企业面试题
- 正交表测试用例设计方法的特点是什么?
参考答案
用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;具体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。 - 描述测试用例设计的完整过程?
参考答案
需求分析+需求变更的维护工作;
根据需求得出测试需求;
设计测试方案,评审测试方案;
方案评审通过后,设计测试用例,在对测试用例进行评审 - 你认为做好测试用例工作的关键是什么?
参考答案
需求和设计文档的理解程度,对系统的熟悉程度 - 完成测试程序是可能的吗?
软件测试初学者可能认为拿到软件后需要进行完全测试,找到全部的软件缺陷,使软件“零缺陷”发布。
实际上完全测试是不可能的。主要有以下几个原因:
- 完全测试比较耗时,时间不允许;
- 完全测试通常意味着较多资源投入,这在现实中往往实行不通的;
- 输入量太大,不能一一进行测试;
- 输出结果太多,只能分类进行验证;
- 软件实现途径太多;
- 软件产品说明书没有客观标准,从不同的角度看,软件缺陷的标准不同;因此测试的程度要根据实际情况确定。
- 为什么要在一个团队中开展软件测试工作?
参考答案
因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。 - 一个成功的测试是(B)
A. 发现错误 B.发现了至今尚未发现的错误
C. 没有发现错误 D. 证明发现不了错误 - 测试过程的活动几乎贯穿整个开发过程,他大体分为 (D) 和系统测试阶段。
A. 模块测试、集成测试、有效性测试
B. 模块测试、功能测试、回归测试
C. 单元测试、功能测试、产品测试计划
D. 单元测试、集成测试、确认测试 - 编码阶段产生的错误有(A) 检查出来。
A. 单元测试 B. 集成测试
C. 有效性测试 D. 系统测试 - 软件是包括 的完整集合。
- 瀑布模型表达了一种系统的、顺序的软件开发方式。以下关于瀑布模式叙述正确的是(D)
A. 瀑布模型能够非常快速的开发大规模软件项目
B. 只有很大的开发团队才使用瀑布模型
C. 瀑布模型已不再适合于现今的软件开发环境
D. 瀑布模型适用于软件需求确定,开发过程能够采用线性方式完成的项目