ISTQB认证工程师学习笔记（3）——静态测试（静态分析和评审）

静态测试依赖于日记工作产品的手动检查（评审），或是依赖工具驱动的代码或其他软件工作产品的评估（静态分析）。两种类型的静态测试都会评审正在测试的代码或其他软件工作产品，而不需要实际执行代码或相关工作产品。

静态分析在安全关键型的系统中（航空等）很重要，但是在其它环境中也很常见。举个例子，在安全测试中，往往会使用静态分析来完成异常处理是否符合设计约定。

静态分析检查的工作产品：
几乎所有的软件工作产品都可以使用静态测试进行检查，包括但不限于以下几种：
1）规格说明，包括业务需求、功能需求和安全性需求等
2）史诗，用户故事和验收准则
3）架构和设计规格说明
4）代码
5）测试件，包括测试计划、测试用例、测试规程和自动化测试脚本等
6）用户手册
7）web网页
8）合同、项目计划、进度表和预算计划
9）配置设置以及基础设施的设置

评审可应用于任何工作产品，只要参与者能够阅读和理解这些工作产品。静态分析技术可有效地应用于具有规范结构（典型代表有代码或模型）的任何软件工作产品，可运用适当的静态分析工具。静态分析技术甚至可借助工具评估以自然语言编写的工作产品，如需求（例如，检查拼写、语法和可读性）。

静态测试的优势
当在软件开发生存周期的早期应用静态测试，就能够在开展动态测试之前尽早地检测缺陷（例如，在需求或设计规格说明评审，待办事项列表的细化工作等）。早期发现的缺陷通常比软件开发生存周期后期发现的缺陷经济得多，特别是与软件部署和使用后发现的缺陷相比。使用静态测试技术来发现缺陷然后及时修复这些缺陷几乎总是比使用动态测试在测试对象中发现缺陷然后修复它们所花费的成本要低得多，特别是在考虑到更新其他软件工作产品以及开展确认和回归测试的额外成本。

其他静态测试的好处：
1）在动态测试开始前，更高效的检测和修复缺陷
2）识别动态测试不易发现的缺陷
3）通过发现代码与需求的不一致、矛盾、遗漏，或是需求描述的不准确、模糊不清，代码的冗余来防止设计或编码产生的缺陷
4）提高开发效率
5）降低开发成本和时间
6）降低测试成本和时间
7）减少软件在开发生存周期后期或正式上线运行后出现失效的几率，总而降低软件在整个生存周期内的总质量成本
8）在评审过程中促进并改善各项目组成员之间的沟通

静态测试和动态测试的差别
静态测试和动态测试可以具有相同的目标，可以通过不同的测试类型相互补充。

二者的主要区别在于，静态测试发现的是缺陷，动态测试发现的是失效，需要依据失效识别缺陷本质。有的缺陷可以在软件工作产品中存在很长时间而且不一定会引发失效，或是缺陷所在的路径很少被执行或是很难运行到，所以在动态测试中设计对应的测试用例就显得很困难。静态测试则不同，直接从代码层面进行逻辑的覆盖检测，可以付出更少的工作量就能发现更多隐藏的缺陷。

另一个区别在于，静态测试的侧重点是提高软件工作产品内部的一致性和质量，动态测试的侧重点是外部的可见的行为。
相比于动态测试，静态测试可以再更早期，采取更经济的方式发现和解决缺陷，比如：
1）需求缺陷（不一致，含糊不清，矛盾，遗漏等）
2）设计缺陷（算法低效，数据库结构低效，高耦合，低内聚等）
3）代码缺陷（变量定义后未赋值，声明后未被使用，不可达代码，重复多余代码等）
4）与标准规范的偏差（不符合编程规范等）
5）接口规格说明错误（系统或模块之间交互的数据格式不一致）
6）安全漏洞（内存溢出等）
7）测试依据的可追溯性或覆盖率的差距或不准确性（对于某一验收准则缺少验收测试等）

此外、大多数类型的维护性缺陷只能通过静态测试才能被发现（例如：没有很好的模块化、组件的可重用性较差、难以分析的代码以及很难保证修改代码而不引入新缺陷）。

评审

评审类型是多样化的，从非正式到正式的评审。非正式评审的特点是既无需遵守既定的过程，也没有正式的文档化输出。正式评审的特点是团队参与、文档化评审结果以及开展评审的文档化过程。评审过程的正式程度与软件开发生存周期模型、开发过程的成熟度、需评审的软件工作产品的复杂性、任何法律或法规要求和/或审计跟踪等因素有关。
评审的关注点依赖于已达成一致的评审目标（例如：发现缺陷、增加理解、培训参与者如测试员和团队新成员，或对讨论和决定达成共识等）。

