软件测试技术

软件测试技术

一、 软件测试概述

（2）、什么是软件测试
软件测试是人工地，或通过使用工具来自动地运行被测系统，或静态检查被测系统的过程，其目的在于校验被测系统是否满足需求，或要弄清楚实际的系统输出与预期系统输出之间的差异。
软件测试包括动态测试和静态检查两类
测试的执行包括人工和自动化两类策略
（3）、软件测试流程

4）、软件缺陷的正式定义
1、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好，则是缺陷。
2、软件未达到需求规格说明书中指明的功能，则是缺陷。
检测正常功能、正常流程
检测性能
3、软件出现了需求规格说明书中指明不会出现的错误，则是缺陷
检查异常情况
检查无效用户输入的识别能力
检查无效用户输入的处理能力
4、软件功能超出需求规格说明书中指明的范围，则是缺陷
无意加入，过错缺陷
人为加入，需求缺陷
5、软件未达到需求规格说明书中虽未指明但应达到的目标，则是缺陷
隐含特性，需求缺陷
核心：紧紧抓住用户需求
措施：软件质量控制
纠偏：测试人员不应对所有缺陷负责

（2）软件缺陷的状态
1、提交——测试人员提交了一个缺陷给程序员
2、打开——待处理
3、拒绝——程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4、修复——程序员修复缺陷后提交的一个状态
5、关闭——测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
6、推迟——可以放在后续版本解决的问题，但要详细写出修复日期或版本
5）测试用例（Test Case）
基于风险最低、效率最高、分而治之的测试设计原则
测试用例就是：1、能代表需求的小的测试单元；2、描述用户预期输出；3、反映系统实际执行结果。
测试用例组成：输入（测试数据和操作步骤）+输出（系统预期执行结果）+测试环境（是系统环境设置，即进行人机测试所必需的工作平台和前提条件）

软件测试用例的基本要素包括：用例编号、用例标题、用例级别、测试环境、测试输入、执行操作、预期结果
6）软件测试分类
（1）、从测试阶段或对象的角度：单元测试、集成测试、系统测试、验收测试
（2）、从测试模式的角度：黑盒测试、白盒测试和灰盒测试
（3）、从测试目标的角度：回归测试、功能测试、性能测试、Alpha测试、Beta测试、压力测试、负载测试、安全性测试、配置测试、安装测试、可用性测试、可恢复性测试等
（4）从测试执行方式的角度：手动测试、自动化测试和半自动化测试

7）软件质量
1、软件产品中能满足给定需要的性质和特性的总体
2、软件具有所有期望的各种属性的组合程度
3、顾客和用户觉得软件满足其综合期望的程度
4、确定软件在使用中将满足顾客预期要求的程度

二、黑盒测试技术

只知道系统输入和预期输出，不需要了解系统输入和预期输出，不需要了解程序内部结构和内部特性的测试方法就称为黑盒测试

分类：（1）功能测试：逻辑功能测试；界面测试；易用性测试；安装测试；兼容性测试（2）性能测试：时间性能；空间性能；一般性能；稳定性；负载测试；压力测试
测试方法评价标准：

以用户需求为中心，坚持高效的测试用例设计，坚持缺陷的快速处理。

1、 边界测试
边界点就是可能导致被测系统内部处理机制发生变化的点：需求中有利于识别边界点的文字：位置、尺寸、数量、长度、速度、高度、距离、质量、时间·····
一般配合等价类使用
2、 等价类测试
基本原理：根据输入域划分等价类，每个等价类中选择一个作为测试用例；其中3个约束：分而不交、合而不变、类内等价
（1） 如何划分等价类
有效等价类：输入域中一组有意义的数据集合；有效等价类被用于检测系统指定功能和性能能否正确实现
无效等价类：输入域中一组无意义的数据集合；无效等价类被用于检测系统的容错性
注意：两个框要一个正确，一个错误，这样才能准确判断缺陷位置。一定要根据需求判断预期结果。
I．需要考虑的细节：
考虑输入长度
考虑输入类型
组成规则
是否为空
是否区分大小写
是否重复
是否去除空格
II．缺点：没有关注到边界的问题；没有关注到输入框的逻辑关系
（2） 如何设计测试用例
弱覆盖：测试用例应覆盖所有的有效等价类
强覆盖：测试用例应覆盖所有的有效等价类组合
3、 基于场景的测试
找到输入条件；判断是否有效条件；判断是否触发条件；需要取哪些测试数据；得到系统预期输出
主要用来测试业务流程；分为基本流（正确流程）和备选流（错误流程）
注意：还要补充一些异常情况；
冒烟测试中主要使用场景法。
4、决策表（判定表）多条输入，多条输出，输入和输出直接存在逻辑关系
具体做法：条件桩（输入） 条件的组合
动作桩（书橱） 所有结果；动作项： 针对动作桩的取值

	决策表的特性：（1）保证完备（2）消除测试冗余
