软件测试

整理一下软件测试的内容。这里主要讨论一下单元测试和集成测试中的常用方法,根据是否需要运行代码,我们可以将测试方法划分为静态测试和动态测试,根据是否需要了解代码逻辑,我们又可以将测试分为黑盒测试和白盒测试,这里主要以黑盒测试与白盒测试两个方向展开.此外,点一下集成测试的步骤和系统测试的步骤或内容,依据JUnit的使用.

注:容错性:在软件测试中表现为非法数据

一、常用测试方法

（一）、黑盒测试

1.1 等价类划分(可以基于输入域,也可以基于输出域)

1. 基本思路:用一组有限的数据区代表近似无限的数据
2. 相关名词:
   • 单缺陷:一个测试错误很少是由两个或两个以上缺陷共同产生的(即一组样例中只需要一个极值就能测出错误)
   • 多缺陷:测试错误是由两个或两个以上缺陷共同产生的
   • 有效等价类:输入完全满足程序输入的规格说明,有意义的输入数据所构成的集合
   • 无效等价类:不满足程序输入要求或者无效的输入数据构成的结合
3. 过程:
   • 分类:将输入域按照具有相同特性或者类似功能进行分类
   • 抽象:在各个子类中去抽象出相同特性并用实例来表征这个分类
4. 分类:
   • 弱一般等价类:单缺陷+有效等价类
   • 弱健壮等价类:单缺陷+有效等价类+无效等价类
   • 强一般等价类:多缺陷取笛卡尔积+有效等价类
   • 强健壮等价类:多缺陷取笛卡尔积+有效等价类+无效等价类
5. 优点:基于相对较少的测试用例就能够进行完整覆盖,很大程度上减少了重复性
6. 缺点:缺乏特殊用例的考虑,同时需要深入的系统知识,才能选择有效的数据

1.2 边界值分析法(边界包括输入等价类和输出等价类的大小边界,n为参数个数)

1. 基本思路:程序往往在输入输出的边界值情况下发生错误

2. 取点:max+1,max,max-1,min+1,min,min-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,常值做笛卡尔积)

3. 优点:对于多变量函数的测试很有效

4. 缺点:对布尔值或逻辑变量无效

5. 注:边界值分析法常被看作是等价类划分法的一种补充

1.3 决策表法(做笛卡尔积)

1. 基本思路:从输入条件的完全组合来满足测试的覆盖率要求

2. 概念:

   • 条件桩:条件
   • 动作桩:对结果
   • 条件项:针对所列条件的具体赋值,通常表现为对于条件桩相互组合的枚举
   • 动作项:条件项下的动作组合
   • 规则:描述了条件与组合之间的关系

3. 格式:(相同的条件项可以和并为_)

   序号	1	2	3	4
   条件桩1	条件项	条件项	条件项	条件项
   条件桩1	_	条件项	条件项	条件项
   动作桩1	动作项	动作项	动作项	动作项
   动作桩1	动作项	动作项	动作项	动作项

4. 分类:

   • 有限条目决策表:条件项为T/F
   • 扩展条目决策表:条件项为等价类划分的结果

1.4 因果图法(和决策图类似,但需要画图)

1. 基本思路:借助图像,着重分析输入条件的各种组合,每种组合条件就是"因",它必然有一个输出的结果,这就是"果".
2. 流程:
   • 分析软件需求规格说明书
   • 绘制因果图
   • 将因果图转化为判定表
   • 设计测试用例
3. 优点:能用于发现输入或输出中的错误,指出程序规范中的不完全性和二义性
4. 注:因果图法相对于决策表多了绘图的一步,需要记忆相关的符号,如:^表示与,v表示或…

1.5 正交实验法

1. 基本思路:从大量的数据中挑选适量的,有代表性的点(条件组合),从而合理地安排实验
2. 相关名词:通常用(L_n(M^k))来描述一个正交表
   • 因子(k):影响某个相对独立的功能实现的操作对象和外部因素
   • 水平数(M):各个因子取值的状态个数和
   • 正交表行数(n):k(M-1)+1