工作产品的评审过程

计划
定义范围，包括评审目的、需评审的文档以及需评估的质量特性
估算工作量和时间表
识别评审特性，例如评审类型和相应的角色、活动和检查表
选择参与评审人员并分配角色
针对较正式的评审类型制定入口和出口准则
核对入口准则是否满足

评审启动会
分发工作产品及其他材料（包括事件日志表、检查表等）
向评审参与者解释评审的范围、目标、过程、角色、和工作产品
回答评审参与者可能针对评审提出的任何问题

独立评审（个人准备）
评审全部或部分工作产品
标注可能存在的缺陷、建议和问题

事件交流和分析
交流已识别的潜在缺陷
分析潜在故障，并为这些潜在故障分派负责人和状态
评估和记录质量特性
根据出口准则评估评审发现，以确定评审结论

修正和报告
当发现需要修改工作产品时而创建缺陷报告
修正在工作产品评审中发现的缺陷（一般由作者进行）
与相关人员交流缺陷（当工作产品中的发现关联到被评审的产品）
记录缺陷更新的状态（在正式评审中），可能包括对评审意见提交人的认同
收集度量数据（对较正式的评审类型）
核对出口准则是否满足（对较正式的评审类型）
接受满足出口准则的工作产品

评审类型

虽然评审可用于各种目的，但其主要目的之一是发现缺陷。所有评审类型都可以帮助检测缺陷，所选的评审类型应基于项目需求、可用资源、产品类型和风险、业务领域和公司文化，以及其他选择准则。
评审可以根据各种属性进行分类。下面列举四种最常见的评审类型及其相关属性。

非正式评审（如伙伴检查、结对、结对评审）
 主要目的：检测潜在缺陷
 可能的附加目的：产生新的想法或解决方案，快速解决小问题
 不基于正式的（文档化的）过程
 可能不包含评审会议
 可能由作者的同事（伙伴检查）或更多人参与评审
 可能记录评审结果
 有效性根据评审人员的不同而变化
 使用检查表是可选的
 敏捷开发中使用的非常普遍

走查
 主要目的：发现缺陷、改进软件产品、考虑替代实施、评估与标准和规范的符合程度
 可能的附加目的：交换关于技术或风格变化的想法、参与者的培训、达成共识
 评审会议前的个人准备是可选的
 评审会议通常由工作产品的作者主持
 必须指定书记（记录员）
 使用检查表是可选的
 可能采用场景、演练或模拟的形式
 生成潜在的缺陷记录和评审报告
 在实践中可能从相当非正式到非常正式

技术评审
 主要目的：获得共识、发现潜在缺陷
 可能的进一步目的：评估质量和建立对工作产品的信心、产生新想法、激励和使作者能够改进未来的工作产品、考虑替代实施
 评审员应该是作者的技术同行，以及同一学科或或其他学科的技术专家
 需要在评审会议之前进行个人准备
 评审会议是可选的，最好由经过培训的促进者（主持人）（通常不是作者）主持
 必须指定记录员，最好不是作者
 使用检查表是可选的
 生成潜在的缺陷记录和评审报告

审查
 主要目的：检测潜在缺陷，评估质量并建立对软件工作产品的信心，通过学习和根本原因分析防止未来出现类似缺陷
 可能的进一步目的：激励和使作者能够改进未来的工作产品和软件开发过程、达成共识

 遵循已定义的过程，基于规则和检查表，正式地记录输出
 使用明确定义的角色（如作者，经理，评审组长，评审员，主持人，记录员等），也可能包括专门的朗读者（在评审会议期间朗读工作产品的人经常会用自己的话来解释，即描述。）
 需要在评审会议之前进行个人准备
 评审参与者是作者的同行或与工作产品相关的其他学科专家
 使用已规定的入口和出口准则
 必须指定书记（记录员）
 评审会议由经过培训的促进者（主持人）（不是作者）引导
 作者不能担任评审组长、朗读者或书记（记录员）
 通常生成潜在的缺陷记录和评审报告
 收集度量并用于改进整个软件开发过程，包括审查过程

评审技术的应用