5、因果图法：
	因——输入条件
	果——输出结果
注意：（1）所有输入/输出条件的相互制约关系以及组合关系（2）输出结果对输入条件的依赖关系，也就是什么样输入组合会产生怎样的输出结果，即“因果关系”
因果图中的基本符号



6、正交测试（试验）：多个选项，都是正值，没有逻辑关系（利用正交工具）
			因子的值两两相交一次（两个因子的值在一个用例中出现两次）

（1） 组成：因素：输入条件S
水平：取值个数g（每个因素的所可取值的数）
考核指标
其中n为试验个数（测试用例个数）

等水平正交表的选择

优缺点：正交测试可以达到100%的成对组合覆盖（高效、经济）
		不足：某些正交表并不存在，无法采用正交表设计满足100%成对组合覆盖的测试用例
		正交表要求各输入条件的取值个数相同，而在成对测试中并没有这个要求

测试方法的选择：

三、白盒测试技术

1）优势与不足
	针对性强，便于快速定位缺陷
	在函数级别开始测试工作，缺陷修复成本低
	有助于了解测试的覆盖程度
	有助于代码优化和缺陷预防
弊端：测试人员需要具备一定的编程经验
	白盒测试工程师需要具备广博的知识面
	成本高
	白盒测试准备时间较长
2）控制流分析技术
	线性结构、条件判定结构、While-do循环结构、Do-while循环结构
	1、关注判定节点固有的复杂性
		焦点：判定表达式
		方法：逻辑覆盖测试
	2、关注判定结构与循环结构对执行路径产生的影响
		焦点：路径
		方法：独立路径产生

3、 关注循环结构本身的复杂性
焦点：循环体
方法：基于数据的静态分析
3）对判定的测试
1、逻辑覆盖：对判定的测试
关注点：判定表达式本身的复杂度
原理：通过对程序逻辑结构的遍历，来实现测试对程序的覆盖
原则：对程序代码中所有的逻辑值，都需要测试真值和假值的情况
语句覆盖是最弱的覆盖准则
局限性：关注语句，而非关注判定节点；对隐式分支无效
对策：优选测试数据；更强的覆盖准则：判定覆盖
2、判定覆盖
设计测试用例时应保证程序中每个判定节点取得每种可能的结果至少一次
边覆盖
3、 条件覆盖
设计测试用例时应保证程序中每个复合判定表达式中，每个简单判定条件的取真和取假情况至少执行一次
4、 判定/条件覆盖
设计测试用例时应满足判定节点的取真、取假分支至少执行一次。且每个简单判定条件的取真和取假情况也至少执行一次
判定覆盖+条件覆盖
5、条件组合覆盖
设计测试用例时应满足每个判定节点中，所有简单判定条件的所有可能取值组合情况至少执行一次
本质：真值表
优势：方法简单
局限性：测试用例太多，冗余严重
6、 修正的判定/条件覆盖
在满足判定/条件覆盖的基础上，每个简单判定都应独立地影响到整个判定表达式的取值
判定覆盖+条件覆盖+独立影响性
实质：利用简单判定条件的独立影响性来消除测试用例的冗余
优势：综合具备条件组合覆盖的优点，有效控制了测试用例数量，消除了测试冗余
不足：测试用例设计较为困难

4）静态白盒测试
	不需要实际运行被测软件，而是直接对软件形式和结构进行分析

（1） 静态结构分析
通过引入多种形式的图表（如函数调用关系图、模块控制图等），帮助我们快速了解程序设计合结构，更好地理解源代码，有利于找到程序设计的缺陷和代码优化的方向。
1、 函数调用层次
层次太深，增大集成测试负担
对栈造成压力，容易导致溢出
控制单个函数的复杂度
高风险节点、调用层次深、缺陷隐藏深、根节点
2、 调用关系
高风险节点
入度越大，缺陷传播速度越快
出度越大，对缺陷的敏感度越度
3、 递归调用

4、 孤立节点
孤立的函数意味着不执行的场景或路径，带表编码或设计的不合理，应尽量避免

四、测试管理及工具

1）缺陷管理
缺陷管理：是在软件生命周期中识别和管理缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失
一般的，需要跟踪工具来帮助进行缺陷的全流程管理

