软件评测师：第二篇测试技术

花花柚子

已于 2024-01-19 17:23:22 修改

阅读量1k

点赞数 21

分类专栏：软件评测师文章标签：软件工程功能测试压力测试

于 2024-01-19 16:44:15 首次发布

本文链接：https://blog.csdn.net/weixin_43741194/article/details/134694351

版权

软件评测师专栏收录该内容

3 篇文章 1 订阅

订阅专栏

第5章黑盒测试

5.1 测试用例设计方法

5.1.1 等价类划分法

完全无需考虑程序内部结构，只需分析需求说明书，特别是功能需求。

根据输入域划分等价类，合理假定等价类的代表值等同于对该类其他值的测试。

有效等价类：合理的、有意义的输入数据构成的集合

无效等价类：不合理、无意义

划分等价类的原则：

①取值范围

②特定条件（比如18位身份证号）

③根据已知程序处理方式的不同划分

5.1.2 分类树法

与等价类划分法类似，等价类划分法强调的是同一参数不同子集间的取值，分类树法则是不同参数之间的取值

步骤：

1.识别测试特征集
2.构建分类树
3.确定用例取值
4.导出测试用例

eg.

TCOND1：目的地

TCOND2：舱位

TCOND3：座位 TCOND1：食物偏好食物是否需要再次进行分类？：不划分也可以，因为食物的子集之间不存在重叠的情况。划分也可以，划分出小类是便于更好的去做日后的数据挖掘、程序的使用等。

基于测试特征集、测试条件，生成分类树，将测试条件的输入补充到分类树中。

————————————————

原文链接：15.4 - 分类树法-CSDN博客

5.1.3 边界值分析法

在任何情况下都必须使用边界值法

转载自：解析边界测试技术——健壮性测试、最坏情况测试、健壮最坏情况测试-CSDN博客

①边界条件：如输入范围

②次边界条件：程序内部逻辑，如2的次方，ASCII编码

③其他：如空值

5.1.3.1 基本边界值测试

n为区间数

用例数：4n+1

在数据有效区内取最大值、略小于最大值、正常值、略大于最小值和最小值

5.1.3.2 健壮性测试

用例数：6n+1

在边界值基础上，增加超过最大值（max）和略小于最小值（min）时的情况

5.1.3.3 最坏情况测试

用例数：5n

在基础边界值的基础上，对不同变量作笛卡尔积

5.1.3.4 健壮最坏情况测试

用例数：7n

在健壮性测试的基础上，对不同变量作笛卡尔积

5.1.4 语法测试

目标：

正面测试：覆盖有效语法
负面测试：故意违反规则语法

语法	至少导出用例数	导出用例类型
强制选择	n	对于每个备选项导出一条用例
强制迭代	2	1.最小迭代次数 2.大于最小迭代次数
迭代具有最大次数限制	2	1.最大迭代次数 2.大于最大迭代次数
任意输入	1	“变异”无效输入

测试原则：

1.语法强制选择时，对于每个选择导出1个用例
2.语法强制迭代时，导出2个测试用例，1个最小迭代次数，一个大于最小迭代次数
3.语法具有最大重复次数时，导出2个用例，1个最大重复次数，一个大于最大重复次数
4.对于任意输入，导出至少1条无效输入（变异）

5.1.5 组合测试

目的：在保证错误检出率的前提下采用较少的测试用例，将被测软件抽象成一个受到多个参数影响的系统，并通过被测软件的参数和参数可取的值，按照组合策略来规划测试

5.1.5.1 单一选择

概念：所选参数取值范围的任意可能取值至少被一个测试用例覆盖

用例数：被测对象最多取值数

5.1.5.2 基本选择

概念：对于任意一个参数的两个取值，存在两个测试用例覆盖这两个取值，且其他参数的取值相同。

用例设计：先变化一个参数的取值进行测试，直到这个参数的所有可能取值都被覆盖到，再只变化另一个参数进行测试。

用例数：被测对象取值数之和-被测对象种类+1

