ISTQB基础知识：软件静态测试技术

ISTQB基础知识软件静态测试技术目录静态测试技术概述评审技术概述走查技术评审静态测试工具静态测试技术概述概述静态测试技术通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查而不需要执行代码。静态测试分为评审和静态分析两种形式评审评审是对软件工作产品（包括代码）进行测试的一种方式，可以在动态测试执行之前进行。在生命周期早期的评审过程中发现并修改缺陷（例如发现需求中的缺陷）的成本会比在动态测试中才发现并修改这些缺陷的成本低的多。评审可以完全以人工的方式进行，也可以通过工具的支持来进行。人工进行评审的主要活动是检查工作产品，并对工作产品做出评估。特点相对于动态测试而言，静态测试成本更低，效率较高可以在软件开发生命周期早期发现缺陷静态测试是一种非常有效的测试技术静态测试技术的工作产品和关系工作产品需求规格说明设计规格说明代码测试计划(testplan)测试规格说明(testspecification)测试用例测试脚本用户指南WEB页面等评审、静态分析和动态测试之间的关系评审、静态分析和动态测试具有共同的目标：识别缺陷。它们之间是互补的：不同的技术可以有效和高效地发现不同类型的缺陷。与动态测试相比，静态技术发现的是软件失效的原因而不是失效本身。静态测试分类小结静态测试技术评审工具支持的静态测试（静态分析）非正式评审正式评审走查技术评审审查评审技术概述概述通过一个过程或一个会议，向项目相关人员、管理人员、用户、客户及其相关人员陈述一件软件产品，并征求大家的评论或认可。其他开发人员对被评审开发人员的工作产品（程序代码、文档），按照事先定义的规程进行的评估和审查评审的目的在于发现工作产品的缺陷和需要改进之处评审的好处尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少缺陷以及改善沟通等。评审也可以在工作产品中发现一些遗漏的内容，例如发现需求有遗漏，而这在动态测试中是很难被发现的。评审发现的典型缺陷与标准之间的偏差需求内的错误设计错误可维护性不足错误的接口规格说明等等。评审技术分类分类非正式评审：对正在进行中的工作产品进行评审，不需要遵循明确定义的过程，评审者可能没有书面指导性资料可参考正式评审：对开发人员已经确认完成的工作产品，遵循明确定义的过程进行评审，参与人员有明确的职责与检查表，具有明确定义的进入和完成评审的准则（结构化和规范化）正式评审分为：走查WalkThrough技术评审TechnicalReview正规检视/审查Inspection决定评审方式的因素开发过程的成熟度法律法规方面的要求审核跟踪(audittrail)的需要如何开展评审由评审的共同目标决定（目标如发现缺陷、增加理解或有共识的讨论和决定等）一篇文档可能需要经历多次评审。如果使用了不只一种评审类型,则评审的顺序可能会有所变化。比如，技术评审之前可能会进行非正式评审，或在客户走查之前可能进行需求规格说明审查。评审的作用在每个项目中都是简便而有效的质量保证手段。在软件开发周期的早期阶段就可以进行的检查活动，并且能够尽早的发现和修改缺陷。能发现在动态测试过程发现不了或很难发现的缺陷（例如，需求规格说明书内遗漏和错误的内容）。能改进设计和开发能力。能缩短开发周期，减少后续测试的费用和时间，降低整个生命周期的费用。促进了团队内知识的传播和共享以及交流的机会。为项目团队提供较好的交流观点和建议的平台。为作者提供了一个阐述他/她的工作的机会和平台。•60-90%的缺陷可以通过技术评审发现•1小时有限的技术评审可以减少33小时的修正缺陷的时间•有效的技术评审比动态测试工作效率高20倍评审过程计划阶段准备工作（自评审）•管理层次•决定评审对象•确定评审时间和所需资源•培训相关人员•选定主持人•组建评审组•确定具体时间、地点以及预备会（如有必要）•定义开始和结束条件•所有参加评审的有关人员各自做好评审会议的准备工作•评审员可能会针对不同的审查重点分别准备•记录发现的缺陷、不足、问题或评论•可以使用检查表(Checklist)评审过程（续）评审会议/执行评审，会议记录修改错误复审或复核•对评审对象而不是作者进行评论•对不足、错误、问题和评论进行讨论•记录员记录不足、错误、修改要求、待处理事件等•可以使用检查表（Checklist）•对发现的缺陷和不足进行评估•确定修改措施并做好记录•在会后向参加评审人员和相关人员发放评审的记录报告•作者根据评审记录对评审对象进行修改•主持人检查所有评审后的工作都已经到位•进行度量分析（例如，缺陷的密度、覆盖度、成本）•检查是否符合规定的结束评审条件•管理机构确定此次评审工作是否达到预期的目的评审角色经理决定是否需要进行评审，在项目计划中分派时间，判断是否已达到评审的目标。主持人主持文档或文档集的评审活动，包括策划评审、召开会议和会议后的跟踪。假如需要，主持人可能还需要进行不同观点之间的协调。主持人通常是评审是否成功的关键。作者待评审文档的作者或主要责任人。评审员具有专门技术或业务背景的人员（也称为检查员(checker)或审查员(inspector)），他们在必要的准备后，标识和描述被评审产品存在的问题（如缺陷）。所选择的评审员应该在评审过程中代表不同的观点和角色，并且应该参与各种评审会议。记录员记录所有的事件、问题，以及在会议过程中识别的未解决的问题。说明每个人承担不同的职责，不同的评审形式可能包含更多角色非正式评审特点最简单的评审形式，没有正式的评审过程，没有制定任何角色可以是由程序员的同行们或技术负责人对设计和代码进行评审一般情况下不需要评审会议，不一定形成评审文档主要目的以低廉的开销达到评审的目的优点可以随时召集进行，评审所花时间短，成本低缺点参加者必须对评审材料比较熟悉评审质量取决于评审员的素质没有评审记录和报告，没法证明曾经执行过评审活动走查概述概述评审对象主要是软件代码，对源程序代码分析、检验，并补充相关的文档，发现程序的错误目的传播知识、了解情况、查找错误走查人员构成作者，一个以上评审人员走查特点特点由作者主持开会。作者阐述评审对象，以场景、演示的形式和同行参加的方式进行。开放式模式。一般没有评审的准备工作和后续工作评审会议之前的准备、评审报告、发现的问题清单和记录员（不是作者本人）都是可选的。在走查评审开始时评审人员才会拿到相关材料并且在走查会议间才开始对材料走读和审查在实际操作中经常在很正规和完全不拘形式间变化优点参加评审的人员只需少量的准备工作可以临时召集缺点参加者必须对相关材料非常熟悉错误或者其它问题可能被忽略走查内容检查变量的交叉引用表检查未说明的变量和违反了规定类型的变量，变量的引用和使用情况检查子程序、宏、函数验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致常量检查确认常量的取值和数制、数据类型标准检查检查程序中是否违反标准的问题风格检查检查程序的设计风格比较控制流比较设计控制流图和实际程序生成的控制流图的差异详细阅读源代码对照程序的规格说明，比较实际的代码，从差异中发现程序的问题和错误走查的过程走查计划走查准备走读修正错误复审记录走读结果技术评审概述由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查，以找出和消除其中的缺陷。目的发现软件在功能、逻辑、实现上的错误验证软件符合它的需求规格讨论、作决策、评估候选方案、解决技术问题、确认软件符合预先定义的开发规范和标准保证软件在统一的模式下进行开发便于项目管理正规技术评审为新手提供软件分析、设计和实现的培训途经后备、后续开发人员通过正规技术评审熟悉他人开发的软件技术评审的特点关注评审对象的技术方面在会前做好准备熟悉被评审材料和评审要求检查表(Checklist)评审报告模板缺陷表模板与技术专家合作（也可能是特邀的公司外部的专家）管理人员、客户也可以被邀请参加不强制要求作者参加主持人应接受过评审训练在非常正规化和不拘形式间变化文档化和定义的缺陷检测过程，需要包含同行和技术专家。可能是没有管理者参与的同行评审。在实际情况中可以是在不正式的和非常正式的之间。评审组成员评审组由多个评审员(Reviewer、Inspector)组成评审组成员，包括主持人(Moderator)、作者(Author)、宣读员(Reader)、记录员(Recorder)。评审组成员的职责是在会前准备阶段和会上检查被审查材料，找出其中的缺陷。合适的评审员人选包括被审材料在生命周期中的前一阶段、本阶段和下一阶段的相关开发人员。不同阶段的评审员由不同角色的人员组成。例如，需求分析评审员可以包括客户和概要设计者，详细设计和代码的评审员可以包括概要设计者、相关模块开发人员、测试人员。评审工作角色与职责主持人(Moderator)在评审会前负责正规技术评审计划和会前准备的检查；在评审会中负责调动每一个评审员在评审会上的工作热情，把握评审会方向，保证评审会的工作效率；在评审会后负责对问题的分类及问题修改后的复核。宣读员(Reader)在评审会上通过朗读和分段来引导评审小组遍历被审材料。除了代码评审可以选择作者作为宣读员外，其他评审最好选择直接参与后续开发阶段的人员作为宣读员。记录员(Recorder）记录员负责将评审会上发现的软件问题记录在“技术评审问题记录表”。在评审会上提出的但尚未解决的任何问题以及前序工作产品的任何错误都应加以记录。作者(Author)被审材料的作者负责在评审会上回答评审员提出的问题，以避免明显的误解被当作问题。此外，作者须负责修正在评审会上发现的问题。技术评审过程评审计划预备会（可选）会前准备（自评审）评审会议修正错误复审复核错误很多？否是技术评审的内容评审计划主持人检查作者提交的被审材料是否齐全，是否满足评审条件。例如，代码应通过编译后才能参加评审。主持人确定评审小组成员及职责，确定评审会时间、地点。主持人向评审小组成员分发评审材料。评审材料应包括：被审材料、检查要点列表（Checklist）和相关技术文档。预备会（可选）如果评审小组不熟悉被审材料和有关背景，主持人可以决定是否召开预备会。在预备会上，作者介绍评审理由、被审材料的功能、用途及开发技术。会前准备（自评审）在评审会之前，每一位评审员应根据检查要点逐行检查被审材料，对发现的问题做好标记或记录。主持人应了解每一位评审员会前准备情况，掌握在会前准备中发现的普遍问题和需要在评审会上加以重视的问题。技术评审的内容评审会议评审会议由主持人主持，由全体评审员共同对被审材料进行检查。宣读员逐行朗读或逐段讲解被审材料。评审员随时提出在朗读或讲解过程中发现的问题或疑问，记录员将问题写入“技术评审问题记录表”。必要时，可以就提出的问题进行简短的讨论。如果在一定时间内（由主持人控制）讨论无法取得结果，主持人应宣布该问题为“未决”问题，由记录员记录在案。在评审会议结束时，由全体评审员作成评审结论。主持人会议评审会结束后对“技术评审问题记录表”中问题进行分类。修正错误作者在会后对评审会上提出的问题进行修正复审如果被审材料存在较多的问题或者较复杂的问题，主持人可以决定由全体评审员对修正后的被审材料再次举行评审会。复核主持人或主持人委托他人对修正后的被审材料进行复核，检查评审会提出的并需要修正的问题是否得到解决。主持人完成“技术评审总结报告”。技术评审的注意事项评审应针对被审材料而不是被审材料的作者。评审会的气氛应该保存轻松、愉快，指出问题的语气应该温和。每次评审会的时间最好不要超过2小时。当被审材料较多时，应将被审材料分为若干部分分别进行评审。