软件测试模型.docx
《软件测试模型.docx》由会员分享,可在线阅读,更多相关《软件测试模型.docx(14页珍藏版)》请在冰豆网上搜索。
![软件测试模型.docx](https://file1.bdocx.com/fileroot1/2022-11/28/6f767509-e0f3-4860-90b8-41fa39d7a0c7/6f767509-e0f3-4860-90b8-41fa39d7a0c71.gif)
软件测试模型
软件测试模型
测试策略的简介
测试策略包括:
单元测试、设计测试用例、要测试哪几方面的问题,针对这几方面问题各自测试什么内容,测试的具体步骤及实用测试策略
瀑布模型、螺旋模型、圆形开发模型、增量开发模型、渐进模型、快速应用开发模型
测试分为单元测试、集成测试、系统测试和确认(验收)测试
单元测试针对程序中的模块或构件主要揭露编码阶段产生的错误
单元测试又称模块测试、逻辑测试或结构测试
单元测试的目的:
发现各模块内部可能存在的各种差错
测试的方法:
一般采用白盒法,以路径覆盖为最佳准则,且系统内多模块可以并行地进行测试
集成测试针对集成的软件系统主要揭露设计阶段产生的错误
集成测试也称组装测试,综合测试或联合测试
集成测试:
是按设计要求把通过单元测试的各个模块组装在一起之后进行测试,以便发现与接口有关的各种错误。
集成测试需要考虑的有关问题(即为什么要进行集成测试)
数据经过接口是否会丢失;一个模块对另一个模块是否造成不应有的影响;几个子功能组合起来三能否实现主功能;误差不断积累是否达到不可接受的程度;全局数据结构是否有问题
系统测试:
主要揭露不符合系统工程中对软件要求的错误
在系统测试实施之前软件工程是应完成以下工作
为测试软件系统的输入信息设计出错处理通路
设计测试用例模拟错误数据和软件界面可能发生的错误记录
确认测试检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准
验收测试又称有效性测试合格测试或确认测试
模块组装后已成为完整的软件包,消除了接口的错误确认测试主要由使用用户参加测试,检验软件规格说明的技术标准的符合程度,是保证软件质量的最后关键环节
V模型即快速应用开发模型
需求分析验收测试
系统规格系统测试
概要设计集成测试
详细设计单元测试
编码
应尽早测试才能尽快发现错误降低日后维护中的消耗
所以说需求设计也是需要测试的
V模型的优点
明确表明了测试过程中存在的不同级别
清楚的描述了测试阶段与开发过程各阶段的对应关系
V模型的测试策略包括了低层测试(代码)又包括了高层测试(需求)
V模型的缺点
他仅仅把测试过程作为需求分析概要设计详细设计编码之后的一个阶段容易让人理解为测试是软件开发的最后一个阶段
没有明确说明早期的测试,不符合越早测试和不断地测试的原则
与实际的测试活动也不符
W模型
用户需求双V验收测试设计交付验收测试
需求分析双V系统测试设计实施系统测试
概要设计双V集成测试设计集成集成测试
详细设计双V单元测试设计单元测试
编码
此模型强调:
测试伴随着整个软件开发周期,测试的对象不仅仅是程序,需求、功能和设计同样需要测试。
测试与开发是同步进行的
优点:
符合尽早测试和不断测试的原则符合实际工作中的测试原则
符合实际工作中的测试活动
缺点:
视软件开发活动是一系列串行的活动开发和测试保持一种现行的前后关系这样就无法支持迭代
H模型
所以相应的测试之间也不存在
准备测试测试执行
测试就绪点
其他流程(如设计流程、开发流程)
说明软件测试不仅仅指测试的执行还包括很多其他的活动
软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发进行
只要测试条件策划能够成熟了,测试准备活动完成了,测试执行活动就可以进行了。
X模型
程序片断1固定版本
测试设计执行测试
工具配置测试设计
执行测试工具配置
编码完成集成1…n
执行测试探索性测试
测试设计
程序片断n执行测试
左边描述的是针对单独程序片断进行的相互分离的编码和测试以后将频繁交换最终集成为产品进行版本固定交付用户使用
软件测试设计
设计测试用例
即时贴程序
程序功能
便签的数量最多为50个
标题字数最多40字节
便签正文字数最多200个
年份只能设置在1900-2100之间
测试用例
为实施测试面向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定集合
解决要测什么,怎么测和如何衡量的问题
测试用例的目的:
执行测试,发现缺陷
重复执行测试,重现缺陷
管理测试过程
回归测试、验证缺陷是否修复
优点:
使测试更加方便的执行;提高测试效率;节省测试时间;使测试更能按时间计划进行;使测试过程更方便管理
准备工作
收集资料
需求文档
设计文档
遗留系统的相关文档
与相关人员讨论
探索性测试
探索性测试与经过深思熟虑的、计划好的的测试过程有所不同,它依靠的是测试人员的知识水平和创造力。
可用于重现和分析缺陷、研究缺陷和程序其他模块的相关性
是测试用例有利的补充
具体问题具体分析
测试用例的内容
项目名称(版本)——模块名称——测试功能项
项目人员——测试时间
测试目的——预置条件——其他参考信息
测试用例编号——相关用例
用例说明——输入条件——执行方法
预期结果
测试结果
缺陷编号
常用的测试用例设计方法黑盒测试&白盒测试
黑盒测试是对需求的所有输入条件进行测试
定义:
被称为功能测试或数据驱动测试,在测试时,把被测试程序视为一个黑盒,在不考虑程序内部结构和内部特性的情况下进行测试
黑盒测试方法
等价类划分
分类每类中选取几个数值
等价类划分步骤:
划分等价类:
不考虑程序的内部结构测试人员要对需求规格说明书的功能需求进行细致分析然后把程序的输入域划分成若干部分从每个部分中选取少数代表性数据当作测试用例,经过这种划分后,每一类的代表性数据在测试中的作用都等价于这一类的其他值。
建立等价类表
确定等价类
细化等价类划分
等价类划分分为有效等价类和无效等价类
合理的有意义的输入数据构成的集合就是有效等价类
不合理的、无意义的输入数据构成的集合。
用来检查程序中功能的实现是否不符合规格说明要求。
就是无效等价类。
等价类测试的重要意义
提供了完备性;保证了无冗余性
目的为了减少测试用例
等价类划分规则
为每个等价类规定一个唯一的编号
设计一个新的测试用例使其尽可能多的覆盖违背覆盖的有效等价类为了工作的高效,此项工作重复进行知道所有的有效等价类都被覆盖为止。
设计一个新的测试用例使其覆盖一个而且仅仅一个尚未被覆盖的无效等价类避免出错此项工作重复进行知道所有的无效等价类都被覆盖为止。
之所以要这样做是因为某些程序中对某一输入错误俄检查往往会评比对其他输入错误的检查,因此必须针对每一个无效等价类分别设计测试用例
等价类划分原则
如果输入条件规定了取值范围或者值的个数则可以确定一个有效等价类和两个无效等价类
例如序号值为1到999
1个有效类序号值为1
2个无效类序号值<1&>999
如果输入条件规定了输入值得集合或者是规定了必须如何的条件这时可确立一个有效等价类和一个无效等价类
例如c语言对变量标识符规定为以字母打头的…串,所有字母打头的就是有效等价类
如果输入条件是一个布尔量,则可以确定一个有效等价类一个无效等价类
如果规定了输入数据时一组值,而且程序要对每个输入值分别进行处理这时可为每一个输入值确立一个有效等价类,此外在针对这组确立一个无效等价类它应该是所有不允许输入值得结合
如果规定了输入数据必须遵守的规则则可以确定一个有效等价类(符合规则)。
和若干个无效等价类(从不同角度违反规则)
保险费率计算问题(实战)
某保险公司承担忍受保险,该公司保费计算方式为:
保费=投保额*保险率,保险率依点数不同而有别,10点以上(含10点),费率为0.6%,10点以下费率为0.1%
点数的计算是年龄、性别、婚姻、扶养人数所得的点数的总和
输入:
年龄、性别、婚姻、扶养人数
输出:
保险率
年龄20-396点
40-594点
99以下59以上,20以下1以上2点
性别男5点
女3点
婚姻已婚3点
未婚5点
扶养人数1人扣0.5点最多扣3点(四舍五入)
编写用例
设计测试用例,尽可能的覆盖尚未覆盖的有效等价类
1,8,10.,12
2,9,11,13
3,8,10,14
设计测试用例,使得每一个新设计的测试用例只包含一个无效等价类,其他的选择有效等价类
481012
591113
681014
781014
181015
291116
381016
等价类的特点
测试内容相同
如果等价类中的一个测试能够捕获一个缺陷,那么选择该等价类中的其他测试也能捕获该缺陷
如果等价类中的一个测试不能够捕获一个缺陷,那么选择该等价类中的其他测试也不能捕获该缺陷
注意
考虑无效等价类;仔细划分
经典笔试题——三角形问题
一个程序读入3个整数,把这三个数值看作一个三角形的3条边的长度值,这个程序要打印出信息,说明这个三角形是不等边的,是等腰的,还是等边的,利用等价类划分的方法,给出足够的测试用例。
解题思路:
我们可以设三角形的3条边分别为ABC,如果他们能够构成三角形的3条边,必须满足:
A>0,B>0,C>0且A+B>C,B+C>A,A+C>B
如果是等腰的,还要判断A=B,或B=C,或A=C
如果是等边的,还要判断A=B且B=C,或A=C且B=C
输入条件有效等价类无效等价类
A>0A+B>CA<=0A+B<=C
是三角形B>0B+C>AB<=0B+C<=A
C>0A+C>BC<=0A+C<=B
是等腰A=BA不等于B且
B=CB不等于C且
C=AC不等于A
是等边A=B=CA不等于B
B不等于C
C不等于A
设计用例:
3.4.51.2.3.4.5.6一般三角形
0.1.27
1.0.28
1.2.09
1.2.310
1.3.211
3.1.212
3.3.41.2.3.4.5.6.13等腰
3.4.41.2.3.4.5.6.14等腰
3.4.31.2.3.4.5.6.15等腰
3.4.51.2.3.4.5.6.16非等腰一般三角形
3.3.31.2.3.4.5.6.17等边
3.4.41.2.3.4.5.6.14.18非等边一般三角形
3.4.31.2.3.4.5.6.15.19非等边一般三角形
3.3.41.2.3.4.5.6.13.20非等边一般三角形
边界值
边界值方法小结
输入或输出的边界最容易产生错误
确定边界值的方法
对取值范围进行界定
对取值个数进行界定
有序集合
分析规格说明,找出其他边界条件
隐含的边界值
2的乘方
ASCII表
单缺陷假设
边界值分析的关键假设;在可靠性理论中叫做单缺陷假设,失效极少是由两个或者多个缺陷同时发生引起的;基本边界值获得测试用例的方法,使所有的变量取正常值,只有一个变量取极值。
对于一个有n个变量的程序,保留其中一个变量,让其余的变量取正常值,被保留的变量取正常值,被保留的变量依次取min,min+,nom,max-,max值,对每个变量都重复进行。
这样,对于一个有n个变量的程序,边界值分析测试程序会产生4n+1个测试用例
找零钱的最佳组合(实战)
假设商店商品价格X皆不大于100元(整数),若顾客买一件商品,付款Y在100元内,求找给顾客的最少货币张数?
货币面值
502010521
定义找回零钱为S
S输入输出找回张数
XY502010521
101
0
100101
10099
505010011
49511002125
208010011
19811001124
109010011
991100123
59510011
49610022
29810011
19910011
决策表
(决策表)判定图方法小结:
分析输入条件和输出条件
分析,简化画出输入输出关系图(判定表)
得出测试用例
决策表法是黑盒测试方法中最为严格、最具有逻辑性的测试方法
决策表的优点:
它能够将复杂的问题按照各种可能的情况全部列出,简明并避免遗漏,因此,利用决策表能够设计出完整的测试用例集合
判定图内容:
条件桩列出问题的所有条件
条件项针对条件桩给出的条件列出所有可能的取值
动作桩列出问题规定的可能采取的操作
动作项指出在条件项的各个组取值情况下应采取的动作
决策表化简(动作相同是前提)
合并:
如果一个条件相和另外一个条件相动作时相同的,且两个条件相对应的每一行的执只有一个是不同的,则可以将其合并,合并的项除了不同值变成不关心条目外其余不变
包含:
如果两个条件相的动作时相同的,对人以条件1的值和条件2种对应的值,如果满足:
A如果条件1的值是T(F),则条件2种的值也是T(F)
B如果条件1的值是不关心,则条件2中的值是T,F,不关心,称条件1包含条件2,条件2可以撤去
C重复A,B两条就可以得到精简的决策表
决策表的步骤:
确定规则个数,假设有N个条件,则有2的N次幂个规则
列出所有的条件桩和动作桩
填入条件项
填入动作项,制定初始决策表
进行简化,合并相似规则或者相同动作
决策表的使用范围:
规格说明以判定表的形式给出的,或者很容易转换成判定表
条件的排列顺序和规则的排列顺序不影响执行哪些操作
规则之间是独立的,某一规则触发的操作与其他规则无关
组合测试方法
组合测试关注的是用例对输入变量取值的组合覆盖情况
常见的组合策略有:
全组合,单因素覆盖,两两组合覆盖
全组合覆盖:
是指所有测试用例覆盖所有的输入变量取值间的组合,全组合的数目为变量取值数目间的组合。
全组合覆盖测试能够发现软件中所有的缺陷,但是我们是无法对软件进行全组合覆盖测试
单因素组合覆盖:
所选的测试用例覆盖所有的变量取值,单因素组合覆盖所需的用例数与取值最多的变量的取值数相同。
单因素组合覆盖能够发现软件中所有的单点故障
两两组合(成对组合)覆盖:
所选的测试用例覆盖所有的任意两个输入变量间取值的组合情况。
可以用成对组合集合来表示通常的测试用例集,对于某个给定的测试用例,它能覆盖一定数量的成对组合元素,例如:
测试用例A1B1C2覆盖了(A1,B1),(A1,C2),(B1,C2)3个成对组合元素。
航空公司托运费计算(实战)
某航空公司行李托运费处理规则,低于30公斤(含)免运费,超过30公斤,头等舱的国内乘客,超重1公斤4元,其他舱的国内乘客,超重1公斤6元,国外乘客加一倍,残疾乘客减一倍
判定树
决策表
123456789
国内-TTTTFFFF
头等-TFTFTFTF
残疾-FFTTFFTT
小于30TFFFFFFFF
免费X
2X
3X
4XX
6XX
8X
12X
猜错法
错误猜测:
错误猜测是基于经验和直觉推测程序中所有可能存在的各种错误,从而针对性地设计测试用例的方法
需要测试人员具备的技术:
有关被测系统的知识,如设计方法或实现技术
有关的早期测试阶段的结果的知识
测试类似或相关系统的经验
典型的实现错误的知识
通用的测试经验规则
随机测试的缺点
无法度量随机测试实际覆盖率
许多测试都是冗余的
确定预期结果可能会花费大量的时间
测试数据因为是随机的,重复测试是不可能的
如何选择测试方法:
任何情况下都必须使用边界值分析方法
用等价类划分方法补充一些测试用例
用错误推测法在追加一些测试用例
如果程序的功能说明中含有输入条件的组合情况,则应在一开始就选用因果图法
如果程序某功能适合自动测试,可以采用自动测试以及随机测试
软件故障模型
概念:
测试时有太多的单个输入变量、多个输入变量的组合,我们把这些测试人员的经验和直觉尽量归纳和固化,形成一些故障模型
输入非法数据
输入类型输入字符长度边界值
输入默认值
无效输出
数据结构溢出
如何评价测试设计的好坏
是否可以发现尚未发现的软件缺陷
是否可以覆盖全部的测试需求
易用性:
应当可以花费很少的时间就可以理解测试用例中表达的测试思路并可以很快地执行完这个测试用例
易维护性:
花费很少的时间就完成定位并维护所有相关测试用的工作
有效验证用户需求:
在产品之后的运行中可以充分满足用户需求,不发生重大漏测问题
城区电话号码(实战)
某城市电话号码由三部分组成,分别是
地区码——空白或三位数字
前缀——非0或1开头的三位数字
后缀——4位数字
假定被测程序能够接受一切符合上述规定的电话号码,拒绝所有不符合规定的电话号码,要求
1请选择适当的黑盒测试方法,写出选择该方法的原因,并使用该方法的步骤,给出测试用例表
2如果所生成的测试用例不够全面,请考虑用别的测试方法生成一些补充的测试用例
选择等价类划分
有效无效
地区码空白1三位数字2任意字符3小于3位数4大于3位数5
前缀200——9996任意字符7小于3位数8大于3位数9
起始为010起始为111
后缀4位数字12小于4位13大于4位14任意字符15