第10&11次课-静态测试&软件测试规范
静态分析(测试)
1.概述
静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。静态测试具有的发现缺陷早、降低返工成本、覆盖重点和发现缺陷的概率高的优点以及耗时长、不能测试依赖和技术能力要求高的缺点。
2.评审
通用评审过程：
评审活动分6个步骤：计划、概述、准备、检查(评审会议)、返工和跟踪
3.代码检查
代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
4.静态分析技术简介
4.1概述
4.1.1静态分析的对象：源码
静态、动态测试比较
软件测试规范(策略)
一、总则
测试条目
对主要的测试类别都是按
“测试对象和目的”、
“测试的组织和管 理”、
“技术要求”，
“测试内容”、“测试环境”、“测试方法 ”、
“准人条件”、“准出条件”、
“测试过程”和“输出文档”
等条目做出要求。
测试目的
a) 验证软件是否满足…软件质量要求；
b)通过测试，发现软件缺陷；
测试类别
a) 单元测试；
b) 集成测试；
c) 配置项测试（也称软件合格性测试或确认测试）；
d) 系统测试；
e) 验收测试。
可根据软件的规模、类型、完整性级别选择执行测试类别。 回归测试可出现在上述每个测试类别中，并贯穿于整个软件生存周 期。
测试过程
ISTQB：
– 计划与控制 分析与设计 实施与执行 评估出口准则和报告 测试结束活动
测试方法
静态测试方法 静态测试方法包括检查单和静态分析方法．
动态测试方法 动态测试方法一般采用白盒测试方法和黑盒测试方法。
在软件动态测试过程中，应采用适当的测试方法，实现测试目标。
测试用例
– 测试用例设计原则
a) 基于测试需求的原则。
b) 基于测试方法的原则。
c) 兼顾测试充分性和效率的原则。
d) 测试执行的可再现性原则。
– 测试用例要素
测试管理
测试的准入准出条件如下：
– a) 准入条件
1) 具有测试合同（或项目计划）；
2) 具有软件测试所需的各种文档；
3) 所提交的被测软件受控：
4) 软件源代码正确通过编译或汇编。
– b) 准出条件
1) 已按要求完成了合同（或项目计划）所规定的软件测试任务；
2) 实际测试过程遵循了原定的软件测试计划和软件测试说明；
3) 客观、详细地记录了软件测试过程和软件测试中发现的所有问 题；
4) 软件测试文档齐全、符合规范；
5) 软件测试的全过程自始至终在控制下进行；
6) 软件测试中的问题或异常有合理解释或正确有效的处理；
7) 软件测试工作通过了测试评审：
8) 全部测试软件、被测软件、测试支持软件和评审结果已纳入配 置管理。
配置管理
应建立配置管理库，将被测试对象和测试工作产品纳入配置管理。
评审
测试文档
软件测试文档一般包括测试计划、测试说明（需要时进一步细分为 测试设计说明、测试用例说明和测试规程说明）、测试项传递报告 、测试日志、测试记录、测试问题报告（也称测试事件报告）和测 试总结报告，测试文档的基本内容和要求见GB./T 9386。
测试策略：
软件测试充分性准则
二、单元测试(Unit Testing)
1.概述
术语
单元测试：又称模块测试，是针对软件设计的最小单位——程序模 块进行正确性检验的测试工作。
其目的是检查每个软件单元能否正确地实现设计说明中的功能、性 能、接口和其他设计约束等要求，发现单元内可能存在的各种差 错。
测试对象
是可独立编译或汇编的程序模块（或称为软件构件或在面向对象设 计中的类）。
只测单元的内部行为，单元间接口不在此时测
在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离 的情况下进行测试。
技术要求
a) 对软件设计文档规定的软件单元的功能、性能、接口等应逐项 进行测试；
b) 每个软件特性应至少被一个正常测试用例和一个被认可的异常 测试用例覆盖；
c) 测试用例的输入应至少包括有效等价类值、无效等价类值和边 界数据值；
d) 在对软件单元进行动态测试之前，一般应对软件单元的源代码 进行静态测试：
e) 语句覆盖率达到100%；
f) 分支覆盖率要达到100%,
g) 对输出数据及其格式进行测试。 对具体的软件单元，可根据软件测试合同（或项目计划）以及软 件单元的重要性、完整性级别等要求对上述内容进行裁剪。
测试策略
多采用白 盒测试技术为主，黑盒为辅
2.单元测试的内容
总则
– 静态测试 当静态测试时，所测试的内容与选择的测试方法有关。如，采用
代码审查方法，通常要对寄存器的使用（仅限定在机器指令和汇 编语言时考虑）、程序格式、人口和出口的连接、程序语言的使 用、存储器的使用等内容进行检查；
采用静态分析方法，通常要对软件单元的控制流、数据流、接口、 表达式等内容进行分析。
– 动态测试 当动态测试时，通常对软件单元的功能、性能、接口、局部数据结构、独立路径、出错处理、边界条件和内存使用情况进行测 试。
对具体的软件单元，应根据软件测试合同（或项目计划）、软件设 计文档的要求及选择的测试方法确定测试的具体内容。
驱动模块和桩模块
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和
外界的联系，应为测试模块开发一个驱动模块（driver）和（或） 若干个桩模块（stub）。下页图显示了一般单元测试的环境。
驱动模块：用于模拟被测模块的上级模块。在大多数场合称为 “主程序”，它接收测试数据并将这些数据传递到被测试模块， 被测试模块被调用后，“主程序”显示“进入-退出”消息。
桩模块：也称存根程序，用于模拟被测模块的调用模块。
提高模块的内聚度可简化单元测试。
如果每个模块只完成一个功能，所需测试用例数目将显著减少，模 块中的错误也更易发现。
如果一个模块要完成多种功能，可以将这个模块看成由几个小程序 组成。必须对其中的每个小程序先进行单元测试要做的工作，对 关键模块还要做性能测试。
单元测试的考虑
1.模块接口测试
1.1应首先对通过被测模块的数据流进行测试。
只有在数据能正确流入、流出模块的前提下，其他测试才有意义。 测试接口一般应包括以下肉容：
– 调用本模块的输入参数是否正确(参数数目、属性、类型、次序)；
– 本模块调用子模块时输入给子模块的参数是否正确；
– 调用内部函数的参数是否正确；
– 是否修改了只读型参数
– 全局量的定义在各模块中是否一致；
– 在单元有多个入口的情况下，是否引用了与当前入口无关的参数；
– 常数是否当作变量来传递；
1.2如果模块内包括外部输入输出，还应该考虑下列因素：
– 文件属性是否正确；
– OPEN与CLOSE语句是否正确；
– 规定的输入／输出格式说明与输入／输出语句是否匹配；
– 缓冲区容量与记录长度是否匹配；
– 在进行读写操作之前是否打开了文件；
– 在结束文件处理时是否关闭了文件；
– 正文书写／输入错误，
– I／O错误是否检查并做了处理。
2.局部数据结构测试
检查局部数据结构是为了保证临时存储在模块内的数据 在程序执行过程中完整、正确。
局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现 下面几类错误：
– 不正确或不一致的数据类型说明
– 使用尚未赋值或尚未初始化的变量
– 错误的初始值或错误的缺省值
– 变量名拼写错或书写错
– 上溢、下溢（数组越界）或地址异常（非法指针） 除了局部数据结构外，如可能，单元测试时还应该查清全局数据 （例如FORTRAN的公用区）对模块的影响。
3.路径测试
在模块中应尽可能地对每一条独立执行路径进行测试，满 足某覆盖标准。
独立路径是指在程序中至少引进一个新的处理语句集合或一个新条件的任一路径。在程序的控制流图中，一条独立路弪是至少包含 有一条在其他独立路径中从未有过的边的路径。
应设计适当的测试用例，对软件单元中的独立路径进行测试，特别 是对独立路径中的基本路径进行测试。
基本路径指在程序控制流图中，通过对控制构造的环路复杂性分析 而导出的基本的、可执行的独立路径集合。
此时设计测试用例是为了发现因错误计算、不正确的比较和不适当 的控制流造成的错误。
由于不能穷举测试，所以基本路径测试和循环测试是最常用且最有 效的测试技术。
计算中常见的错误包括：
– 死代码
– 误解或用错了算符优先级；
– 混合类型运算；
– 变量初值错；
– 精度不够；
– 表达式符号错。
4.错误处理测试
一个好的设计应能预见各种出错条件，并预设各种出错处 理通路，出错处理通路同样需要认真测试，测试应着重检 查下列问题：
– 出错的描述是否难以理解
– 在对错误进行处理之前，错误条件是否已经引起系统的干预。
– 所提供的差错描述信息不足以确定造成差错的位置或原因
– 显示的错误与实际的错误是否相符
– 对错误条件的处理正确与否
– 意外的处理不当
– 联机条件处理（即交互处理等）不正确
5.边界测试
边界测试是单元测试中最后，也是最重要的一项任务。
6.功能、性能、内存使用
6.1应对软件设计文档规定的软件单元的功能逐项进行测试。
6.2按软件设计文档的要求，对软件单元的性能（如精度、时间、容量 等）进行测试。
6.3检查内存的使用情况．特别是动态申请的内存在使用上的错误（如指 针越界、内存泄露等）。
单元测试的文档
软件单元测试完成后形成的文档一般应有：
a) 软件单元测试计划；
b) 软件单元测试说明；
c) 软件单元测试报告；
d) 软件单元测试记录；
e) 软件单元测试问题报告。 可根据需要对上述文档及文档的内容进行裁剪。
三、集成测试
1.概述
1.1 术语
– 集成测试 也称为组装测试 、联合测试，是将模块按照设计要求组装起来 进行测试，主要目标是发现与接口有关的问题。
– 部件测试 子系统的组装测试特别称为部件测试，它所做的工作是要找出 组装后的子系统与系统需求规格说明之间的不一致。
1.2 测试对象：
a) 任意一个软件单元集成到计算机软件系统的组装过程：
b) 任意一个组装得到的软件系统。
1.3 为什么进行集成测试？
– 一个模块可能对另一个模块产生不利的影响
– 将子功能合成时不一定产生所期望的主功能
– 独立可接受的误差在组装后可能会超过可接受的误差限度
– 可能会发现单元测试中未发现的接口方面的错误
– 在单元测试中无法发现时序问题（实时系统）
– 在单元测试中无法发现资源竞争问题
1.4 集成测试的目的
在模块组装后查找模块间接口的错误
• 模块间数据交换是否丢失、有错（通讯、数据内容、时序等）
• 各个子功能组合起来，能否达到预期要求的父功能；
• 全局数据结构是否有问题；
• 单个模块的误差累积，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行组装测试，发现并排除在模块连接中可能 出现的问题，最终构成要求的软件系统。
1.5 技术要求(可裁剪)
a)应对已集成软件进行必要的静态测试，并先于动态测试进行；
b) 软件要求的每个特性应被至少一个正常的测试用例和一个被认可 的异常测试用例覆盖；
c) 测试用例的输入应至少包括有效等价类值、无效等价类值和边界 数据值；
d) 应采用增量法，测试新组装的软件；
e) 应逐项测试软件设计文档规定的软件的功能、性能等特性；
f) 应测试软件之间、软件和硬件之间的所有接口；
g) 应测试软件单元之间的所有调用，达到100%的测试覆盖率；
h) 应测试软件的输出数据及其格式；
i) 应测试运行条件（如数据结构、输入／输出通道容量、内存空间、 调用频率等）在边界扶态下，进而在人为设定的状态下，软件的功能 和性能；
j) 应按设计文档要求，对软件的功能、性能进行强度测试； k)对完整性级别高的软件，应对某进行安全性分析，明确每一个危险 状态和导致危险的可能原因，并对此进行针对性的测试。
2.集成方式(策略)
通常，把模块组装成为系统的方式有两种：一次性组装方式(big bang，大爆炸)；增殖式组装方式。
2.1一次性组装方式
对所有模块进行个别的单元测试后，按程序结构图将各模块联接起来，把联接后的程序当作一个整体进行测试。
应避免一次性组装方式
最坏情况下，甚至连单元测试都被省略。 使用的必要条件：高度模块化且模块间的耦合极小，且详尽说明了接 口且接口错较少时，可考虑使用一次性组装方式。
2.2增殖式组装方式(又称渐增式组装)
首先对一个个模块进行模块测试，然后将这些模块逐步组装成较 大的系统； 在组装的过程中边连接边测试，以发现连接过程中产生的问题通过增殖逐步组装成为要求的软件系统。
增式测试把单元测试与集成测试结合起来进行，将模块逐步集成起 来，逐步完成集成测试。
实施方法：自顶向下结合 ,自底向上结合, 混合增值式
2.2.1自顶向下增式测试
主控模块作为测试驱动，所有与主控模块直接相连的模块用桩模 块替换，并对主模块进行测试；
根据集成的方式（深度或广度），每次用一个实际模块替换相应 的桩模块；
在每个模块被集成时，都必须已经进行了单元测试；
进行回归测试以确定集成新模块后没有引入错误 上述过程从第2步重复进行，直到整个系统结构被集成完成。
特点：见ppt
2.2.2自底向上增式测试
组装从最底层的模块开始，组合成一个构件，按程序结构向上组装测试后的构件
2.2.3两种实施方法的比较
2.2.4混合增殖式测试
自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
一般来讲，一种方式的优点是另一种方式的缺点。因此，通常是把以 上两种方式结合起来进行组装和测试。下面简单介绍几种常见的综 合的增殖方式：
衍变的自顶向下的增殖测试
自底向上自顶向下的增殖测试
回归集成测试
2.2.5关键模块问题
3.集成测试内容
总则
进行必要的静态测试。
当动态测试时．从全局数据结构及软件的适合性、准确性、互操作 性、容错性、时间特性、资源利用性这几个软件质量子特性方面考 虑．确定测试内容。
全局数据结构
适合性方面
准确性方面
互操作性方面
容错性方面
时间特性方面
资源利用性方面
集成测试实施中的注意点
集成测试完成的标志
文档
软件集成测试完成后形成的文档一般应有：
a) 软件集成测试计划；
b) 软件集成测试说明；
c) 软件集成测试报告：
d) 软件集成测试记录和／或测试日志；
e) 软件集成测试问题报告。 可根据需要对上述文档及文档的内容进行裁剪。
四、确认测试(配置项测试/功能测试)
1.概述
1.1确认测试的任务是验证软件的功能和性能及其特性是否与用户的要 求一致。
对软件的功能和性能要求在软件需求规格说明中已经明确规定。它 就是软件确认测试的基础。
1.2测试对象
是软件配置项。软件配置项是为独立的配置管理而设计的并且能满足最终用户功 能的一组软件。
1.3测试目的
目的是检验软件配置项与软件需求规格说明的一致性。
1.4确认测试包括有效性测试和软件配置审查。
1.5技术要求
2.测试内容
2.1有效性测试（功能测试）
任务： 验证被测软件是否满足需求规格说明书列出的需求。 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。 它包含的信息就是软件确认测试的基础。
2.1.1测试内容
大体可归为界面、数据、操作、逻辑、接口等几方面。
程序安装、启动正常，有相应的提示框、错误提示等
每项功能符合实际要求
系统的界面清晰、美观
菜单、按钮操作正常、灵活，能处理一些异常操作
能接受正确的数据输入，对异常数据的输入有提示、容错 处理等
数据的输出结果准确，格式清晰，可以保存和读取
功能逻辑清楚，符合使用者习惯
系统的各种状态按照业务流程而变化，并保持稳定
支持各种应用的环境
能配合多种硬件周边设备
软件升级后，能继续支持旧版本的数据
与外部应用系统的接口有效
2.1.2有效性测试（功能测试）使用技术
是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试技术： 等价类划分法，边界值分析法，错误推测法，因果图法，组合分 析法
2.1.3有效性测试结果
在全部软件测试的测试用例运行完后，所有的测试结果可分为两类：
1）测试结果与预期的结果相符。 软件 被接受。
2）测试结果与预期的结果不符。
2.2软件配置复查
是确认测试的另一个重要环节，其目的是保证：
3.确认测试完成后形成的文档
a) 软件配置项测试计划；
b) 软件配置项测试说明；
c) 软件配置项测试报告；
d) 软件配置项测试记录和/或测试日志：
e) 软件配置项测试问题报告。 可根据需要对上述文档及文档的内容进行裁剪
五、系统测试
1.概述
1.1测试对象
系统测试的对象是完整的、集成的计算机系统．重点是新开发的软件 配置项的集合。
1.2测试目的
在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或 与之矛盾的地方。
系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用 环境下来运行。
1.3意义
保证各组成部分不仅能单独地受到检验，而且在系统各部分协调工 作的环境下也能正常工作。
1.4技术要求
2.系统测试的内容
GB/T15532-2008中，系统测试内容主要依据GB/T 16260.1规定的质量特性来进行，有别于传统的测试内容，测试内容主要从：功能性、 可靠性、易用性、效率、维护性、可移植性和依从性等方面（可 剪裁）来考虑。
2.1功能性
1 适合性方面2 准确性方面3 互操作性方面4 安全保密性方面
2.2可靠性
1 成熟性方面2 容错性方面3 易恢复性方面
2.3易用性
1 易理解性方面2 易学性方面3 易操作性方面4 吸引性方面
2.4效率
1 时间特性方面2 资源利用性方面
2.5维护性
1 易分析性方面2 易改变性方面4 易测试性方面
2.6可移植性
1 适应性方面2 易安装性方面3 共存性方面4 易替换性方面
以上基于特性的系统测试对应到传统的测试类型一般有：
功能测试、性能测试、负载测试、压力测试（强度测试）、疲劳测 试、易用性（用户界面）测试、安装与卸载测试、配置测试、文 档测试、安全性测试、恢复测试、回归测试、健壮性测试、交付 测试（稳定期测试）、演练测试、背靠背测试、度量测试、比较 测试等。
上述测试最好由第三方进行。
3.文档
系统测试完成后形成的文档一般应有：
a) 系统测试计划；
b) 系统测试说明；
c) 系统测试报告：
d) 系统测试记录和／或测试日志；
e) 系统测试问题报告。
六、验收测试
验收测试概述、目的
• 验收测试与系统测试的区别
• 验收测试的时机、范围
• 验收测试主要内容
• 验收测试过程
• 验收测试形式
七、回归测试
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！