Module 2. 软件测试技术

Module 2. 软件测试技术

主要内容 • 软件测试基本方法 • 静态分析 • 白盒测试 • 黑盒测试 • 测试模式 • 范围测试 • 说明书测试 • 风险测试 • 情景测试 • 组合测试 • 探索测试 • 实际练习

什么是静态分析？ • 不实际运行程序，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。 • 作用 • 通过对代码标准及质量的监控提高代码可靠性 • 尽可能早地通过对源代码的检查发现缺陷 • 组织代码审核定位易产生错误的模块 • 非常有效的质量保证手段 • 越来越多地被采用

缺陷产生的原因 其它编码需求设计静态分析的主要内容 • 检查需求 • 检查设计 • 检查代码

需求的标准 完整性是否完整描述一个功能正确性是否正确反应客户要求可行性必要性 Gold plating? 无二义性会引起歧义吗可验证性测试用例怎么写？实施无关性需求规格说明的标准完整性是否包含所有需求 FURPS 一致性相互矛盾重复检查需求

需求检查练习 • 例1　产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于60秒。 • 完整吗？ • 清晰吗？ • 例2　分析程序应该能生成HTML标记错误的报告，从而使HTML初学者可以用它来快速排错。 • 是否有歧义？ • 可验证吗？ • 例3　如果可能的话，应当根据系统货物编号列表，在线确认输入的货物编号。 • “如果可能的话”是什么意思？

需求检查练习 • 例4　产品不应该提供将带来灾难性后果的查找和替换选择。 • 真正的需求是什么？ • 例5　系统对标准XYZ 1.4.1的支持是可选的。 • 有歧义吗？ • 例6　当用户选择“紧凑内存”选项时，程序通过Huffman解析矩阵方法将邮件列表数据压缩到相应的大小。 • 可测吗？ • 代码无关吗？

规格说明用语清单 • 绝对的肯定 • 总是、每一种、所有、没有、从不 • 注意隐含的假设 • 当然、因此、显然、必然 • 模棱两可的词 • 某些、有时、常常、通常、经常、太多、几乎 • 不可测的描述 • 良好、迅速、廉价、高效、稳定 • 隐藏的需求 • 已处理、已拒绝、已忽略、已消除 • 缺少的分支 • 如果…那么…（没有“否则…”分支）

检查设计 • 在编码开始前进行 • 检查功能设计说明，消除歧义 • 功能的用意、总体位置 • 输入、输出 • 可能的错误/例外 • 接口定义 • 交互细节 • 实施建议

检查代码 • 通过代码检查能够发现大部分的错误 • 通过检查代码发现模块中的错误

! 检查代码 • 研究分析代码而不用实际执行 • 包括可执行的代码和非执行的代码 • 提供的信息 • 度量标准 • 容易产生错误的代码 • 代码规则的执行 • 流图和调用图的分析 80%的问题是由于20%的代码引起的

度量元 • 复杂度度量 • McCabe • Halstead • 嵌套级别(最大/平均) • 规格度量 • 行数 • 语句数 • 注释数 • 声明数 • ……

代码审核内容 • 分析容易产生错误的代码: • 控制流分析 • 非结构化的代码 • 死代码 • 数据流分析 • 未定义的数据的使用 • 未使用的数据 • 信息流分析 • 断言分析

代码审核内容 • 流图和调用关系图 • 作为理解代码的帮助 • 作为审核符合设计的帮助 • 作为测试设计的帮助 • 作为调试的帮助 • 代码规则的执行 • 针对不同语言的特征 • 格式和形式 • 命名规范 • 度量标准的强制

静态分析方法 • 走查：Walkthrough • 审查：Inspection • 自动化工具

走查（Walkthrough） • 开发组内部进行的 • 采用讲解、讨论和模拟运行的方式查找错误的活动 • 限时 - 避免跑题 • 参加人员 • 经验丰富的开发人员 • 和本模块相关的开发人员 • 本项目组的新人 • 由本模块的开发者进行讲解、回答问题并记录 • 不要现场修改 • 检查要点 • 逻辑错误 • 代码标准/规范/风格

审查（Inspection） • 开发组、测试组和相关人员(QA、产品经理等)联合进行。 • 采用讲解、提问并使用Checklist方式进行的查找错误的活动。 • 以会议的形式，制定目标、流程、规则和结果报告。 • 相关资料要在会议前下发并阅读。 • 参加人员 • 经验丰富的开发人员 • 和本模块相关的开发人员 • 测试组和相关人员

审查（Inspection） • 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录 • 不要现场修改 • 检查要点 • 设计需求 • 代码标准/规范/风格 • 文档的完整性和一致性

自动化工具 • 基于编码规则 • Logiscope • LDRA • NuMega的CodeReview • 基于质量度量 • Logiscope • McCabe • LDRA

