软件测试
软测review
房老师今年画的重点不是很准,大题3道结果复习的时候和我们说就两道,结果多考了蜕变关系的设计。
源码测试
随机测试
大数定律:测试执行次数够多、测试数据随机生成 → 概率低的偶然现象发生
模糊测试
模糊测试(Fuzzing)是一项通过异常的输入自动化发现待测程序缺陷的技术。主要是AI那个部分的,数据扩增这些。
三要素:一个(套)工具、一个目标、一个循环
工具:模糊器(Fuzzer)
目标:待测程序(PUT)
循环:执行程序、崩溃分派
相关术语
- 模糊是指使用从输入空间(模糊输入空间)采样得到的输入来执行待测程序(PUT,Program Under Test)的过程。
- 模糊器是一个(组)用于实现模糊测试的程序。(核心组件)
- 模糊运动是指一个模糊器按照一组特定的正确性政策在一个给定待测程序上的一次具体的执行。
- 缺陷预言是一个用于确定一次给定执行是否违反具体正确性策略的程序,通常作为模糊器的一部分出现。
- 测试输入是一组用于驱动待测程序执行的数据
- 测试用例=输入+调用序列+预言
- 种子是一个或一组在模糊测试过程中为输入生成(Input Generation)提供基准的测试输入
变异测试
变异体:基于一定的语法变换规则,通过对源程序进行程序变换得到的一系列变体。
等价变异体
重复变异体
蕴含变异体
变异算子
一系列语法变换规则,变异的依据,反映了测试人员关注的缺陷种类。
基本形式:
- 对程序的源代码进行变换(Source Code Level)
- 对程序的编译结果(中间表示)进行变换,例如:针对Java Bytecode的程序变换算子
- 元变异(Meta-mutation)
变异测试假设
- 缺陷是简单的、可模拟的
- 缺陷可叠加
- 缺陷检测有效性
蜕变测试
蜕变关系(Metamorphic Relation,MR)是指多次执行目标程序时,输入与输出之间期望遵循的关系。
随机测试生成大量结果时,无法判断测试用例间的关系。
对程序来说,可以生成大量数据,如何判断数据对错?总不能人工标定。蜕变测试是指多次执行目标程度时,输入与输出之间期望遵循的关系(蜕变关系)比如,sin的蜕变关系:sin(x)=-sin(x + pi),需要注意的是等价关系(关系有大于小于等)。这样就可以起到断言的作用。如果不符合,程序就会有问题(当然,满足也不见得一定对)
设计 MR 关系。
解决测试预言如何获取的问题。
测试预言
测试预言是(自动化)软件测试不可或缺的一部分。
测试预言分类:隐式、显式
- 隐式预言:用于检测显著缺陷的测试预言。例如,预期外的程序崩溃就是一种典型的显著缺陷。
- 显示预言:根据软件的预期功能提取得到的预言,一般用于检测功能性缺陷。
预言问题现状:复杂的预言难以构建,容易构建的预言效果差。
使用不完全测试预言:
- 蜕变测试
- 差分测试
蜕变测试三要素
三要素:
- 蜕变关系(MR):一组待测算法/功能的必要属性,蜕变测试的核心。
- 蜕变集合(Metamorphic Group):由表达了蜕变关系的一组输入组成的集合。
- 蜕变测试过程:应用蜕变关系和蜕变集合进行测试的一般流程。
差分测试
定义:差分测试(Differential Testing)也称为差分模糊测试,是一种常用的软件测试技术,通过向一系列类似的应用程序 (或同一应用程序的不同实现)提供相同的输入,根据这些相似程序执行结果是否存在差异来判定是否检测到缺陷。
通过将同一测试用例运行到一系列相似功能的应用中观察执行差异来检测bug。
基本思想:通过将统一测试用例运行到一系列相似功能的应用中观察差异来检测bug
比如,用不同jvm/编译器执行一段代码,如果不同一定有问题(相同不一定没问题) 测试结果如何判断:知道有错,然后人工去检查
测试用例优先级
回归测试作为一种有效的方法,可有效保证代码修改的正确性并避免代码修改对被测程序其他模块产生副作用。
测试用例优先级(重要)
测试用例优先级(Test Case Prioritization,TCP):通过设定特定优先级准则(执行时间,代码覆盖等),对测试用例进行优先级排序以优化其执行次序,旨在最大化优先级目标,例 如最大化测试用例集的早期缺陷检测速率
优先级排序流程(重要)
特征提取:选择合适的特征表示测试用例
优先级策略:操纵测试用例的特征进行优先级排序
评估准则:选择恰当指标评估优先级排序的结果
特征提取
基于源码特征提取(只有运行缺陷才能检测到)
基于文本特征提取
还有基于缺陷特征提取、基于模型特征提取。
优先级策略
基于贪心的TCP
- 全局贪心策略:每轮优先挑选覆盖最多代码单元的测试用例;多个用例相同随机选择
- 增量贪心策略:每轮有限挑选覆盖最多,且未被已选择用例覆盖代码单元的测试用例;所有代码单元均已被覆盖则重置优先级排序过程;多个用例相同随机选择
PPT上覆盖数组的例题看一下。
复杂度$ O(n^2m)$
基于相似性的TCP
自适应随机策略:每轮优先与已选择测试用例集差异性最大的测试用例。让测试用例均匀地分布在输入域中。
第一张图的表格打错了,t2的s9也是0。
基于搜索的TCP
基于搜索的策略:探索用例优先级排序组合的状态空间,以此找到检测错误更快的用例序列。
基于机器学习的TCP
对测试用例特征进行学习,根据预测的缺陷检测概率进行优先级排序。
- 特征提取:设计并提取测试程序中源码特征。
- 缺陷模型:建立模型预测测试程序检测缺陷的概率。
- 开销模型:建立模型预测测试程序的运行时间。
- 测试优先级:基于单位时间内检测缺陷能力进行优先级排序。
测试用例选择(可能有应用题)
测试用例选择(Test Case Selection,TCS):旨在从已有测试用例集中选择出所有可检测代码修改的测试用例。使用场景:适用于因测试预算不足以致不能执行完所有测试用例的测试场景。
测试用例集约减
评估指标
APFD(重要)
指标:平均故障检测百分比(Average Pecentage of Faults Detected,APFD)
说明:当给定测试用例的执行次序时,该评测指标可以给出测试用例执行过程中检测到缺陷的平均累计比例。
特点:其取值范围介于0-100%之间,取值越高,则缺陷检测速度越快。
移动应用
众包:利用群体力量来完成传统方法中成本高昂或耗时的大规模任务,是Howe Jeff于2006年在美国《连线》杂志上首次提出的一种商业模式。
移动应用众包测试:利用群体力量完成移动应用测试任务。
- 移动应用碎片化问题:品牌、型号、系统、传感器……
- uTest, Testin, Baidu Crowd Test, Alibaba Crowd Test, TestIO, MoocTest
基于图像理解的移动应用自动化测试
移动应用不同终端很难有一个程序能全部测试
如何处理图像、得到控件、得到控件之间的关系、获取文本,这边主要是要了解大概的步骤
- 基于图像理解的移动应用自动化测试
- 能够了解各个任务的难点
- 能够论述各个任务的解决方案
- 核心思想
- 方法步骤
基于图像理解
众包、自动化测试
最核心的是从图像理解这个场景下的业务,通过图像操纵控件。很难有框架能处理所有的终端,但是人可以(ios,安卓),同一个app在不同框架应该提供相同的功能。甚至于,同一类(jd,淘宝),甚至不同类都有很多相似
不会考具体的方法,从宏观上知道如何处理图像,得到什么信息(控件,控件之间的关系,文本)
了解核心思想和方法步骤(比如把文字转为向量,控件也可以转化,包含为1不包含为0)
什么是GUI测试
产品需要服务于用户,提供最好的、正确的用户体验。UI则是用户与界面交互的接口,包含用户所有的感受。
移动应用GUI测试面临巨大的挑战
- 环境碎片化
- 快速演化的开发平台。
必要性
· 增强测试可复用性
• 保证测试的一致性
• 提高测试效率,减少测试开销
• 实现快速的回归测试,加快测试进度
• 实现更广的测试覆盖度提高测试可靠性,避免人为因素
重要
侵入式
Selenium、Appium
Selenium:Web应用测试框架,支持多种浏览器,支持多种语言,依靠WebDriver识别控件 Appium:移动应用测试框架,支持Android/iOS,支持多种语言
自动化测试框架存在的问题:
• 测试脚本的执行依赖于操作系统接口,如 Android 的 ADB
• 定位控件所需信息依赖于移动应用的 UI 层,如 Android 的 XML 布局文件
• 人工编写脚本的时间开销大
• 脚本随应用迭代的可维护性不强
下一步:减少依赖,降低成本,增加可维护性
Sikuli
通过图像匹配算法来完成对GUI元素的识别和定位。
存在的问题:
• 测试脚本的执行仍依赖于操作系统接口,如 Android 的 ADB
• 使用像素级方式定位控件的方式难以应对复杂场景,如不同分辨率的设备
• 仍面临人工编写和维护脚本的成本
下一步:追求对图像更深入的理解
深度图像理解
控件匹配
控件提取
文字识别
界面理解
控件理解
录制回放
自动化探索
局限性
- 无法感知异形屏幕对UI控件的遮挡
- 难以模拟真实场景下人的交互操作
- 仍依赖操作系统接口执行测试操作
非侵入式
机械臂 + AI
- 外置摄像头捕获屏幕,对接实现对屏幕的视觉理解
- AI 算法选择目标控件并生成测试操作
- 调度机械臂执行各种类型的测试操作
- 模拟人为交互,摆脱底层依赖
基于群智协同的众包测试
- 基于群智协同的众包测试
- 能够了解众包的难点
- 能够了解基本的机制(如点赞、点踩机制,机制会考问答或选择)
- 能够了解解决方法
考的少一点,不需要知道的太具体
了解:难点、基本机制、解决方法
基于群智协同的众包测试
知道众包的时候如何协同(难点)
要知道:一般众包纯竞争,如何协作?
一旦找到bug,所有人都要看到,要打破纯竞争下的信息不对成
能力有差异:有的人发现问题快,有的人对问题补充快。引入了点赞点踩的机制要知道
众包:利用群体力量来完成传统方法中成本高昂或耗时的大规模任务。
移动应用众包测试:利用群体力量完成移动应用测试任务。
优势:
- 更充分的测试时间
- 更广泛的测试方法
- 更多样的测试环境
- 更全面的测试方法
缺陷:
- 功能缺陷
- 显示问题
- 性能问题
- 布局问题
- 应用崩溃
- 错误提示
- 空白屏
挑战:
- 任务分配
- 任务奖励
- 众测过程引导
- 测试报告质量控制
对于众包测试存在的问题的解决
协作式众包测试
用户在提交报告时进行实时相似报告推荐,避免重复报告提交(信息共享),推荐待审核报告与待测页面(任务分配),用户承担测试任务也承担审核任务,点赞点踩(协作方式),Fork他人结果进行修改
众测报告质量优化
众测报告信息包括测试截图、文本描述和测试环境信息。
众测报告聚合
众测报告排序:原则是错误越早被发现,补救的成本就越低。
众测报告半监督聚类
众测报告一致性检测
AI测试
AI一
与传统软件测试的区别,与传统软件周期的区别,测试可能的难点(数据纬度高难以理解),测试时应该覆盖什么(神经元覆盖)
模糊测试:
变异算子
基本流程、数据生成、...
AI二
- 图像扩增(可能会放到模糊测试中,也可能考选择或问答)
- 公平性(简单了解)
- 后门攻击(大概了解)
杰哥基本整理了,重点看一下模糊测试任务构建(大题)
- 标题: 软件测试
- 作者: Kiyotaka Wang
- 创建于 : 2024-01-11 09:16:33
- 更新于 : 2024-01-15 13:09:35
- 链接: https://hmwang2002.github.io/2024/01/11/ruan-jian-ce-shi-fu-xi/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。