测试方法
测试方法
文章目录
前言
- 不做文字的搬运工,多做灵感性记录
- 这是平时学习总结的地方,用做知识库
- 平时看到其他文章的相关知识,也会增加到这里
- 随着学习深入,会进行知识拆分和汇总,所以文章会随时更新
- 参考的文章过多,所以参考会写不全,见谅
1.测试方法分类
- 静态测试
- 动态测试
1.静态测试
- 不执行程序的测试方法
- 主要用于测试文档和代码
- 代码也是一种文档
1.1评审
1.含义
- 对产品进行的检查(静态),以确定与计划的计划的结果所存在的误差,并提供改进建议
- 定义了多个角色和一个包括评审会议(review meeting)在内的基本评审过程(review process)
2.过程
- 评审组对选择的评审对象进行评审和讨论
- 需求规约说明书、系统设计、程序代码、用户手册、网页、测试策略、测试计划、测试规约说明书、测试脚本
3.目的
- 在评审过程中去发现评审对象的错误、缺省、不精确处,也包括维护的不完善和接口的错误描述等
- 查找与需求、指南、标准或规定的不符之处、
- 评审的目的不在于解决问题
4.角色
- 作者:写代码的人
这里说的是这种很细小的评审
5.分类
- 文档审查
- 代码审查
- 代码走查
1.文档审查
- 就是看文档里面有没有错别字、排版、标点符号,就是看排版有没有问题
- 文档里的说法和用户要求、开发理解是否一致
2代码审查
1.含义
- 一种同级评审,通过检查文档以检测缺陷,这是最正式的评审技术,因此总是基于文档化的过程
- 列如不符合开发标准,不符合更上层的文档等
2.特性
- 最正式的评审活动
- 由接受过专门培训的主持人(不是作者本人来领导
- 通常是同行检查
- 引入了度量
- 根据入口、出口规则的检查列表和队则定义正式的评审过程
- 会议之前需要进行准备
- 出具审查报告和发现问题列表
- 正式的跟踪过程
- 过程改进和读者是可选的
3.目的
- 发现缺陷
4.方法
- 互查
5.范围
通常合格的代码应具有正确性、清晰性、规范性、一致性和高效性,概括起来,代码审查工作涵盖以下方面
- 业务逻辑的审查
- 算法的效率
- 代码的风格
- 编程规则
3代码走查
1.定义
由文档工作者逐步陈述文档内容,已收集信息并对内容达成共识
2.特性
- 由作者主持开会
- 以情景、演示的形式和同行参加的方式进行
- 开放的模式
- 评审会议之前的准备、评审报告、发现问题清单和记录员(不是作者本人)都是可选的
- 严格按照IEEE 1028要求,准备工作是必须的
- 实际情况中可以是非正式的,也可能是正式的
3.目的
学习、增加理解、发现缺陷
4.优劣
- 优点
- 参加评审的人员只需要较少的准备工作
- 可临时召集(当正规评审有时间压力时可以考虑走查)
- 缺点
- 参加者必须对相关资料非常熟悉、
- 会议比一般的评审时(open end)
- 错误或其他问题可能会被忽略
1.2.可以发现的缺陷
- 引用一个没有定义值的变量
- 从未使用的变量
- 模块和组件支架接口不一致
- 不可达代码(unreavhsble code)或死代码(dead code)
- 违背编程规则
- 安全漏洞
- 代码和软件模型语法错误等
2.静态分析
- static analysis
1.内容
- 符合编程的原则和标准
- 与控制流(control flow)结合
- 控制流分析
- 程序代码复杂度
- 复杂度分析
2.数据流分析
- 使用了从未声明/定义的变量
- 变量声明了没有使用
3.控制流分析
这个不是算法图,只是跟算法有关
- 控制流程图是个带有开始和结束节点的有向图
- 程序的指令(语句是通过节点来表示的)
- 一个没有分支的语句序列可以用一个节点表示
- 语句之间的路径是通过边(控制流)来描述的
- 图内的开始和结束节点可以忽略
[
4.复杂度
-
复杂度分析给出一组能描述程序代码的复杂度特征的度量
(每个公司有它自己的计算方法,具体值是多少算复杂,看公司规定)
- 圈复杂度(cyclomatic complexity)(McCable复杂度)
- 圈数(cyclomatic number) V(G) = e - n + 2p
- e 边数(箭头数)
- 节点数
- 无链接部分的数目(一般 p = 1)
-
计算复杂度
边:17
节点数:13
复杂度(圈数):6 ( 闭合圈数 +1 :此图中有5个圈,完全没有重合的)
5.意义
- 在测试之前尽早发现缺陷
- 通过度量计算,早期警示代码和设计可能存在问题的方面
- 高度复杂性测试
- 可以发现在动态测试过程中不溶于发现的一些缺陷
- 可以发现软件模块之间的相互依赖性和不一致性
- 链接
- 改进代码和设计的可维护性
- 在开发过程中学习经验教训,从而预防缺陷
6.静态分析工具
【oss】开源软件
【proprietary】付费软件
3.动态测试方法
- 通过运行程序来发现缺陷的测试方法
- 黑盒测试
- 白盒测试
3.1黑盒测试
- 功能测试、数据驱动测试、基于规格说明书测试
- 安全测试、互操作测试
- 方法:大纲法、场景法、等价类、边界值、决策表、错误猜测
- 优点:
- 能确保从用户的角度进行测试
- 缺点:
- 无法测试程序内部特定位置
- 当规格说明有误,则不能发现问题
- 不涉及程序的内部结构,如果外部特性本身有问题或者规格说明书有问题,则无法察觉。
- 用于测试非功能性特性
- 可用性、可靠性、稳定性、健壮性、可恢复性
- 可维护性测试
- 易用性测试
- 可移植性、兼容性测试
- 配置测试
- 文档测试
3.2白盒测试
含义
- 结构测试、逻辑驱动测试、基于程序本身的测试、程序员测试
- 需要完全了解程序结构和处理过程,按照程序内部逻辑测试程序,检验程序中每条通路是否按照预定要求工作
优缺点
- 优点:
- 能对程序内部的特定部位进行覆盖测试
- 缺点:
- 无法查出程序内部特性
- 无法对未实现规格说明的程序内部欠缺部分进行测试
设计法
- 以白盒测试为主,并适当结合黑盒测试方法
测试方法
- 逻辑覆盖法
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定-条件覆盖
- 条件组合覆盖
- 路径覆盖法
步骤
- 获得需求、获得 / 画出流程图 / 算法图
- 画出控制流图
- 根据需求来画
- 根据算法图/流程图来画(优先)
- 能清预期结果
- 选择覆盖法设计测试用例
- 用例并不一定能测试出来所有的bug
覆盖方法
逻辑覆盖+路径覆盖
语句覆盖法C0
-
目标
程序中每个可执行语句至少执行一次
-
度量(覆盖率)
- 被执行的语句数/所有可能的语句数(路径可能没走完)
- 被执行的路径数/所有可能的路径数
-
用例
-
能发现语句错误:这个是根据执行结果和预期结果来发现的
-
分支/判定覆盖不能发现逻辑错误或者组合判断中的条件错误
判定/分支覆盖C1
条件组合均取真/假
-
目标
程序中每个判断的取真分支和取假分支至少执行一次
(这个最少需要两个用例,一个用例全都走真/是,一个全都走假/否)
-
用例
- 语句覆盖率
- 路径覆盖率
-
能发现逻辑错误
- 还是通过期望值和实际值的误差
- 不能发现组合判断中的条件错误
条件覆盖C2
原子条件集均取真/假
-
目标
程序每个判断中每个条件可能取值至少满足一次
未必比C1好
-
用例
- 把每个条件判断都给拆开(有and 、or组合的条件判断),构成原子条件集
- 将原子条件集中的每个条件都取真一次、取假一次,可以是全部真/假,也可以两个用例的原子条件集真假交叉
- 两个用例就行了,每个原子条件都是单独的 ,互不关联,没必要用m x n个用例,取过就行
- 区分判定覆盖是整个组合判断都是真假,这个是原子条件一组都是真假(一个用例组都去真,一个都去假的)
-
不能发现逻辑错误
-
使用数轴、集合、图形会更好判断
判定-条件C1+C2
组合判断+原子条件判断 :都各取对错一次,这个最好是在先写C2,再写C1+C2
-
每个条件中的所有可能取值至少执行一次,同时,每个判定的结果至少执行一次
(原子条件集要真假都测试一遍,组合条件也要真假测试一遍)
-
可能导致某些条件掩盖了另一些条件
多条件/条件组合覆盖C3
-
目标
每个判定中的所有条件取值组合至少执行一次
-
比C2全面
-
就是各个原子集真假两两组合
路径覆盖C4
-
目标
用例覆盖程序中的所有可能的执行路径,所有真假什么的两两组合
-
不切实际
- 因为涉及到相当长和几乎无穷尽的路径数
- 人很可能的循环在程序段中都可被视为是可能的路径
-
路径覆盖优化
- McCaBe的基路径方法
- 从源节点到汇节点的显性独立路径数
- 圈复杂度(圈复杂度计算)就是需要设计的用例数目
- 当规模很小时,我们可以直观第标识独立路径
- 表示:path(n):节点 / 边序 ,用例数据
- 确定一个开头和一个结尾,每个用例都要从开头贯穿到结尾
白盒测试工具
- 内存资源泄露工具
- 代码覆盖率检查工具
- 代码性能检查工具
- 静态源代码分析工具