在独立评审（即个人准备）活动期间可以应用许多评审技术来发现缺陷。这些技术可用于上述评审类型。这些技术的有效性可能因所使用的评审类型而异。下面列出了各种评审类型的不同独立评审技术的示例。

临时评审
在临时评审中，评审员很少或根本没有得到指导如何执行此任务。评审员经常按顺序阅读工作产品，在遇到问题时识别并记录事件。临时评审是一种常用的技术，几乎不需要准备。此技术高度依赖于评审员的技能，并可能导致不同评审员报告许多重复的事件。

基于检查表的评审
基于检查表的评审是一种系统性的技术，评审员基于评审开始时（例如，由促进者（主持人））分发的检查表来发现事件。评审检查表包含一组基于潜在缺陷的问题，这些问题可能来自经验。检查表应特定于所评审的工作产品类型，并应定期维护以涵盖以前评审中遗漏的事件类型。基于检查表的技术的主要优点是对典型缺陷类型的系统的覆盖。应注意不要简单地按照独立评审中的检查表，而是也要寻找检查表之外的缺陷。

场景和演练的评审
在基于场景的评审中，将为评审员提供有关如何通读工作产品的结构化指南。基于场景的评审支持评审员基于工作产品的预期使用，对工作产品开展“演练”（如果工作产品以适当的格式记录，例如用例）。与简单的检查表条目相比，这些场景为评审员提供了有关如何识别特定缺陷类型的更好指导。与基于检查表的评审一样，为避免错过其他缺陷类型（例如，功能遗漏），评审员不应受限于文档化的场景。

基于视角
在基于视角的文档阅读评审中，类似于基于角色的评审，评审员在独立评审中采用不同的利益相关方观点。典型的利益相关方观点包括最终用户、市场人员，设计人员、测试员或操作员。使用不同的利益相关方视角可以更加深入地进行独立评审，同时可以减少评审员之间的重复问题。此外，基于视角的文档阅读评审还要求评审员尝试使用被评审的工作产品来生成他们所需的衍生产品。例如，如果对需求规格开展基于阅读视角的文档评审，以查看是否包含所有必要信息，这 时测试员将会尝试生成草拟的验收测试。此外，在基于视角的文档阅读评审中，希望使用检查表。经验研究表明，通常情况下基于阅读视角的文档评审是评审需求和技术工作产品最有效的技术。关键的成功因素是基于风险适当地包括和权衡不同的利益相关方观点。

基于角色的评审
基于角色的评审技术，评审员可以从独立利益相关方角色的角度评估工作产品。典型角色包括特定的最终用户类型（有经验、没有经验、老人、小孩等），以及组织中的特定角色（用户管理员、系统管理员、性能测试员等）。同样的原则也适用于基于视角的阅读，因为角色是相似的。

评审的成功因素

为了获得成功的评审，必须考虑适当的评审类型和使用的技术。此外，还有许多其他因素会影响评审结果。

组织层面的评审成功因素包括：
 每次评审都有明确的目标，其在评审计划中得到定义，并将其作为可度量的出口准则
 应用的评审类型要适用于要实现的目标，适用于软件工作产品的类型和级别，以及参与者
 所使用的任何评审技术（例如基于检查表或基于角色的评审）要适用于在被评审的工作产品中有效的缺陷识别
 使用的任何检查表要处理主要风险，并且检查表是最新的
 大型文档以小块形式编写和评审，从而通过向作者提供早期和频繁的缺陷反馈来实施质量控制
 参与者有足够的时间来准备
 安排评审并得到足够的重视
 管理者支持评审过程（例如，通过在项目进度表中考虑足够的时间进行评审活动）
 评审与公司的质量和/或测试方针相结合。

与人相关的评审成功因素包括：
 合适的人员参与以满足评审目标，例如，具有不同技能或观点的人员，他们可能将文档用作工作输入
 测试员参加评审不但有利于提高评审质量，还可以通过评审了解产品，以使他们准备更有效测试，以及尽早准备这些测试
 参与者将有充足的时间和精力关注细节
 评审应分成小块任务进行，以便评审员在独立评审和/或评审会议期间不会失去注意力（当召开时）
 对发现的缺陷持欢迎态度，并客观地处理缺陷
 管理好评审会议，使参与者感受到他们的时间是有价值的
 评审应该在信任的氛围中进行；结果不会用于评估参与者
 参与者避免使用可能表示对其他参与者感到无聊、恼怒或敌意的肢体语言和行为
 提供充分的培训，特别是对于较正式的评审类型，如审查
 强调学习和过程改进的文化