目录
动态测试
概念
通过运行被测程序，检查运行结果与预期结果的差异， 并分析运行效率和健壮性等性能。
三个组成部分
构造测试用例、执行程序、分析程序的输出结果。
分类
- 从是否关心软件内部结构和具体实现的角度划分
“白盒”测试、“黑盒”测试和“灰盒”测试
- 从软件开发的过程的角度划分
单元测试、集成测试、确认测试、系统测试、验收测试及回归测试
- 从测试执行时是否需要人工干预的角度
人工测试和自动化测试
- 从测试实施组织的角度划分
开发方测试、用户测试(β测试)、第三方测试
白盒测试又称为结构测试或逻辑驱动测试
特点
- 可以构成测试数据使特定程序部分得到测试
- 有一定的充分性度量手段
- 可获得较多工具支持
- 通常只用于单元测试和集成测试(主要是单元测试)
基本测试内容
- 对程序模块的所有独立执行路径至少测试一次
- 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次
- 在循环的边界和运行的边界限内执行循环体
- 测试内部数据结构的有效性
测试方法：
逻辑覆盖（包括语句覆盖、分支覆盖、条件覆盖、分支-条件覆盖以及路径覆盖）
覆盖率
覆盖率=（至少被执行一次的item数）/ item的总数
通过覆盖率数据，可以知道测试的是否充分，测试的弱点在哪些方面，进而指导设计能够增加覆盖率的测试用例。覆盖率是用来度量测试完整性的一个手段。分为逻辑覆盖和功能覆盖两大类。
逻辑覆盖
是以程序内部的逻辑结构为基础的测试方法，属“白盒” 测试。
从覆盖源程序的各个方面考虑，大致可以分为：
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
- 路径覆盖
语句覆盖
语句覆盖是最起码的测试要求。是使每一条语句至少被执行一次。它对程序的逻辑覆盖很少，是很弱的逻辑覆盖标准。
不能发现条件语句错误、逻辑运算错误、循环语句错误。
判定覆盖
判定覆盖又叫分支覆盖，含义是：每个判定的分支至少执行一次。
要求设计做够多的测试用例，使得程序中的每一个分支至少通过一次，即每个语句都取得一次true一次false。对多分支语句，如C语言中的case语句，分支覆盖必须对每一个 分支的每一种可能的结果都进行测试
判定覆盖要比语句覆盖强度大一些。
判断：执行了分支覆盖，实际也就执行了语句覆盖。（正确√）
条件覆盖
即一个判断语句中往往包含了若干条件。通过给出测试用例，使判断中的每个条件都获得各种可能的结果。
这里要注意：判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果
判断：如果满足条件覆盖，一定满足判定覆盖。(错误×二者都无这种关系）
判断/条件覆盖
选取足够多的测试数据，使判断中每个条件都取得各种可能值， 并使每个判断表达式也取到各种可能的结果。
需要设计足够多的测试用例，使得判定中每个条件的所有可 能取值至少能够获取一次，同时每个判断的所有可能的 判定结果至少执行一次。发现错误能力强于分支覆盖和条件覆盖。
注意：有可能不能覆盖全部路径。
条件组合覆盖
使得每个判断中条件的各种可能组合都至少出现一次。
判断：满足条件组合覆盖就满足判定覆盖、条件覆盖、判定条件覆盖。（对√）
注意：并不一定满足路径覆盖。
程序图
给定一个采用命令式程序设计语言编写的程序， 其程序图是一种有向图，其中：节点要么是整个语句，要么是语句的一部分，边表示控制流（从节点i到节点j有一条边,当且仅当对应节点j的语句或语句的 一部分，可以立即在节点i对应的语句或语句的一部分之后执行）。
结构化程序设计基本结构的有向图
DD-路径
结构性测试最著名的形式以叫做决策到决策路径(DD- 路径)的结构为基础。DD-路径指语句的一种序列，从决策语句的“出路”开 始，到下一个决策语句的“入路”结束，在这种序列中没有内部分支。
Miller测试覆盖指标
代码循环结构
路径测试
执行所有可能的穿过程序的控制流程路径。一般来说，这一测试严格地限制为所有可能的入口/出口路径。如果遵循这一规定，则我们说达到了100%路径覆盖率。 在路径测试中，该策略是最强的，但一般是不可实现的。
McCabe度量法
环路复杂性度量-McCabe度量法：基于程序控制流的复杂性度量方法。
环形复杂度计算
在一个强连通的有向图中，环的个数为：
其中： m为图中的弧数， n为图中的结点数，p为图中强连通分量数。
注意：环路复杂度是可加的。
数据流测试
数据流测试主要是为了发现：
- 定义/引用异常缺陷
- 变量被定义，但从来没有使用（引用）
- 所使用的变量没有被定义
- 变量在使用之前被定义两次
方法
- 一种提供一组基本定义和一种统一的测试覆盖指标结构
- 另一种基于叫做“程序片”的概念
定义/使用测试
程序图：
，其中
是程序
:程序中的一组变量
：有一个单入口节点和一个单出口节点，并且不允许有从某个节点到其自身的边
：
中所有路径的集合
节点
是变量
的使用节点，记做
，当且仅当变量
的值在对应节点
的语句片段处使用。
使用节点是一个谓词使用（记做P-use）， 当且仅当语句n是谓词语句；否则是计算使用（记做C-use）
对应谓词使用的节点永远有外度≥2，对应于计算使用 的节点永远有外度≤1
覆盖指标
集合T满足程序P的全定义准则
当且仅当所有变量，
包含从的每个定义节点到的一个 使用的定义清除路径。
集合T满足程序P的全使用准则
当且仅当所有变量，包含从的每个定义节点到v的所有使用，以及到所有后续节点的定义清除路径。
集合T满足程序P的全谓词使用/部分计算使用准则
当且仅当所有变量，包含从的每个定义节点到v的所有谓词使用的定义清除路径，并且如果的一个定义没有谓词使 用，则定义清除路径导致至少一个计算使用。
集合T满足程序P的全计算使用/部分谓词使用准则
当且仅当所有变量，包含从的每个定义节点到v的所有计算使用的定义清除路径，并且如果的一个定义没有计算使 用，则定义清除路径导致至少一个谓词使用。
代码静态审查
静态分析通常是指不执行程序代码而寻找代码中可能存在的错误 或评估程序代码的过程。被测对象是各种与软件相关的有必要测试的产物，如文档、源代码等。通过扫描程序正文对程序的数据流和控制流等进行分析。
- 软件静态分析的作用：
- 使系统的设计符合模块化、结构化、面向对象的要求
- 使开发人员编写的代码符合规定的编码规范
- 通过对代码标准及质量的监控提高代码可靠性
- 尽可能早地通过对源代码的检查发现缺陷
- 组织代码审核定位易产生错误的模块
- 为日后的维护工作节约大量的人力、物力
代码检查内容：
- 完整性检查
- 一致性检查
- 正确性检查
- 可修改性检查
- 可预测性检查
- 健壮性检查
- 可理解性检查
- 可验证性检查
- 结构性检查
- 可追溯性检查
- 代码标准符合性检查
代码编写规则：分为规则和建议
编码规范的内容：
- 格式
- 注释
- 命名——对标识符和文件的命名要求
- 语句、函数和类——对具体程序中的语句、函数和类的 使用要求
- 程序组织
- 公共变量
代码结构分析：程序的理解是程序质量的度量、评估的基础在代码结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构。
530
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
