软件测试
• 对用结构化程序语言书写的程序,可以通过使用“控制流覆盖规则”从程序推导出其对应的控制流图
• 数据流测试是面向程序中的变量
• 编码标准一致性检查,主要检查方式
• 目的
• 检查程序是不是按照某种标准或规范编写的。
• 发现程序缺陷。
• 发现程序产生的错误。
• 检查代码是不是流程图要求的。
• 检查有没有遗漏的项目。
• 使代码易于移植,因为代码经常需要在不同的硬件中运行,或者使用不同的编译器编译。
• 使代码易于阅读、理解和维护。
• 目的:发现错误
• ①功能不正确或遗漏了功能;
• ②界面错误;
• ③数据结构错误或外部数据库访问错误;
• ④性能错误;
• ⑤初始化和终止错误。
• 方法
• 等价划分法
• 有效等价类
• 对于程序的规格说明,是合理的、有意义的输入数据构成的集合。
• 无效等价类
• 对于程序的规格说明,是不合理的、没有意义的输入数据构成的集合。
• 边界值分析
• 按照输入值范围的边界
• 按照输入/输出值个数的边界
• 输出值域的边界。
• 输入/输出有序集(如顺序文件、线性表)的边界。
• 错误推测法
• 靠经验和直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的例子。
• 因果图
• 估摸不考
• 逻辑覆盖法(白盒法)
• 语句覆盖
• 使得程序中每个可执行语句至少都能被执行一次。
• 每一个语句都应该做到至少执行一次
• 判定覆盖
• 使得程序中每个判定至少都获得一次“真”值和“假”值。
• 将每个判断语句都至少取得一次真以及一次假
• 条件覆盖
• 使得判定中的每个条件获得各种可能的结果。
• 判定条件覆盖
• 使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果。
• 条件组合覆盖
• 使得每个判定中条件的各种可能组合都至少出现一次。
• 路径覆盖
• 设计足够的测试用例,覆盖程序中所有可能的路径
• 程序插桩技术
• 基本路径法
• 程序中的循环体最多只执行一次
• 程序的每一个可执行语句至少要执行一次。
• 基本可执行路径集合,设计测试用例的方法。
• 符号测试
• 错误驱动测试
• 点覆盖
• 覆盖所有点
• 边覆盖
• 覆盖所有边
• 主路径
• 对产品的各功能进行验证,根据功能测试用例逐项测试,检查产品是否达到用户要求的功能。
• 性能测试
• 目的
• 为了获取或验证系统性能指标。
• 性能基准测试法
• 响应时间
• 并发用户数
• 吞吐量
• 压力测试
• 在保证系统不崩溃的前提下,用于评价系统超过所描述的需求或资源限制时的情况。
• 类别
• 稳定性压力测试
• 高负载下的长时间(如24小时以上)测试
• 破坏性压力测试
• 极限负载情况下导致系统崩溃的测试
• 测试重点
• 发现功能性测试所不易发现的系统方面的缺陷
• 容量测试
• 定义
• 采用特定的手段,检测系统能够承载处理任务的极限值所进行的测试工作。
• 目的
• 分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等)
• 健壮性测试
• 测试重点
• 当出现故障时,系统是否能够自动恢复或忽略故障继续运行
• 目的
• 用于测试系统抵御因“设计缺陷”带来的错误的能力,一是容错性测试,二是恢复性测试。
• 安全性测试
• 定义
• 检查系统对非法侵入的防范能力
• 目的
• 发现软件系统中是否存在安全漏洞
• 内容
• 功能验证
• 采用黑盒测试方法,对涉及安全的软件功能进行测试,验证其功能是否有效
• 漏洞扫描
• 通过使用漏洞扫描器,系统管理员能够发现所维护的信息系统存在的安全漏洞,从而在系统安全中及时修补漏洞的措施。
• 模拟攻击试验
• 设计一组特殊且极端的黑盒测试案例,通常以模拟攻击来验证软件或信息系统的安全防护能力。
• 侦听技术
• 在数据通信或数据交互过程对数据进行截取分析的过程
• 常见的安全测试场景
• 应用程序
• 操作系统
• 数据库
• 网络环境
• 可靠性测试
• 定义
• 是在给被测试系统加载一定业务压力的情况下,使系统运行一段时间,以此来测试系统是否稳定。
•
• 恢复性测试
• 定义
• 检查系统的容错能力;当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。
• 备份测试
• 是恢复性测试的一个补充。目的:是验证系统在发生软件或者硬件失败时备份数据的能力。
• 协议一致性测试
• 协议测试
• 协议测试是一种黑盒测试,它按照协议标淮,通过控制观察被测协议实现的外部行为,对其进行评价。
• 一致性测试
• 测试一个产品在效率或互通性方面是否符合某个指定的标准。
• 兼容性测试
• 定义
• 指检查软件之间是否能够正确地进行交互和共享信息
• 目的
• 待测试项目在不同的操作系统平台上正常运行,包括能在同一操作系统平台的不同版本上正常运行;
• 待测试项目能与相关的其他软件或系统的“和平共处”;
• 待测试项目能在指定的硬件环境中正常运行;
• 待测试项目能在不同的网络环境中正常运行。
• 安装测试
• 不仅需要考虑在不同的操作系统上运行,而且还要考虑与现有软件系统的配合使用问题
• 可用性测试
• 定义
• 是对于用户友好性的测试,是指在设计过程中被用来改善易用性的一系列方法。
• 方法
• 一对一用户测试
• 启发式评估
• 焦点小组
• 配置测试
• 定义
• 验证系统在不同的系统配置下能否正确工作,这些配置包括:软件、硬件和网络等。
• 目的
• 目的就是促进被测软件在尽可能多的硬件平台上运行,有时经常会与兼容性测试或安装测试一起进行。
• 文档测试
• 针对系统提交给用户的文档进行验证,目标是验证软件文档是否正确记录系统开发全过程的技术细节。
• 用户文档
• 开发文档
• 测试方法
• 文档走查
• 数据校对
• 操作流程检查
• 引用测试
• 链接测试
• 可用性测试
• 界面截图测试
• GUI测试
• 定义
• 检查待测试软件的人机界面,通常要检查的部件包括界面布局与色彩、输入输出格式、程度流程和拼写等,以发现其中的人为因素和易用性的问题。
• 指导软件测试
• 促进彼此沟通
• 协助质量管理
• 测试方案的制定
• 测试策略的制定
• 测试计划的制定
• 测试的组织
• 为每个测试过程选择适当的测试用例,准备测试环境和测试工具。
• 将在测试计划阶段制定的测试活动分解,进而细化为若干个可执行的子测试过程,构造出测试计划中说明的执行测试所需的要素
• 记录测试过程中实际的测试设计进度、测试执行进度、测试覆盖率、测试风险等状态和结果;
• 分析测试过程中记录的状态和结果,并与测试计划进行比较。假如两者存在偏离,采取合适的措施和应对计划使之回到测试计划的轨道。
• 对软件错误进行统计,建立统计报告、分析与修改措施系统
• 制定并实施软件错误报告以及可靠性数据收集、保存、分析和处理的规程,完整、准确地记录软件测试阶段的软件错误并收集可靠性数据
• 完成测试计划
• 获取测试集
• 度量测试单元
• 4个关键元素
• 初始状态声明
• 输入数据
• 实际测试的代码
• 期望输出结果
• 集成测试是测试和组装软件的系统化技术,用于测试模块的接口部分
• 确定模块组装方案,将经过测试的模块组装为一个完整的系统。
• 组装方案分为渐增式及非渐增式。
• 以黑盒法为主
• 是发现与接口有关的模块之间的问题。
• 模块间数据是否按预期传递
• 是否存在单元测试时没发现的资源竞争问题
• 是否能实现所期望的父功能
• 是否会对其他相关的模块产生负面影响
• 集成后每个模块的误差是否会累积扩大,是否会达到不可结束的程度
• 非增量式集成测试
• 增量式集成测试
• 自顶向下集成
• 广度优先
• 先上再下,先左在右
• 深度优先
• 先左到右,先上到下
• 自底向上集成
• https://blog.csdn.net/fbvukn/article/details/85853826
• 针对系统中各个组成部分进行的综合性检验,很接近日常测试实践
• 检验软件是否满足功能、性能和行为方面的需求
• 根本任务
• 证明被测系统的功能和结构的稳定性;还要有一些非功能测试:性能测试、压力测试、可靠性测试等等。
• 最终目的
• 是为了确保软件产品能够被用户或操作者接受。通过与系统的需求定义比较,检查软件是否存在与系统定义不符合或与之矛盾的地方。
• 主要目标
• 不再是找出缺陷,而是证明其性能
•
• 完全采用黑盒测试技术
• 验证软件的有效性(验收测试)
• 有效性测试
• 软件配置复查
• 由用户在开发者的场所进行,并且在开发者对用户的“指导”下进行测试。
• 在开发者不能控制的环境中的“真实”应用:由软件的最终用户们在一个或多个客户场所进行。