软件测试期末复习
回归测试
回归测试作为一种有效的方法,可有效保证代码修改的正确性并避免
代码修改对被测程序其他模块产生副作用;回归测试一般占软件产品测试预算的80%以上,占软件维护预算的50%以上
现有用例策略的问题
重复执行已有测试用例
- 用例庞大
- 用例冗余
- 用例失效
- 用例缺失
回归测试优化
- 测试用例修复
- 测试用例选择
- 测试用例扩充
- 测试用例缩减
- 测试用例优先级
随机测试
大数定律:简单地说,就是随着样本数的增加,样本的平均值会越来越接近于期望值

变异测试
变异体
基于一定的语法变换规则,通过对源程序进行程序变换得到的一系列变体
假设:
- 源程序不包括缺陷
- 变异体表达缺陷
变异得分
杀死与存活:变异体是否导致某个测试用例运行失败,即测试用例是否检测到变异体
- 检测到:变异体被杀死
- 没检测到:变异体存活
变异体类别
等价变异体
对于给定输入,两个变异体总是给出相同输出

重复变异体
语义相同
如上也是重复变异体
蕴含变异体
对于两个变体和 ,如果 杀死 的测试用例 都可以 ,则称 蕴含

变异算子
略
测试预言问题
测试预言是自动化测试中不可或缺的部分

什么是测试预言?
- 是文档:体现被测单元的预期功能
- 是机制:验证待测程序的行为是否符合预期
- 是程序:判定程序的执行是否违反了某种正确性政策
- 是约束
- 是映射
断言、神经网络的输出都是测试预言的一种
隐式预言or显式预言
隐式预言检测显著缺陷,显式预言检测功能性缺陷
预言问题
给定系统的输入,如何找到能够正确辨别出符合期望的正确行为与发现潜在的不正确行为测试预言的挑战性难题


差分测试
基本思想:通过将同一测试用例运行到一系列相似功能的应用中观察执行差异来检测bug

定义
一种常用的软件测试技术,通过向一系列类似的应用程序(或同一应用程序的不同实现)提供相同的输入,根据这些相似程序执行结果是否存在差异来判定是否检测到缺陷
流程
利用相似/竞品软件系统进行测试
- 确定一组相似的待测程序
- 生成测试输入和输出
- 正确性验证


应用
- 针对编译器
- 针对调试器
- 针对深度学习框架
- 模糊测试 变异差分(MuFuzz)





蜕变测试
动机
两大测试难题:
- 可靠测试集问题
- 预言问题
本质
充分利用成功测试用例
三要素
- 蜕变关系:一组待测算法/功能的必要属性,核心
- 蜕变集合:表达了蜕变关系的一组测试输入组成的集合
- 蜕变测试过程:应用蜕变进行测试的一般流程




总结
辨析蜕变测试和差分测试




测试用例优先级(重要)
Test Case Prioritization,TCP
通过设定特定优先级准则(执行时间,代码覆盖等),对测试用例进行优先级排序以优化其执行次序,旨在最大化优先级目标,例如最大化测试用例集的早期缺陷检测速率
算法
基于贪心的TCP策略
全局贪心
- 每轮选择覆盖最多代码单元的测试用例
- 多个用例相同则随机选择
增量贪心
- 每轮优先挑选覆盖最多,且未被已选择用例覆盖代码单元的测试用例。(即该覆盖最多指的是覆盖最多新的)
- 所有代码单元均已被覆盖则重置优先级排序过程
- 多个用例相同随机选择

算法流程模拟

- 初始化覆盖矩阵和语句覆盖数组c,所有代码单元均未被覆盖,c为全0数组

- 根据覆盖矩阵和单元覆盖数组 ,计算待排序用例覆盖值,选择测试用例

- 选择测试用例 ,更新语句覆盖数组,以及待排序测试用例覆盖值

- 选择测试用例 ,更新覆盖数组,计算剩余测试用例覆盖新的语句数量

- 选择测试用例 ,更新覆盖数组,计算剩余测试用例覆盖新的语句数量

- 所有语句均被覆盖,重置语句覆盖数组,计算剩余测试用例覆盖值

- 选择测试用例 ,更新覆盖数组,计算剩余测试用例覆盖新的语句数量

- 无待排序用例,排序结束
贪心策略改进——字典排序
选择使得有序覆盖数组的字典序更大的测试用例

基于相似性的TCP策略
原理:故障通常聚集在一起
每轮优先与已选择测试用例集差异性最大的测试用例。让测试用例均匀地分布在输入域中
测试用例距离
首先要会算测试用例之间的距离
设 和 为测试用例 和 所覆盖的代码单元集合,那么这两个测试用例之间的距离计算如下:
然后是测试用例和测试用例集之间的距离计算:分别使用最小距离、平均距离和最大距离度量方式计算待选择用例 与已选择用例集 的距离

