第二章 静态测试

1第二章静态测试2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-2本章要点讨论与静态测试相关的内容，包括评审1.评审的定义和分类2.同行评审的分类3.评审工作流程4.对规格说明书的测试5.源代码评审静态分析及其工具2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-3静态测试定义通过检查和评审软件而不是运行软件对软件进行测试的方法对象各种与软件相关的有必要进行测试的产物，例如各类文档、源代码等方法评审对软件元素或项目状态进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见通常由人来执行静态分析被测程序进行特性分析的一些方法的总称通常需要工具辅助2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-4缺陷发现越早修复成本越低01020304050607080需求设计编码测试交付使用不同项目阶段修复同一缺陷花费的成本2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-5评审除了在项目早期发现缺陷和降低项目失败风险外，项目中需要进行评审的其它原因包括1.分享知识2.培训团队成员3.为管理层决策提供依据4.为过程改进提供信息评审分类培训评审预备评审同行评审状态评审2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-6同行评审（PeerReview）由开发软件产品作者以外的其他人检查工作产品，以发现缺陷并寻找改进的机会方法：评审参与者主要采用一行一行仔细阅读被评审对象的形式发现被测对象中的缺陷一般设在里程碑点附近，即当工作产品到达了一个完成的里程碑并即将进入下一个开发阶段时同行评审2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-7V模型的评审时间点需求|需求规格说明书评审概要设计|概要设计说明书详细设计|详细设计说明书编码|源代码单元测试集成测试系统测试系统测试文档集成测试文档单元测试文档评审评审评审评审评审走读，静态分析2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-8同行评审的类型审查小组评审走读桌面评审临时评审这些同行评审类型的区别在于正式程度审查是最正式，然后是小组评审、走读、桌面评审，临时评审最随意同行评审越正式，发现的缺陷越多，但评审越正式，花费成本越高被评审对象越重要或者风险越高，采用的评审方式越正式同行评审的类型2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-9审查说明IBM的工程师MichaelFagan于20世纪70年代提出，也叫正式评审，是一种包括非作者等专家在内的针对特定对象，如需求规格书、设计文档和源代码进行检查以发现缺陷的过程审查是一种有结构有规则的评审方法。Fagan的审查流程包括：计划、介绍会议、准备、会议、返工、跟踪、因果分析，每个阶段定义参与审查的角色相应的输入、输出2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-10审查流程2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-11审查中的角色作者被评审对象的创建者，提供被评审对象及其相关信息评审组长组织评审会议，确保审查活动能够正确地进行审查专家发现被评审对象中的问题读者在会议上讲解被评审对象，使评审专家把精力集中在被评审对象本身而不是作者记录员记录会议阶段有价值的信息2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-12计划参与者：作者和评审组长在这个阶段，需要开展如下工作1.选择评审组长2.确定审查对象3.确定审查专家4.确定总体会议、会议次数和相应的时间表5.准备和分发审查工作包，审查包中包括被审查对象的初始可交付产品、相关参考文档、缺陷检查表、指导书、错误记录模版和其它材料审查工作流程2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-13总体会议本阶段可选，主要目标是让审查专家熟悉被审查对象，包括对象特征、上下文、背景等参与者：所有需要参加审查的人员准备参与者：审查专家这是审查最重要的阶段。在这个阶段，1.审查专家独立工作、逐行阅读被审查对象，将任何发现问题、疑问记录在审查意见单中2.评审组长根据各个审查专家提交的意见决定是否按时或者推迟召开审查会议审查工作流程2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-14会议参与者：作者、评审组长、审查专家、读者、记录员在会议阶段1.读者分段逐个阅读审查对象，审查专家听取讲解并考虑是否有新的问题提出。2.评审组长组织对所有审查意见单上的问题列表进行确认，作者确认是否是问题，记录员在问题列表上记录答复和在会上发现的新缺陷。3.在会议结束前，所有人投票，给出对工作产品的审查结论。审查工作流程2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-15返工参与者：作者在此阶段，作者修改会议中确认的问题，输出修改后的交付产品跟踪参与者：评审组长/质量工程师/指定的审查专家检查修改后的交付件，如果通过，则输出可基线的交付物因果分析参与者：质量工程师在这个阶段，开展如下工作：1.分析缺陷原因2.度量审查效率和效果审查工作流程2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-16审查规则为了更好地发挥审查的作用，在审查中有一组需要遵守的原则作者不能担当评审组长、读者或记录员等角色，要保持开放的思想，接受别人的意见，避免争论评审组长不要同时担任记录员控制审查小组规模：3～7个审查专家为好审查专家要努力发现被审查对象中的问题，审查过程中始终保持对问题的敏感性审查期间要努力发现问题不要试图去解决问题会议限制在两个小时之内在会议上，审查团队要保持一个适当的审查速度，每小时150～200行代码或3～4页文档2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-17小组评审小组评审类似于审查，是一种“轻型审查”，同样可以可采用审查的指导方针和流程，只是没有审查正式也没有审查严格，会议期间读者的角色由评审组长代替小组评审方法发现问题的数量是审查的2/32007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-18走读和同级桌查走读产品的作者一组同事说明该产品，希望获得他们的意见以满足自己的需要。走查是一种非正式的评审，其过程由作者主持，没有标准的流程可循发现的缺陷数量比审查少一半过程同级桌查一对一评审，是指只有除作者以外只有一位评审专家对工作产品进行检查2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-19临时评审临时评审请团队内其他同事帮忙，在短时间内解决一些问题举例假设这样一个场景：Susan是一个程序员，她正在检查自己的代码。John，Susan的同事，是另外一个程序员：Susan:”Hi,John,能帮个忙吗？”John:”当然，我现在刚好有空”Susan:”我的程序有点问题，但我不找不到问题在哪里”John:”Okey!让我看看!”…几分钟后，”Oh,问题可能在这儿，你看，这里有变量用错误，这个“i”好像没定义过，你是不是想用“j”？Susan:”Oh,yeah!没错!非常感谢!”2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-20软件评审指导书内容目的范围评审角色及职责过程准则1.目标2.进入标准3.活动4.退出标准5.度量相关资料过程监控2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-21DV剧背景时间点1.评审计划10月18日-10月19日活动：完成被评审对象；启动评审电子流；确定主审人，评审专家，评审会议时间；提交被评审对象2.评审准备10月20日活动：评审专家独立审阅被评审对象，发现问题3.评审会议10月21日晚上活动：召开评审会议，确认评审问题是否是问题4.评审跟踪10月22日活动：责任人修改评审问题，主审人提交评审总结报告2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-22DV剧背景用到的与评审相关的资料1.被评审对象：《BMW2.0计费系统软件需求规格说明书》2.《预审意见模版》3.《软件需求规格说明书Checklist》4.《软件评审指导书》5.《评审过程Checklist》6.《评审总结》评审电子流是一个与评审流程处理相关的信息化系统，用于处理评审流程的信息，可提高评审流程处理和管理效率2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-23检查软件的规格说明书一般采用逐行阅读说明书以发现缺陷的方式，规格说明书的测试应该在说明书整体或者部分完成后立即开展原因尽早发现缺陷使说明书具有更好的可测试性软件测试人员可以更加熟悉系统应用具体方法静态黑盒测试：由于考虑到规格说明书的重要性，很多软件项目选择审查作为评审规格说明书的方式在进行规格说明书审查时可以采用如下技术：1.对说明书进行概要评审2.对说明书进行详细评审测试规格说明书2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-24目标发现特定的缺陷，比如大的原理性问题，遗漏或过度复杂的描述等可以使用如下技术假设作为用户：质量就是满足用户要求研究现有标准和基线评审和测试类似软件系统规格说明书的概要评审（1）2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-25假设作为用户从用户的角度检查规格书，可以问自己如下问题，如果我是软件的客户：1.我需要什么样的功能？2.我需要的所有功能是否都包含在规格书中了？3.是否存在与现有系统冲突的功能？4.功能是否易于使用？5.性能如何？6.功能的安全情况如何？等等如果能从一些熟悉软件目标应用领域的人处获得支持，对评审过程将是非常有帮助的规格说明书的概要评审（2）2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-26研究现有标准和基线当对规格书进行概要评审的时候，测试人员应该参考现有的标准和基线：1.组织标准、术语和惯例：软件应该使用终端用户的通用术语和惯例2.工业标准：在某些工业领域，例如通讯、金融，有很多应用软件必须遵守的协议3.政府标准4.安全标准等等测试人员应该把相关标准作为规格说明书评审的一部分评审规格说明书的同时，测试人员应该验证系统参考了正确的标准并且没有遗漏规格说明书的概要评审（3）2007级本科《软件测试与质量保证》2009年9月-2010年01月SEIofECNU版权所有©2-27评审和测试类似软件没有什么比经验更好的东西了，从类似软件中可以得大量有用的信息，这些参考软件可能是：1.正在开发系统的早期版本2.组织内的类似软件3.竞争对手产品分析类似软件的时候，应密切关注如下问题并考虑这些是否会影响被测试系统：1.特性是否有增删？2.代码变更比例如何？3.软件的复杂度是否有区别？4.可测试性如何？5.性