5.1.5.3 成对组合

概念：被测软件中的任意两个参数的取值范围的任意一对有效取值至少被一个测试用例覆盖

用例设计：设计测试用例时，先根据取值数最多的两个被测对象取值测试，然后补充上其他测试条件的不同取值

用例数：被测对象中取值数最多的两个数相乘

5.1.5.4 全组合

概念：所有参数取值范围的任意有效取值的组合至少被一个测试用例所覆盖

用例数：全部被测对象的取值数相乘

5.1.5.5 K强度组合

概念：在组合要求为K的组合中，任意K个参数取值范围的任意有效的组合至少被一个测试用例覆盖

分类：

K=1：单一组合
K=2：成对组合
K=K：娶亲组合

用例数：被测对象中前K个取值数最多的数相乘

5.1.4 错误推断法

基于经验和直觉让推测程序中可能有的和容易发生错误的特殊情况。

5.1.5 因果图

Ci 表示原因，Ei 表示结果

（1）基本图形符号

恒等。若原因出现，则结果出现；若原因不出现，则结果不出现。
非。若原因出现，则结果不出现；若原因不出现，则结果出现。
或。若几个原因中有一个出现，则结果出现；若几个原因均不出现，则结果不出现。
与。若几个原因都出现，结果才出现；若几个原因中有一个不出现，则结果不出现。

（2）限制关系图形符号

限制关系图形要么在因（输入条件）之间，要么在果（输出结果）之间。

从原因方面考虑主要有4种约束条件：

E(互斥、排他)。a、b两个原因不会同时出现，最多只有一个出现。
I(包含、或)。a、b、c三个原因至少有一个出现。
O(唯一)。a、b两个原因必须有一个出现，且仅有一个出现。
R(需求)。a出现时b必定出现。

从结果方面考虑主要有1种约束条件：

M(屏蔽)。a出现时，b必定不出现；a不出现时，b则不确定。

因果图一般要转化成判定表才能作为确定测试用例的依据

5.1.6 判定表法

组成：

条件桩	条件项	条件组1	条件组2
动作桩	动作项	（0/1）	（0/1）

用例数：对于n个条件，有2^n个用例

eg.

购买电影票

(31条消息) 软件测试学习——判定表法软测判定表侯清尘的博客-CSDN博客

条件桩：（1）刷华夏信用卡（2）周三下午（3）情侣动作桩：（1）电影票8折（2）电影票7折（3）电影票5.6折（4）女生免票

条件桩
刷华夏信用卡 0 0 0 0 1 1 1 1
周三下午 0 0 1 1 0 0 1 1
情侣 0 1 0 1 0 1 0 1
动作桩
电影票8折 √
电影票7折 √
电影票5.6折 √
女生免票 √ √ √ √
全票 √

可见，如果有n个条件，每个条件都有（0,1）两种取值，那么一共就会有2^n 种取值

条件桩
刷华夏信用卡	0	0	0	0	1	1	1	1
周三下午	0	0	1	1	0	0	1	1
情侣	0	1	0	1	0	1	0	1
动作桩
电影票8折					√
电影票7折			√
电影票5.6折							√
女生免票		√		√		√		√
全票	√

5.1.7 正交试验法

背景

全面试验法：对于所有条件，均匀取点并排列条件

缺点：条件较多时，用例数庞大

简单对比法：固定一组条件，只改变一个条件进行对照试验

缺点：结果缺乏代表性，试验数据存在误差，结果不稳定（比如当结果是曲线的时候，根据简单对比法可能得出一条简单的直线）

正交试验法

5.1.8 功能图法

本质是黑白盒的混合方法，涉及的逻辑覆盖和路径测试属白盒方法，但此处仅在功能或系统层面进行分析，不涉及到程序内部

功能图包括动态说明和静态说明

动态说明

描述输入数据的次数或转移的次序

静态说明

描述输入条件和输出条件的对应关系

5.1.9 场景法

基本流：黑直线表示，最主要的流程

备选流：其他可能的情况