算法流程模拟




基于搜索的TCP策略
探索用例优先级排序组合的状态空间,以此找到检测错误更快的用例序列。
步骤
- 种群构造:生成 个测试用例序列,解的编码形式为优先级排序的测试用例编号位置。如初始时对6个测试用例构造2个个体:

- 交叉:使用单点交叉的方式。随机生成切割点,互相交换两个用例序列切割点后部分的片段,仅交换相同测试用例的部分。如个体1和个体2通过交叉算子生成个体3和个体4:

- 变异:对种群中的个体进行基因值的改变操作。以一定概率选择测试用例,并随机生成两个测试用例位置,进行互换,产生新的测试用例序列。如示例对个体1进行变异算子生成新的个体:

-
评估值计算:以语句覆盖为例,给定程序包含 个语句 和 个测试用例 , 为某一次搜索中 的一个优先级序列, 为该测试用例序列 中第一个覆盖语句 的测试用例下标,那么其适应度计算为:
基于机器学习的TCP策略
-
编译器场景中的测试用例优先级
-
对测试用例特征进行学习,根据预测的缺陷检测概率进行优先级排序。
步骤
- 特征提取:设计并提取测试程序中源码特征。
- 缺陷模型:建立模型预测测试程序检测缺陷的概率。
- 开销模型:建立模型预测测试程序的运行时间。
- 测试优先级:基于单位时间内检测缺陷能力进行优先级排序。
APFD(必考)
平均故障百分比 Average Percentage of Fault Detected
其取值范围介于 0~100%之间,取值越高,则缺陷检测速度越快
算法:给定程序包含 个故障 和 个测试用例 , 为 的一个优先级序列, 为该测试用例序列 中第一个检测到故障 的测试用例下标,则该优先级序列 的 值计算公式为
示例:

算法应用
如是说
- 提高缺陷检测效率:在有限的时间内,优先执行那些最可能发现缺陷的测试用例,从而提高缺陷检测的效率。
- 减少测试执行时间:通过根据优先级合理排序测试用例,减少不必要的测试执行时间,节省测试资源。
- 增加测试覆盖率:在资源有限的情况下,优先执行能覆盖更多功能的测试用例,确保关键路径和高风险区域的测试更早完成。
- 应对软件修改后的回归测试:在软件迭代或修复后,通过优先执行与修改相关的测试用例,确保新引入的缺陷能尽早被发现。
实证工作:
- 传统动态排序技术评估
- 真实软件演化评估
- 动态与静态排序技术比较
- 黑盒与白盒排序技术比较
测试用例选择
Test Case Selection,TCS
旨在从已有测试用例集中选择出所有可检测代码修改的测试用例,适用于因测试预算不足以致不能执行完所有测试用例的测试场景
主要方法
- 等价类划分
- 边界值分析
- 决策表测试
- 状态转换测试
- 随机测试
- 覆盖率分析
- 风险分析
- 回归测试
动态静态
- 静态测试用例选择是指在 不执行程序代码 或 不考虑程序实际行为 的情况下,根据事先定义的规则、设计文档、需求文档、或者代码结构来选择测试用例
- 动态测试用例选择则是指根据 程序实际执行情况、程序行为 或 代码执行路径 来选择测试用例。它关注的是程序运行时的行为,包括覆盖不同的代码路径、条件判断、循环等
和测试用例优先级的区别和联系
特性 | 测试用例优先级 | 测试用例选择 |
---|---|---|
定义 | 根据重要性、风险等因素对测试用例进行排序,决定先执行哪些测试用例。 | 从所有可能的测试用例中,依据特定方法选择需要执行的测试用例。 |
侧重点 | 确定测试用例执行的顺序,优先执行最关键的测试用例。 | 确定哪些测试用例应该执行,注重覆盖系统的不同需求或行为。 |
主要目标 | 保证关键、风险高、复杂度高等测试用例优先被执行,以便及时发现潜在缺陷。 | 确保选择的测试用例能够覆盖关键功能、边界情况等,减少冗余并提高测试效率。 |
使用阶段 | 通常在测试计划阶段,确定测试用例执行的顺序。 | 在测试设计阶段,根据具体的选择方法决定哪些用例需要执行。 |
执行顺序 | 通过排序来安排测试用例执行的顺序。 | 通过选择和覆盖策略来确定执行的测试用例。 |
输入依据 | 依据功能的关键性、风险、复杂度等外部因素。 | 依据需求、设计、代码结构或状态转换等选择标准。 |
测试用例优先级 测试用例选择
如上
移动应用中的测试
基于图像理解的自动化测试
流程
(可能不对)
- 捕获屏幕图像:用户首先需要提供一个屏幕上某个元素的截图,这个图像将作为
匹配的基准。 - 编写脚本:在Sikuli 脚本中,用户会指定要在屏幕上查找的图像,以及找到图
像后要执行的动作。Sikuli 脚本使用Python 语言编写,可以很容易地引入图像
并定义动作。 - 图像识别:Sikuli 运行时,会使用计算机视觉算法来搜索屏幕上与脚本中指定的
图像相匹配的部分。它会分析屏幕上的像素数据,寻找与提供的图像相似的区域。 - 相似度阈值:Sikuli 允许设置相似度阈值(通常是一个0到1之间的数),这个阈
值决定了图像匹配的灵敏度。数值越高,要求的匹配度越精确。 - 执行操作:一旦找到匹配的图像,Sikuli 就会在该位置执行用户定义的操作,如
点击、输入文字或者拖拽等。 - 反馈和调整:如果Sikuli 没有找到匹配的图像,或者匹配错误,脚本会报错或
者执行不预期的操作。用户需要根据反馈调整图像或脚本,以确保正确匹配。
难点
略
各任务解决方法
略
众包测试
难点
审查效率问题:
- 大量报告被提交上来,近乎82%的报告是重复的
- 文本问题:同样的问题可以通过不同的描述方法编写
- 截图问题:图片整体UI相似,涉及到bug的部分非常小
研究存在局限性:
- 主要着眼于文本分析理解
- 仅引入简单的截图分析辅助文本
- 简单将文本与图片拼接分析
人员质量参差不齐
测试覆盖不足
缺乏实时监督和沟通
数据隐私和安全问题
测试结果分析
机制
利用群体力量来完成传统方法中成本高昂或耗时的大规模任务
测试流程为:
- 申请上传:用户将自己的应用程序上传到众测平台,并指定相应的测试任务和酬劳信息。
- 任务选择和环境设置:众测人员自由选择他们想要完成的任务。选择后测试人员从平台上下载应用程序进行测试。
- 提交报告:众测人员根据选择的待测应用,对测试到的缺陷提交缺陷报告。
- 生成最终测试报告:平台收集补充信息,生成最终的缺陷报告,包括:一般信息、设备信息、操作路径等。
- 报告验证:客户将验证所有最终的缺陷报告,并决定如何酬劳每个提交报告的众包测试人员。
解决方法
增加测试人员筛选和认证,分配任务时注意匹配
提供测试计划和指导,分阶段测试
使用实时沟通工具
严格的保密协议
自动化测试结果分析,提供标准化报告模板避免混乱
众包测试树
众包测试树
│
├── 测试层次
│ ├── 系统测试
│ ├── 集成测试
│ ├── 功能测试
│ ├── 用户体验测试
│ ├── 回归测试
│ ├── 性能测试
│ └── 安全测试
│
├── 测试类型
│ ├── 功能测试
│ ├── 兼容性测试
│ ├── 本地化测试
│ ├── 冒烟测试
│ ├── 黑盒测试
│ ├── 白盒测试
│ └── 灰盒测试
│
├── 测试资源
│ ├── 外部测试人员
│ ├── 测试平台
│ ├── 测试经理
│ └── 开发人员
│
├── 测试执行过程
│ ├── 任务分配
│ ├── 执行测试
│ ├── 问题反馈与修复
│ └── 持续反馈循环
│
└── 测试评估与分析
├── 测试覆盖率分析
├── 问题优先级排序
├── 质量报告
└── 后期回顾
其他知识点
协作式众包测试,众测报告质量优化,众测报告聚合,众测报告排序(文本理解、图片分析等)(如果是文本理解需要相关文本处理,图片分析需要深度学习)
AI测试
与传统测试区别
- 两者的测试目标不 同。传统软件测试关注待测程序的功能性和性能,而智能软件测试还需在此之上验证待测软 件的准确性、可解释性、是否具有偏见等
- 两者的测试方法不同。传统软件具有黑盒、 白盒、灰盒三种类型的测试方法,而智能软件往往采用黑盒测试方法
测试的难点
- 高质量的测试数据集难以构造;
- 模型的黑盒特性导致无法根据程序的内部状 态来评估测试效果;
- 智能软件中的模型会受到对抗性样本的影响,测试需要确保鲁棒性。
数据扩增
略
模糊测试
基本流程
看课件
数据生成
看课件
结果反馈
看课件
简单应用
看课件