软件测试
整理一下软件测试的内容。这里主要讨论一下单元测试和集成测试中的常用方法,根据是否需要运行代码,我们可以将测试方法划分为静态测试和动态测试,根据是否需要了解代码逻辑,我们又可以将测试分为黑盒测试和白盒测试,这里主要以黑盒测试与白盒测试两个方向展开.此外,点一下集成测试的步骤和系统测试的步骤或内容,依据JUnit的使用.
注:容错性:在软件测试中表现为非法数据
一、常用测试方法
（一）、黑盒测试
1.1 等价类划分(可以基于输入域,也可以基于输出域)
-
基本思路:用一组有限的数据区代表近似无限的数据
-
相关名词:
- 单缺陷:一个测试错误很少是由两个或两个以上缺陷共同产生的(即一组样例中只需要一个极值就能测出错误)
- 多缺陷:测试错误是由两个或两个以上缺陷共同产生的
- 有效等价类:输入完全满足程序输入的规格说明,有意义的输入数据所构成的集合
- 无效等价类:不满足程序输入要求或者无效的输入数据构成的结合
-
过程:
- 分类:将输入域按照具有相同特性或者类似功能进行分类
- 抽象:在各个子类中去抽象出相同特性并用实例来表征这个分类
-
分类:
- 弱一般等价类:单缺陷+有效等价类
- 弱健壮等价类:单缺陷+有效等价类+无效等价类
- 强一般等价类:多缺陷取笛卡尔积+有效等价类
- 强健壮等价类:多缺陷取笛卡尔积+有效等价类+无效等价类
-
优点:基于相对较少的测试用例就能够进行完整覆盖,很大程度上减少了重复性
-
缺点:缺乏特殊用例的考虑,同时需要深入的系统知识,才能选择有效的数据
-
距离：一个班级有30~40个人,30~40张桌
-
弱一般等价类：
- 人数/桌数：35/35（可以去30~40之间的任意值，一般取中位数）
-
弱健壮等价类：
- 弱一般等价类
- 人数/桌数：35/20
- 人数/桌数：35/50
- 人数/桌数：20/35
- 人数/桌数：50/35
注：这里为什么需要四个样例，是为了基于单缺陷取值且取满整个平面（两个变量，正常情况下都需要四个无效值测试用例）
-
强一般等价类：基于多缺陷，取满平面内每个范围所有有效值点，用的较少
-
强健壮等价类：基于单缺陷，取满平面内每个范围所有有效值和无效值点
-
1.2 边界值分析法(边界包括输入等价类和输出等价类的大小边界,n为参数个数)
-
基本思路:程序往往在输入输出的边界值情况下发生错误
-
取点:min-1,min,min+1,常值(一般可以取中间值),max-1,max,max+1
分类:
- 边界值分析:基于单缺陷
- 一般:4n+1个样例(max-1,max,min+1,min,常值)
- 健壮:6n+1个样例(max+1,max,max-1,min+1,min,min-1,常值)
- 最坏情况分析:基于多缺陷
- 一般:\(5^n\)个样例(max-1,max,min+1,min,常值做笛卡尔积)
- 健壮:\(7^n\)个样例(max+1,max,max-1,min+1,min,min-1,常值做笛卡尔积)
- 边界值分析:基于单缺陷
-
优点:对于多变量函数的测试很有效
-
缺点:对布尔值或逻辑变量无效
-
注:边界值分析法常被看作是等价类划分法的一种补充
1.3 决策表法(做笛卡尔积)
-
基本思路:从输入条件的完全组合来满足测试的覆盖率要求
-
概念:
- 条件桩:条件
- 动作桩:对结果
- 条件项:针对所列条件的具体赋值,通常表现为对于条件桩相互组合的枚举
- 动作项:条件项下的动作组合
- 规则:描述了条件与组合之间的关系
-
格式:(相同的条件项可以和并为
_)序号 1 2 3 4 条件桩1 条件项 条件项 条件项 条件项 条件桩1 _ 条件项 条件项 条件项 动作桩1 动作项 动作项 动作项 动作项 动作桩1 动作项 动作项 动作项 动作项 -
分类:
- 有限条目决策表:条件项为T/F
- 扩展条目决策表:条件项为等价类划分的结果
1.4 因果图法(和决策图类似,但需要画图)
- 基本思路:借助图像,着重分析输入条件的各种组合,每种组合条件就是"因",它必然有一个输出的结果,这就是"果".
- 流程:
- 分析软件需求规格说明书
- 绘制因果图
- 将因果图转化为判定表
- 设计测试用例
- 优点:能用于发现输入或输出中的错误,指出程序规范中的不完全性和二义性
- 注:因果图法相对于决策表多了绘图的一步,需要记忆相关的符号,如:
^表示与,v表示或…
1.5 正交实验法
- 基本思路:从大量的数据中挑选适量的,有代表性的点(条件组合),从而合理地安排实验
- 相关名词:通常用\(L_n(M^k)\)来描述一个正交表
- 因子(k):影响某个相对独立的功能实现的操作对象和外部因素
- 水平数(M):各个因子取值的状态个数和
- 正交表行数(n):k(M-1)+1
- 流程:
- 阅读需求规格说明书确定因子和水平数
- 选择合适的正交表
- 将变量的值映射到表中,为剩下的水平数取值,另外增加一些没有生成但是可以的测试用例
- 获得正交表:正交表通常是研究数学的学者构建好的,我们直接使用即可.可以自行百度常用正交表
- 优点:适用于作为输入条件的原因非常多,每个条件不只有"是"或否两个值,而是有多个值的情况下
- 缺点:
- 各个因子的水平数可能不等,需要用包含或组合的方法选取合适的正交表
- 基于对应的因子数和水平数无法找到直接与之对应的正交表,可以选取行数最少的
1.6 错误推测法:经验为主
（二）、白盒测试
1.1 语句覆盖
- 基本思路:每个可执行语句都要执行到
1.2 判定覆盖
-
基本思路:每个判断的取真取假分支至少经历一次
-
语句覆盖和判定覆盖的区别:
语句:
if(a>b) a=b;- 语句覆盖:若a=1,b=2,语句覆盖完成,因为以上是作为一条完整的语句被执行到的
- 判定覆盖:若a=1,b=2,判定覆盖未完成,因为判定覆盖要求判定取真取假都要执行
1.3 条件覆盖
- 基本思路:每个判断中每个条件的可能取值至少满足一次
1.4 判定-条件覆盖
- 基本思路:判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次
1.5 条件组合覆盖
-
基本思路:要求判断中每个条件的所有可能至少出现一次,并且每个判断本身的判定结果也至少一次.关键:让这些结果的所有可能组合都至少出现一次
-
这话说得太抽象了,举个例子:
条件:a,b,c,d
判定:判定A为(a&&b),判定B为(c||d)
条件组合:
编号 条件(a,b/c,d) 判定(A/B) 1 T,T T 2 T,F F 3 F,T F 4 F,F F 5 T,T T 6 T,F T 7 F,T T 8 F,F F 测试样例:能把上面的组合覆盖到即可,如使样例分别满足1,5/2,6/3,7/4,8
-
注:以上白盒测试的样例层层递进,不断细化
1.6 基本路径覆盖
- 基本思路:设计所有的测试样例,来覆盖程序中的所有可能的,独立的执行路径
- 流程:
- 绘制流程图
- 将流程图中的节点进行合并,简化构成程序流程控制图(为方便计算判断结点,需要将每个判定条件拆分成二元的)
- 计算程序环路复杂度:判断节点数目+1(有多种算法)
- 确定一条最长的基本路径
- 准备测试用例以确保基本路径组中的每一条路径被执行一次
二、集成测试
- 目标:将已分别通过测试的单元按设计要求集成起来再进行的测试,以检查这些单元之间的接口是否存在问题.
- 相关概念:
- 驱动程序：用于测试的控制程序(子上调用程序进行测试)
- 桩程序：用来替换一部分功能的程序段(自下为程序提供支撑,比如可以代替实际需要使用的下层数据库等外件)
（一）、非渐增式测试
基本思路：先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序
（二）、渐增式测试
基本思路:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试是在模块一个一个的扩展下进行,其测试的范围逐步扩大
2.1 自顶向下法
- 基本思路:从主控模块("主程序")开始，沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来
- 特点:不需要驱动程序
- 分类:
- 深度优先策略
- 广度优先测录
2.2 自顶向上法
- 基本思路：从"原子"模块(底层模块,该模块通常在单元测试中被测试好)开始集成进行测试
（三）、混合策略
- 分类:
- 改进的自顶向下法
- 混合法
三、系统测试
目标:充分运行系统,验证整个系统是否满足功能和非功能性的质量要求
对于web项目常用的测试:
- 图形测试
- 兼容性测试
- 表单测试
测试工具:slenium
四、JUnit使用
这里只是简单聊一下使用,相关的包导入大家可以自行查找maven仓库
- 构建相关测试类
- 选择待测试类的类名
- 按键
ctrl+shift+t后选择需要测试的单元后生成测试类
- 基本测试思路
- 构建测试类,执行数据操作
- 通过assertEquals进行断言(输出结果,预期结果)
- 常用注解:
- @SetBefore:方法注解,在当前所有test运行开始前执行的操作
- @SetAfter:方法注解,在当前所有test运行结束后执行的操作
- @RunWith:类注解,可以用于一次运行多个测试集(Parameters.class),也可以用于运行多个测试类(Suit.class)