可根据场景图输出用例流

基本流	开始状态
	状态步骤1
	状态步骤2
	结束状态
备选流1——XXX	在基本流步骤1中如果XXX，则……
备选流2——XXX	在基本流步骤2中如果XXX，则……

转测试用例

如上图，V表示执行基本流的必要条件，I表示该场景下被激活的备选流，n/a表示条件不适用。

5.1.11 测试方法选择的综合策略

①等价类划分。减少工作量

②边界值分析。任何情况下都必须使用（并不，哈哈哈，有时候无法达到边界值）

③……

第6章白盒测试

6.1 白盒测试技术

6.1.1 词法分析与语法分析

就是编译原理里面的概念，通过词法分析和语法分析得到一些关于关键数据表：

标号交叉引用表

标号是汇编中的概念，标号属性有段基地址和偏移地址和类型属性（指示距离，如SHORT，NEAT，FAR），一般用来跳转到程序的某一位置，如无条件转移指令和循环指令
变量交叉引用表
子程序、宏、函数定义表
等价表
常数表

6.1.2 静态错误分析

确定源程序中是否存在某种错误或危险结构

① 类型和单位分析：对如数组下标、循环内计数器等特殊类型针对性检查

② 引用分析：采用深度优先算法遍历程序的路径，检查是否存在未复制就被引用，或赋值后未被引用的情况

③ 表达式分析：括号、下标越界、浮点数计算误差等

④ 接口分析：检查实参类型、数量、维数、顺序和使用在模块之间接口和模块与外部数据库之间接口的一致性

6.1.3 程序插桩技术

比如，插入输出语句和计数语句，检查程序执行的路径和执行过程中变量的值的变化等情况。

此外，还可以插入断言语句，比如如果正确执行了n=m-1，那么一定有n<m，这就可以作为断言的依据。

6.2 白盒测试方法

6.2.1 静态测试技术

6.2.1.1 代码检查法

包括：

① 桌面检查：程序员在编译之后对程序进行的分析检验

② 代码审查：由程序员和测试员组成小组，组织审查会议，由程序员负责逐句讲解程序逻辑，其他成员展开讨论

③ 走查：根据材料测试员提前准备测试用例，会议上根据程序的逻辑，人工模拟计算结果，从而对程序的逻辑、功能展开讨论。

代码检查工具：C++Test

(31条消息) C++Test使用入门_cinco?的博客-CSDN博客

6.2.1.2 静态分析法

测试员通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口和内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表等。

① 函数调用关系表：检查函数调用层次是否过深、有无没被调用的函数等

② 控制流分析：类似程序流图，反应函数的内部逻辑

工具：Logiscope，举例可发现的错误：多个函数出口可能导致内存泄漏、过多的逻辑判断回降低程序的可靠性和影响运行性能、孤立出口的死代码等。

控制流图与基本路径测试步骤

（1）绘制程序流图和控制流图

（2）计算控制流图G的环路复杂性V（G）

计算独立路径数量，一条独立路径是至少包含一条在其他独立路径中从未有过的边的路径

V（G）=边数e-节点数n+2*连接组件数p

对于连通图而言， p=1，则有：

V（G）=边数e-节点数n+2

V（G）=判断结点数+1

V（G）=闭合区域数+1（外部区域数）

（3）计算先行无关路径的基本集

（4）生成测试用例，确保覆盖基本集中的所有路径

③数据流分析：“定义-使用对”，考虑数据定义、使用和撤销的顺序

④接口分析：

⑤表达式分析：

6.2.2 动态测试

6.2.2.1 基于控制流设计测试用例：逻辑覆盖法

满足条件覆盖或判定覆盖不一定满足语句覆盖、判定覆盖

满足判定条件组合覆盖一定满足语句覆盖、判定覆盖和条件覆盖

以最简单的例子

func(int a,b,c,x){
x=0;
if (a) && (b||c):
	x=1;
return x;
}

① 语句覆盖（SC）：北侧程序中每条语句都要被遍历到