如何使静态分析更有效？ • 必须引入“别人”的眼睛 • 根据团队及项目的实际情况，设计合理的实施办法 • 有准备地进行 • 应该有包含所有关注要点的Checklist • 把握会议时间 • 每次以 2小时为限 • 可以进行多次

Input Output 白盒测试 • 把测试对象看做一个透明的盒子 • 利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试 • 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致

白盒测试目标 • 尽可能高的覆盖率 • 对程序模块的所有独立的执行路径至少测试一次 • 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次 • 在循环的边界和运行界限内执行循环体 • 测试内部数据结构的有效性 • 执行效率

逻辑覆盖 • 以程序内部的逻辑结构为基础的设计测试用例的技术 • 主要包含以下几种情况 • 语句覆盖 • 判定覆盖 • 条件覆盖 • 路径覆盖

逻辑覆盖 • 语句覆盖 • 设计若干个测试用例，使得每一可执行语句至少执行一次 • 判定覆盖 • 设计若干个测试用例，使得程序中每个判断的取真分支和取假分支至少经历一次 • 判定覆盖又称为分支覆盖 • 条件覆盖 • 设计若干个测试用例，使得程序中每个判断的每个条件的可能取值至少执行一次 • 路径覆盖 • 设计足够的测试用例，覆盖程序中所有可能的路径

Input Output 黑盒测试 • 把测试对象看做一个黑盒子 • 不考虑程序内部的逻辑结构和内部特性 • 只依据程序的需求规格说明书 • 检查程序的功能是否符合它的功能说明

黑盒测试 • 在程序接口上进行测试 • 主要是为了发现以下错误 • 是否有不正确或遗漏了的功能? • 在接口上，输入能否正确地接受? 能否输出正确的结果? • 是否有数据结构错误或外部信息(例如数据文件)访问错误? • 性能上是否能够满足要求? • 是否有初始化或终止性错误?

黑盒测试 • 在过去的测试中，我们常从开发者的视角出发分析代码和规格说明书。 • 规格说明书仅能给我们提供一部分风险类型，我们必须在更广的范围内进行测试。 • 不同领域的专家能够看到不同的使系统产生缺陷的机会，并设计出能够引发这些缺陷的测试用例。 • 跳出框框进行思考和设计，是黑盒测试的精髓。

黑盒测试模式

模式与技术 • 测试技术是进行测试的方法。 • 测试模式指用于指导设计测试的思路，一种测试模式可能会用到一种或多种技术。 • 设计任何测试需要包含五个方面的内容： • 测试什么？ • 试图发现什么问题？ • 如何判断测试通过或失败？ • 怎么进行测试？ • 谁来执行测试？

测试模式 • 范围测试 • 规格说明测试 • 风险测试 • 情景测试 • 探索测试 • 组合测试 • …

模式：范围测试 • 采用“抽样”的策略，从众多的可能情况中抽取合理的典型用例 • 常见办法 • 等价类划分 • 将输入划分成若干等价组。 • 从每一类中取一个代表值作为整个组的代表。 • 如果一个测试发现的缺陷，也能被另一个测试发现，则两个测试等价。 • 边界值测试 • 边界值是一个等价类向另一个等价类过度的点。 • 程序在边界更容易出错，所以边界值和边界附近的值是最佳的测试点。

范围测试 • 优点 • 可以通过较少的用例检测出最可能发生的错误 • 很直观的方法，易于普及 • 弱点 • 漏掉不位于边界或典型值的错误 • 边界不易确定

范围测试典型案例 • 三角型问题 • 输入：a, b, c – 分别为三角形的三个边长值 • 输出：该三角形为等边、等腰、或不等边 • 如何设计测试用例？ • 选择什么样的输入值

模糊边界问题 • 理论上说，等价类划分的任务是将输入分类成相互独立并排斥的范围。 • 3D动画游戏 • 对显卡的要求 • 处理速度 • 画面效果 • 兼容性 • 必须测试游戏程序可支持的显卡

模糊边界问题（续） • 如何从数目众多的显卡中选出典型的测试对象？ • 分类的思路 • 市场占有率 • 时间范围 • 品牌、驱动 • 工业标准、芯片 • 支持的操作系统

划分等价类 • 设备兼容性测试显示了多维空间无法明确划分的情况。 • 范围测试成功的关键是记住“分区只是一种抽样策略”。它的目标是从大量潜在的测试中，选出最为合理并有价值的几个代表。 • 好的抽样策略依赖于我们对具体领域的了解，而不仅仅是说明书。 • 如果你知道多种使程序出错的方法，那么对每一种错误，寻找最有可能使错误产生的设备（型号、版本）。

划分等价类 • 客户的问题： • “等价类方法对那些要求支持所有OEM系统、所有声卡和显卡、所有操作系统、及所有技术（例如DirectX 3和5）的人非常有用。 • 那么测试人员怎样才能保证他的等价类表可以提供很好的覆盖率？” • 令人失望但真实的回答： • “即使分析和执行的过程非常好，我们也很可能错过一个可能造成缺陷的设备或驱动，或它们的组合。”