缺陷定义：
1、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好，则是缺陷。
2、软件未达到需求规格说明书中指明的功能，则是缺陷。
检测正常功能、正常流程
检测性能
3、软件出现了需求规格说明书中指明不会出现的错误，则是缺陷
检查异常情况
检查无效用户输入的识别能力
检查无效用户输入的处理能力
4、软件功能超出需求规格说明书中指明的范围，则是缺陷
无意加入，过错缺陷
人为加入，需求缺陷
5、软件未达到需求规格说明书中虽未指明但应达到的目标，则是缺陷
隐含特性，需求缺陷
缺陷管理概述：
1、 缺陷的属性2、缺陷报告3、缺陷跟踪和管理
缺陷属性：可重现性、严重性、优先级（需要在报告中明确体现）、可修复性（不在报告中体现）
测试人员负责的内容：
常见缺陷类型
功能性缺陷、性能缺陷、设计缺陷、接口缺陷、逻辑缺陷、计算缺陷、数据缺陷、用户界面缺陷、文档缺陷、配置缺陷、环境缺陷、兼容性缺陷等等
测试经理/项目经理负责的内容
指定缺陷处理优先级和分配缺陷处理责任人
程序员负责的内容：描述解决方案
（2）软件缺陷的状态
1、提交——测试人员提交了一个缺陷给程序员
2、打开——待处理
3、拒绝——程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4、修复——程序员修复缺陷后提交的一个状态
5、关闭——测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
6、推迟——可以放在后续版本解决的问题，但要详细写出修复日期或版本

五、功能测试与性能测试
1）功能测试（Function Testing）
功能测试主要针对系统的功能需求展开测试，以确认被测系统是否满足用户功能使用要求。
功能测试是系统测试中最基本的测试
1、 功能测试的内容
功能测试用例的设计
结合黑盒测试的基本思想，从：系统输入、系统内部处理、系统输出；展开
2、功能测试的执行：手工执行、自动化执行

2）自动化测试
	是通过测试工具、测试脚本等手段，按照测试工程师的预订计划对软件产品进行自动的测试，从而验证是否满足用户的需要。
	特点：可重复性、可操作性、高效率


3）性能测试
	1、测试环境的搭建：在进行性能测试前，需要完成性能测试的搭建工作，一般包括硬件环境、软件环境及网络环境，可以要求配置开发工程师协助完成。
	2、功能测试与性能测试的区别：性能测试对测试环境的干净、独立性要求更高，更为严格。
	3、性能测试环境包含内容：
		（1）一般web应用系统分为3层架构：表现层（web服务器）、业务逻辑层（应用服务器）、数据层（数据库服务器）
		（2）性能测试环境包含：
				硬件：服务器、客户端、交换机等
				软件：数据库、中间件、被测系统、操作系统
				网络：有线/无线/宽带、网络协议

/4、保证测试环境与真实环境的一致性
硬件环境：包括服务器环境、与网络环境
软件环境：包括版本一致性，场景一致性
5、 根据客户需求调整性能测试环境实施的策略
通过建模的方式实现底端硬件对高端硬件的模拟
通过集群的方式计算

六、单元测试
发现设计或实现中的逻辑错误，及早暴露代码中的缺陷，便于问题的定位和解决
一般以白盒测试为主、结合黑盒测试的方法、允许多个测试单元的测试并行展开
1）单元测试步骤
理解需求和设计、概览源代码、走读代码、设计测试用例、搭建测试环境、执行测试用例、重复进行设计测试用例和加载测试、分析判断，给出结论
单元测试对象——结构化编程（函数、过程）、面向对象编程（类）
2）单元测试必须自动化
1、动态测试
开发测试脚本，一次编写多次运行
目标：代码提交前执行检查
2、 静态测试
开发代码扫描工具，一次配置多次运行
目标：规范开发行为
3）Junit
一个JAVA语言的单元测试框架
@Test断言
@Before，在每个测试用例执行前执行一次
@After。在每个测试用例执行后执行一次
@BeforeClass，在测试类的所有测试用例执行前执行一次
@AfterClass，在测试类的所有测试用例执行后执行一次

测试参数化——构造注入
1、 指定参数化运行器
2、 准备测试数据（构造器注入）
定义参数：定义私有变量，用于保存输出
引入参数：定义带参数的构造方法
准备测试数据：定义一个特殊方法
3、 添加test方法，执行测试

测试参数化——属性注入
@Runwith（Parameterize.class）
@Parameterized.Parameter(属性)
1、 参数化运行器
参数化运行器、org.junit.runners.Parameterized
测试数据准备：构造器注入、属性注入：用属性指定来获取数据集
2、 测试参数化
（1） 指定参数化运行器
（2） 准备测试数据（属性注入）
定义参数：定义公有变量，用于保存输出
引入参数：指定每个属性为参数
准备测试数据：定义一个特殊方法
（3） 添加test方法，执行测试
3、 执行结果：4个测试用例