取a，b，c=1一次执行即可满足

② 分支测试：北侧程序中每个分支都要被遍历到，哪怕分支中没有语句

a,b,c=1：执行一次结果为真

a,b,c=0：执行一次结果为假

③判定覆盖（DC）：程序中每个判定结果为“真”和为“假”的分支都至少执行一次

a,b,c=1：执行一次结果为真

a,b,c=0：执行一次结果为假

④条件覆盖（CC）：被测程序中每个判定语句的每个判定条件的取值至少满足一次

第一组：a=1,b=0,c=0；a=0,b=1,c=1 满足条件覆盖不满足判定覆盖

第二组：a,b,c=1；a,b,c=0 满足判定覆盖和条件覆盖

⑤分支条件覆盖（CDC）：判定中每个“真”“假”可能都出现至少一次，且判定结果的“真”、“假”也至少出现一次

第二组：a,b,c=1；a,b,c=0 满足判定覆盖和条件覆盖

⑥ 分支条件组合覆盖（MCC）：每个判定条件中所有可能的组合都至少出现一次

如例子中有三个变量，2个水平，则有23=8种组合

⑦ 修正条件判定覆盖（MCDC）：

每个程序模块的入口出口都至少调用一次

对于每个条件X，存在一下两次计算

除条件X外，其他条件在两次计算中保持不变（对照试验）
条件X分别取到“真”“假”两个值
两次计算中判定计算结果相反，仅由“X”条件的改变而改变

对每个条件根据上述规则得到的用例组成的集合，满足修正条件判定覆盖

修改条件判定覆盖必然满足判定覆盖和条件覆盖，是条件组合覆盖的子集

6.2.2.2 基于数据流设计测试用例

6.2.6 其他白盒测试方法

（1）域测试：将程序分为域错误、计算型错误、路径丢失错误

域错误：对于输入，执行了错误的路径，比如IF数据输入真值进入了判断为假的路径

计算型错误：对于数据的处理输出了错误的结果，比如本来输入2应该执行2*10，结果却是210=1024

路径丢失错误：缺少判定谓语（不理解......），大概就是比如只有IF为真的路径，对于为假没有处理这种吧，又或者本来应该判断IF的两个and，现在只有一个and

（2）符号测试：程序允许符号输入（这里的符号包括变量），通过对符号的测试代替一类普通测试的结果

（3）Z路径测试：舍弃部分次要因素，简化循环的路径覆盖称为Z路径覆盖

（4）程序变异：错误驱动测试，缩小错误的搜索范围，集中在某类错误是否存在

第7章面向对象的软件测试技术（第一版内容）

Object-Oriented Software 简称OO

7.2 面向对象技术

类：对对象的抽象

对象：类的实例

7.3 面向对象测试模型

(33条消息) 软件测试 | 期末复习——面向对象的软件测试面向对象的单元测试微拂素罗衫的博客-CSDN博客

面向对象开发的三个阶段：面向对象分析、面向对象设计和面向对象编程

面向对象分析测试、面向对象设计测试：开发前期的关键测试，对文档进行测试

面向对象编程测试：对编程风格和代码实现进行测试

面向对象单元测试：对类对象的成员函数进行测试

面向对象集成测试：系统内部的相互服务，如成员函数建的相互作用，类间的消息传递

面向对象确认和系统测试：以用户需求为测试标准，借鉴OOA和OOA Test

7.4 面向对象软件的测试策略

7.4.1 面向对象分析的测试

OOA：Object Oriented Analysis

（1）对对象的测试：

全面定义
区别于其他对象的共同属性
对象内具有相同的服务，不同服务的要有多态
对象的名称准确合适

（2）分类结构的测试：

上层能否派生下层
下层能否抽象上层
上层能否体现共性
下层能否体现特殊性

……

（4）对定义的属性和实例关联的测试

（5）对定义的服务和消息关联的测试

7.4.2 面向对象设计的测试

OOD：Object Oriented Design

OOD是OOA的进一步细化和更高层的抽象，两者界限难以严格区分（那就是没必要分太细呗）