3. 流程:
   • 阅读需求规格说明书确定因子和水平数
   • 选择合适的正交表
   • 将变量的值映射到表中,为剩下的水平数取值,另外增加一些没有生成但是可以的测试用例
4. 获得正交表:正交表通常是研究数学的学者构建好的,我们直接使用即可.因此建议百度
5. 优点:适用于作为输入条件的原因非常多,每个条件不只有"是"或否两个值,而是有多个值的情况下
6. 缺点:
   • 各个因子的水平数可能不等,需要用包含或组合的方法选取合适的正交表
   • 基于对应的因子数和水平数无法找到直接与之对应的正交表,可以选取行数最少的

1.6 功能图法(没讲)

1.7 错误推测法:经验为主

（二）、白盒测试

1.1 语句覆盖

1. 基本思路:每个可执行语句都要执行到

1.2 判定覆盖

1. 基本思路:每个判断的取真取假分支至少经历一次

2. 语句覆盖和判定覆盖的区别:

   语句:if(a>b) a=b;

   • 语句覆盖:若a=1,b=2,语句覆盖完成,因为以上是作为一条完整的语句被执行到的
   • 判定覆盖:若a=1,b=2,判定覆盖未完成,因为判定覆盖要求判定取真取假都要执行

1.3 条件覆盖

1. 基本思路:每个判断中每个条件的可能取值至少满足一次

1.4 判定-条件覆盖

1. 基本思路:判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次

1.5 条件组合覆盖

1. 基本思路:要求判断中每个条件的所有可能至少出现一次,并且每个判断本身的判定结果也至少一次.关键:让这些结果的所有可能组合都至少出现一次

2. 这话说得太抽了,举个例子:

   条件: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

3. 注:以上白盒测试的样例层层递进,不断细化

1.6 基本路径覆盖

1. 基本思路:设计所有的测试样例,来覆盖程序中的所有可能的,独立的执行路径
2. 流程:
   • 绘制流程图
   • 将流程图中的节点进行合并,简化构成程序流程控制图(为方便计算判断结点,需要将每个判定条件拆分成二元的)
   • 计算程序环路复杂度:判断节点数目+1(有多种算法)
   • 确定一条最长的基本路径
   • 准备测试用例以确保基本路径组中的每一条路径被执行一次

二、集成测试

1. 目标:将已分别通过测试的单元按设计要求集成起来再进行的测试,以检查这些单元之间的接口是否存在问题.
2. 相关概念:
   • 驱动程序：用于测试的控制程序(子上调用程序进行测试)
   • 桩程序：用来替换一部分功能的程序段(自下为程序提供支撑,比如可以代替实际需要使用的下层数据库等外件)

（一）、非渐增式测试

基本思路：先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序

（二）、渐增式测试

基本思路:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试是在模块一个一个的扩展下进行,其测试的范围逐步扩大

2.1 自顶向下法

1. 基本思路:从主控模块("主程序")开始，沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来
2. 特点:不需要驱动程序
3. 分类:
   • 深度优先策略
   • 广度优先测录

2.2 自顶向上法

1. 基本思路：从"原子"模块(底层模块,该模块通常在单元测试中被测试好)开始集成进行测试

（三）、混合策略

1. 分类:
   • 改进的自顶向下法
   • 混合法

三、系统测试

目标:充分运行系统,验证整个系统是否满足功能和非功能性的质量要求

对于web项目常用的测试:

1. 图形测试
2. 兼容性测试
3. 表单测试

测试工具:slenium

四、JUnit使用

这里只是简单聊一下使用,相关的包导入大家可以自行查找maven仓库

1. 构建相关测试类
   • 选择待测试类的类名
   • 按键ctrl+shift+t后选择需要测试的单元后生成测试类
2. 基本测试思路
   • 构建测试类,执行数据操作
   • 通过assertEquals进行断言(输出结果,预期结果)
3. 常用注解:
   • @SetBefore:方法注解,在当前所有test运行开始前执行的操作
   • @SetAfter:方法注解,在当前所有test运行结束后执行的操作
   • @RunWith:类注解,可以用于一次运行多个测试集(Parameters.class),也可以用于运行多个测试类(Suit.class)