DUG软件测试基础知识.ppt

Hansky Training Class Manual Module 2. 软件测试技术 主要内容 软件测试基本方法 静态分析 白盒测试 黑盒测试 测试模式 范围测试 说明书测试 风险测试 情景测试 组合测试 探索测试 实际练习 什么是静态分析？ 不实际运行程序，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。 作用 通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块 非常有效的质量保证手段 越来越多地被采用 静态分析的主要内容 检查需求 检查设计 检查代码 检查需求 需求的标准 完整性 是否完整描述一个功能 正确性 是否正确反应客户要求 可行性 必要性 Gold plating? 无二义性 会引起歧义吗 可验证性 测试用例怎么写？ 实施无关性 需求规格说明的标准 完整性 是否包含所有需求 FURPS 一致性 相互矛盾 重复 需求检查练习 例1　产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于60秒。 完整吗？ 清晰吗？ 例2　分析程序应该能生成HTML标记错误的报告，从而使HTML初学者可以用它来快速排错。 是否有歧义？ 可验证吗？ 例3　如果可能的话，应当根据系统货物编号列表，在线确认输入的货物编号。 “如果可能的话”是什么意思？ 需求检查练习 例4　产品不应该提供将带来灾难性后果的查找和替换选择。 真正的需求是什么？ 例5　系统对标准XYZ 1.4.1的支持是可选的。 有歧义吗？ 例6　当用户选择“紧凑内存”选项时，程序通过Huffman解析矩阵方法将邮件列表数据压缩到相应的大小。 可测吗？ 代码无关吗？ 规格说明用语清单 绝对的肯定 总是、每一种、所有、没有、从不 注意隐含的假设 当然、因此、显然、必然 模棱两可的词 某些、有时、常常、通常、经常、太多、几乎 不可测的描述 良好、迅速、廉价、高效、稳定 隐藏的需求 已处理、已拒绝、已忽略、已消除 缺少的分支 如果…那么…（没有“否则…”分支） 检查设计 在编码开始前进行 检查功能设计说明，消除歧义 功能的用意、总体位置 输入、输出 可能的错误/例外 接口定义 交互细节 实施建议 检查代码 通过检查代码发现模块中的错误 检查代码 研究分析代码而不用实际执行 包括可执行的代码和非执行的代码 提供的信息 度量标准 容易产生错误的代码 代码规则的执行 流图和调用图的分析 度量元 复杂度度量 McCabe Halstead 嵌套级别(最大/平均) 规格度量 行数 语句数 注释数 声明数 …… 代码审核内容 分析容易产生错误的代码: 控制流分析 非结构化的代码 死代码 数据流分析 未定义的数据的使用 未使用的数据 信息流分析 断言分析 代码审核内容 流图和调用关系图 作为理解代码的帮助 作为审核符合设计的帮助 作为测试设计的帮助 作为调试的帮助 代码规则的执行 针对不同语言的特征 格式和形式 命名规范 度量标准的强制 静态分析方法 审查：Inspection 走查：Walkthrough 自动化工具 走查（Walkthrough） 开发组内部进行的 采用讲解、讨论和模拟运行的方式查找错误的活动 限时 - 避免跑题 参加人员 经验丰富的开发人员 和本模块相关的开发人员 本项目组的新人 由本模块的开发者进行讲解、回答问题并记录 不要现场修改 检查要点 逻辑错误 代码标准/规范/风格 审查（Inspection） 开发组、测试组和相关人员(QA、产品经理等)联合进行。 采用讲解、提问并使用Checklist方式进行的查找错误的活动。 以会议的形式，制定目标、流程、规则和结果报告。 相关资料要在会议前下发并阅读。 参加人员 经验丰富的开发人员 和本模块相关的开发人员 测试组和相关人员 审查（Inspection） 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录 不要现场修改 检查要点 设计需求 代码标准/规范/风格 文档的完整性和一致性 自动化工具 基于编码规则 Logiscope LDRA NuMega的CodeReview 基于质量度量 Logiscope McCabe LDRA 如何使静态分析更有效？ 必须引入“别人”的眼睛 根据团队及项目的实际情况，设计合理的实施办法 有准备地进行 应该有包含所有关注要点的Checklist 把握会议时间 每次以 2小时为限 可以进行多次 白盒测试 把测试对象看做一个透明的盒子 利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致 白盒测试目标 尽可能高的覆盖率 对程序模块的所有独立的执行路径至少测试一