（1）对认定类的测试

（2）对结构的类层次结构的测试

（3）对类库支持的测试

7.4.3 面向对象编程的测试

OOP：Object Oriented Programming

（1）数据成员是否满足了数据封装的要求

（2）类是否实现了要求的功能

7.4.4 面型对象的单元测试

OO Unit Test

传统的单元测试方法仍适用，需要注意的内容有：

选取输入数据：

对某一类输入中的数据能正确执行，那同类中其他的输入也能正确执行
对某一复杂度的输入能正确执行，那更好复杂度也能正确执行

对于继承，需重新测试的有：

继承的成员函数在子类中有改动
继承的成员函数调用了子类中有改动的成员函数

7.4.5 面向对象的集成测试

由于OO程序类的联系密切，无法在编译不完全的情况进行测试，一般是在编译完成后进行黑盒集成测试

基于线程的测试：按照系统完成回应某一输入或事件所需的类进行划分，每个线程分别测试
基于使用的测试：从不需要服务器类的类独立类开始构造，到需要使用独立类的类依赖类，直到构造完整个系统，一般尽量不使用驱动模块和桩模块

7.4.6 面向对象的确认和系统测试

在系统层次上，和一般的软件确认和系统测试，无太大区别，类连接的细节消失了，传统的黑盒测试可被用于驱动有效性测试。测试的内容包括功能测试、强度测试、性能测试、安全测试、恢复测试、易用性测试、安装/卸载测试

7.5 面向对象软件测试用例设计

基于故障的测试：分析模型考虑可能出现的故障（实际就是错误推断法）

考虑如功能未实现或超出要求、子系统间交互
基于场景的测试：从用户任务考虑用户可能执行的操作来设计测试用例
随机测试：当一个类有多重操作序列时，选取随机操作序列进行测试

第8章应用负载压力测试

8.1 概述

8.1.1 概念

负载压力

系统的负载压力是指系统在某种指定软件、硬件以及网络环境下承受的流量

如并发用户数、持续运行时间、数据量

负载压力测试

关注不同负载场景下的相应时间以及会出现的问题（速度变慢、内存泄漏等）

负载测试和压力测试的区别

负载测试关注的是在满足性能指标的情况下系统的最大负载，而压力测试是确定在什么负载下系统会失效。

疲劳强度测试

系统稳定运行下能支持的最大并行用户数或日常用户数量，持续执行业务，观察执行指标和资源监控指标，确定系统处理最大工作量的强度性能指标

8.1.2 负载压力测试目的

在真实环境下检测系统性能、评估系统性能和服务等级

包括量级、在速度受影响时服务的优先级等
预见系统负载压力承受力

使系统的性能指标与实际使用相贴合，既不浪费也能保证使用体验
分析系统瓶颈、优化系统

对于测试工程师而言，处理的优先级：应用软件瓶颈>数据库、操作系统瓶颈>硬件瓶颈

8.1.3 测试工具

分类	软件
商业软件	LoadRunner
	QALoad
开源软件	OpenSTA	脚本控制语言SCL，用于测试Web应用
	TestMaker	基于Java架构，跨平台，Jython语言（Python的Java实现）
	JMeter	纯Java，跨平台，可测试Java对象、JDBC、数据库
自研软件

同样的，性能测试也贯穿软件生命周期，从需求设计到运维

8.2 负载压力测试解决方案

详解并发测试、疲劳强度测试、大数据量测试

8.2.1 并发性能测试

1、应用在客户端的测试

主控台、负载生成、服务器

测试目标：虚拟用户数、每秒点击数、每秒事务数、事务响应时间

一个Vuser组可以存放多个Vuser，可以指定不同组的Vuser在某一个集合点同时执行不同的操作（组内执行同一个操作）来测试负载峰值

2、应用在网络上性能的测试

应用网络故障分析

Agent Manager 分析 Agent（捕捉点）
网络应用性能监控

3、应用在服务器上性能的测试

