软件测试 第3章静态测试技术
- 格式：doc
- 大小：65.50 KB
- 文档页数：4
软件测试
第3章 静态测试技术
1. 静态测试技术概述
1 概念：
1.1 定义：是指不通过执行被测程序而对软件产品（包括工作产品）进行分析的测试活动
测试对象：需求规约、分析和设计规约、代码街开发过程中的各种文档
1.2 目的：一般是对工作产品进行确认 (例如设计规格说明是否正确实现了所有的系统需求)，并对设计的质量进行验证
1.3 优点：静态测试的成本低，效率高，可以在开发早期发现软件中的缺陷和错误，是有效的测试技术。
2 原则：
2.1 所有违背编码标准的因素都要进行评审，例如标识符如何命名，代码如何缩进
2.2 对代码的复杂度进行评审，
代码要求易简不易繁，提高可读性，便于阅读，代码复杂度要降低
2.3 审查并删除不可用的代码、未被调用的过程和未使用的变量
2.4 报告所有类型的数据流异常
常见的数据流异常
变量在初始化前使用（未初始化就使用），未定义先使用
被赋值的变量一直末被使用：变量是多余无意义
变量在两次赋值之间末被使用：第一次赋值对程序而言是无意义
参数不匹配：如果参数个数，类型，顺序不匹配，函数调用则失败
可疑的类型转换：例如实型数据转为整型，小数会丢失，不为零的数据变为零，造成运算错误
3
静态测试方法分类：
静态测试 人工方法（评审）
由测试人员手工逐步执行所有的活动，并观察每一步是否成功完成 代码检查 桌面检查
代码审查
走查
正规技术评审
自动方法
使用一组测试工具对被测软件进行分析和验证
说明：运行测试工具被测试软件自己不运行而是被测试工具分析，作为测试工具输入源
2. 代码检查
1. 概念：
主要检查代码与设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等
2. 代码检查类型：
2.1 桌面检查
程序员在程序通过编译后，对自己编写的程序代码进行分析、检验，补充相关文档，目的是发现程序中的错误和缺陷
2.2 代码审查
2.3 代码走查
3 代码审查：
3.1 由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静软件测试
态分析
3.2 审查步骤
第一步：准备：事先把审查材料（如设计规格说明、控制流程图、程序文本以及相关的要求和规范）分发给小组成员，准备一份常见的错误和缺陷清单（称为检查表），小组成员充分阅读这些材料
第二步：代码审查会：程序员介绍程序逻辑，审查小组成员提问、讨论、审查错误和缺陷是否存在
3.3 GB/T 15532-2008《计算机软件测试规范》附录A介绍了静态测试方法-代码审查
3.3.1 测试内容：检查代码和设计的一致性；检查代码执行标准的情况；检查代码逻辑表达的正确性；检查代码结构的合理性；检查代码的可读性
3.3.2 组织：由四人以上组成，分别为组长、资深程序员、程序编写者与专职测试人员
3.3.3 过程：准备阶段，程序阅读，会议审查，形成报告
3.3.4 代码审查单内容：寄存器使用，格式，入口和出口连接，程序语言的使用，存储器使用，测试与转移，性能，可维护性，逻辑，软件等
4 代码走查：
4.1 走查是一种非正式评审，被查工作产品的开发者向其他相关人员描述其产品并征求意见
属于一种即兴的审查，如编写了某一代码，直接与其他编程人员讨论，一般准备一组测试用例，人工模拟计算机运行软件；虽然笨拙，但发现错误的概率很高，在发现错误的同时能找到解决的方法。
4.2 代码走查的步骤与代码审查的步骤相似
4.3 走查的参与者模拟计算机运行过程来人工执行少量的、用于人工跟踪的测试用例，其目的是质疑隐藏在源代码之后的逻辑和基本假设
4.4 走查的主要目标是对故障进行检测和文档化，而不是对开发者的能力进行评价
5 走查过程：
5.1 计划走查会议
5.2 走查产品
5.3 走查会议
5.4 解决问题
5.5 记录走查
5.6 返工产品
6 走查类型：
6.1 规格说明走查
规格说明走查包括：系统规格说明、项目计划和需求分析
目标是检查规格说明中存在的问题以及不准确、不清晰和冗长之处
参与者：用户、高级分析员、项目分析员
对象：数据流图、数据字典、实体关系图等
6.2 设计走查
设计走查包括初步设计和详细设计
目标是检查设计结构中的缺陷、薄弱环节、错误和冗余
参与者：用户、分析人员、高级设计师、项目设计人员
对象：结构图、详细设计文档等
6.3 代码走查（使用人工方法模拟计算机运行软件）
目标是检查代码中的错误以及违背标准、不清晰、不一致的地方
参与者：编码人员、项目程序员、设计人员和外部程序员
对象：代码列表、编译器列表等
6.4 测试走查 软件测试
测试走查包括测试计划和测试步骤
目标是检查测试文档中不充分、不完整和不清晰的地方
参与者：项目程序员、测试人员、分析人员和设计人员
对象：测试计划、测试步骤、测试数据示例等
3 代码检查：代码检查的内容事项
检查变量的交叉引用表
检查标号的交叉引用表
检查子程序、宏、函数
等价性检查
常量检查
标准检查
风格检查
比较控制流
选择、激活路径
对照程序的规格说明，详细阅读源代码，比较实际代码与期望代码的差异，从中发现程序的问题和错误
补充文档
3. 正式评审（正规评审）
1 概述：
正式评审在软件开发生存周期中每个阶段结束时实施，采用正式的会议评审方式，通过正式评审的活动标志着该活动到达了一个里程碑，该活动的制品也就成为一个基线；
正式评审也可以在出现严重问题的时候实施
2 两种类型：管理评审和技术评审
a) 项目管理评审的任务是针对适用的项目计划、进度安排、标准和指南进行项目状态的评价
b) 技术评审的任务是举行技术评审以评价正在考虑中的软件产品或服务，并提供相关证据（如它们是完备的、符合标准和规范的等）
3. 正式技术评审内容：
3.1 评审会议
由评审会主席和若干名评审员组成，参加者大多是与评审内容相关的技术专家，参加人员不宜太多，通常为3～5人
必要时(如需求评审)可请用户代表参加 ：是否与用户需求一致
3.2 评审记录
指派专人记录会上提出的所有问题
会议结束后将其整理成一份“评审问题列表”并存档
3.3 评审报告
评审会结束时应形成评审总结报告，总结报告应指明被评审的制品，参加评审的人员，评审中发现的问题以及评审的结论
评审总结报告不必很长(通常一页纸就够了)，而“评审问题列表”可作为评审总结报告的附件
4 正式技术评审过程：
4.1 计划
4.2 预备会
4.3 会前准备（自评审）
4.4 评审会
4.5 修正错误 软件测试
4.6 复审
4.7 复核
5 正式技术评审的指导原则：
5.1 评审产品，而不是评审生产者（对事不对人，不是对程序员的评判）
5.2 制定议事日程且遵守日程
5.3 限制争论和辨驳（主要是发现问题，不是为了解决问题，解决问题应放到评审会以后处理）
5.4 对各个问题都发表见解，但不要试图解决所有记录的问题
5.5 做书面笔记
5.6 限制参与者人数并坚持事先做准备
5.7 为每个可能要评审的工作制品建立一个检查表
5.8 为正式技术评审分配资源和时间
5.9 对所有评审者进行有意义的培训
5.10 评审以前所做的评审
6 正式技术评审的检查表：
6.1 根据不同的评审活动（如软件需求评审、软件设计评审、源代码评审等）设计不同的检查表
6.2 例如，软件设计评审检查表
编号 检查项 是 否
1 设计特征是否与需求一致?
2 设计是否实现了每个程序接口要求的程序行为?
3 是否包含了需要的处理步骤?
4 是否指明了每个决策点的可能结果?
5 是否在设计中考虑了所有预期的情形和条件?
6 是否能确保设计配置变更的完整性?
7 每个程序是否只有一个功能?
8 设计是否具有良好的结构化?
9 是否避免了不必要的设计复杂性和表示方式?