模式：规格说明测试 • 检查产品满足所有规格、需求文档中的每一条陈述。 • 检查用户手册，安装步骤，操作范例。 • 优点 • 彻底分析每个被测功能项 • 避免向客户传递虚假或误导信息，减少支持成本/客户申告 • 弱点 • 未考虑交互影响 • 任何没有列入规格说明、和处理不当的问题

没有规格说明怎么办？ • 所有存在的文档 • 内部版本的软件变更备忘录 • 用户手册草稿（或旧版本） • 有关产品的文章 • 公布的样式指南或UI标准 • 第三方产品兼容性测试系列 • 公布的规范 • 内部备忘录（项目经理给工程师的功能描述） • 采访参与上一个版本开发的人员 • 查看旧版本的客户电话记录，查看现场发现的缺陷 • 易用性测试结果 • Beta测试结果

没有规格说明怎么办？ • 市场演示，产品概念推销 • 缺陷报告及回复 • 工程师对产品的审核会 • 个人采访 • 开发负责人 • 技术写作人员 • 客户服务 • 领域专家 • 项目经理 • 察看header文件，源代码，数据库表定义 • 原型，实验室有关原型的记录

模式：风险测试 • 从可能发生的问题（风险）出发，设计测试 • “先找最大的缺陷” • 风险测试实例 • 失败模式和影响分析 • 从预报的缺陷清单中抽取测试用例 • 压力测试，安全性测试 • 测试预期的或担心的错误

风险测试 • 优点 • 测试作用大 • 直观的测试 • 弱点 • 没有识别或想像到的风险

风险测试 • 主要任务 • 识别风险因素（系统发生故障的情形） • 对每一种风险因素，设计有足够能力对付它的测试 • 评估风险测试的覆盖率，查找测试工作的漏洞 • 评估测试结果和发现的缺陷，判断这些测试所针对的风险是什么，考虑是否有更有效的测试方法。

每一个质量属性都包含 一个风险类别，例如： “系统不可靠的风险” 哪里有风险？ • 质量属性 • 能力 • 可靠性 • 易用性 • 性能 • 易安装性 • 兼容性 • 可支持性 • 可测试性 • 可移植性 • 可维护性 • …

哪里有风险 • 从公布的缺陷统计和缺陷分类中，寻找你感兴趣的缺陷。 • 从清单中找出一个缺陷 • 分析你的软件是否会出现这个缺陷 • 如果从理论上分析被测系统可能存在这个缺陷，思考如何把它找出来 • 思考这个缺陷存在的可能性有多大，及它的严重性 • 针对这类缺陷设计一个或多个测试 • 公布的缺陷信息往往是过时的，且与你的被测系统相差很大。应逐步积累并建立自己的缺陷模式。

哪里有风险？ • 需求：不完整、不正确、不清楚 • 新东西：新功能可能出错 • 新技术：新的概念可能引发新错误 • 学习曲线：由于无知或习惯而造成的错误 • 修改：变更可能会破坏旧的代码 • 仓促的工作：经费和时间不足造成低质量工作 • 疲劳的程序员：长时间的持续工作造成低效和错误 • …

模式：情景测试 • 模拟真实使用情景的测试 • 情景测试实例 • 依照商业规范、客户数据、或竞争对手的结果，对产品进行评估测试 • 生命周期测试 • 特点 • 很现实（来自真实用户或竞争对手的情形） • 测试通过或失败的判定很明确 • 测试覆盖多个特征或功能 • 每个测试都关系到某些涉众（stakeholder）的利益

情景测试 • 优点 • 复杂、真实的事件。可以处理那些不易模拟的情形。 • 能暴露随时间发展而发生的问题 • 弱点 • 单个功能失败可以使测试效率降低 • 必须仔细考虑测试的覆盖率

构造情景的方法 • 目标驱动：某人想得到 X。他怎么能得到 X？ • 序列驱动：某人（或系统）通常按照某个顺序完成任务 X。完成 X 所要经历的常见顺序是什么？ • 交易驱动：我们想完成一桩交易，如开银行帐户或发送信息。完成这个交易的步骤，数据，输出和显示是什么？ • 从竞争对手的产品中获取思路：文档，广告，帮助等。所有关于如何最好或最新颖地使用产品的途径。我们的产品如何完成这些事情？

构造情景的方法 • 竞争对手的输出：嗨！看看他们生成的这些漂亮的文件。或者，瞧他们能够把语法错误的网页显示出来。咱们的产品能吗？ • 客户的表格：这儿有几种客户在业务中使用的表格，我们的程序能处理（读、填写、显示、确认）它们吗？ • 用例分析中提到的情景 • XP开发过程中的客户故事

Module 2. 软件测试技术