即监控服务器，包括操作系统、数据库以及中间件

8.2.2 疲劳强度测试

1、日常业务疲劳强度模拟

长时间运行日常业务，用于发现内存泄漏、资源争用等问题

2、高峰业务疲劳强度模拟

时间长，业务多且集中

8.2.3 大数据量测试

1、独立数据量测试

单用户大数据量，如文件上传下载，增删查改，批处理任务等

2、综合数据量测试

并发数和大数据量综合调配，采用并发测试、疲劳强度测试以及大数据量测试相结合的综合测试方案

8.3 负载压力测试指标

客户端交易处理性能指标
服务端资源监控指标
数据库资源监控指标
Web服务器资源监控指标
中间件监控指标

服务器监控内容：

磁盘管理
文件系统
内存
CPU

数据库资源监控：

监控超出共享内存缓冲区的操作数
扩展的会话/用户检查以及参数控制
磁盘

8.4 负载压力测试计划

度量最终用户响应时间
定义最优的硬件配置
检查可用性
查看硬件或软件升级
评估新产品
确定瓶颈
度量系统容量

测试工具：QALoad（美国）、LoadRunner（美国）

“真实的环境”强调的是服务器、数据库、中间件的真实，同时要有一定的数据量

测试协议的选择：

客户端与直接压力承受的服务器之间的通信协议是选择测试协议的唯一标准

8.4.10 结果评估与测试报告

1、性能评估

并发用户数
交易响应时间
交易通过率
吞吐量
点击率

2、资源占用

8.5 负载压力测试技巧

8.5.1 参数化

可以从文件或数据库中读取数据进行替换参数

第9章 Web应用测试

9.1 Web 系统测试概述

9.1.2 Web系统设计技术

ASP、JSP、J2EE、.NET

9.2 Web应用设计测试

9.2.1 总体架构

1、客户端是否执行部分业务逻辑

2、Web架构的组层是否满足需求

包括Web应用服务器、中间件和安全服务器等

9.2.2 客户端设计的测试

3、功能设置的测试

功能设置是否合理

4、信息组织结构的测试

包括线性组织信息与非线性信息展示，是否容易找到信息等

5、页面设计的测试

一致性、用户友好、兼容性

9.2.3 服务端的测试

6、容量规划的测试

点击率、延迟、流量

7、安全性

加密技术、防火墙

8、数据库设计

9.3 Web应用开发测试

9.3.2 代码测试

1、源代码规则分析

检查语法和拼写，和白盒测试差不多吧

2、链接测试

链接正确、可达（无孤立链接）

3、框架测试、表格测试、图形测试

大小、滚动条、嵌套

9.3.3 组件测试

表单（Forms）测试、Cookies测试、脚本测试、CGI测试ASP测试、ActiveX控件测试

9.4 Web应用运行测试

功能测试
- 客户端的选择：操作系统和浏览器
- 客户端浏览器的配置
- 客户端的显示
- 内容测试：链接检测(Xenu)、功能自动化测试
易用性测试
- 界面测试
- 辅助功能测试：说明、导航、站点地图、帮助
- 图形测试
负载压力测试
- 并发用户数
- 交易响应时间
- 交易通过率
- 吞吐量
- 点击率
客户端配置与兼容性测试
安全性测试
- 部署：通信安全、防火墙、远程应用服务器设置、信任级别
- 输入验证：SQL注入、XSS、缓冲区溢出等
- 身份验证：是否受限访问、账户权限要求、验证调用者身份
- 授权：防御策略、授权方式、限定系统资源限制（最低权限）
- 配置管理：远程连接、强身份验证、加密通信、配置安全、权限隔离
- 敏感信息：机密信息加密、保存机密信息地方、密钥安全性、是否几率敏感信息
- 会话管理：是否加密会话标识符和cookie
- 加密：加密算法、密钥大小、密钥的安全性
- 参数处理：程序所有的输入参数，不光是用户输入的
- 审核和日志文件：需要审核的活动、审核日志的同步、日志的管理保护