软件测试4静态测试

《软件测试4静态测试》由会员分享，可在线阅读，更多相关《软件测试4静态测试（47页珍藏版）》请在金锄头文库上搜索。

1、1,静态测试,计算机学院软件工程系 Email:Xiahui_ Telphone:15829202190 QQ:79003370(不聊天),2,本章要点,静态测试概述 评审 评审流程 对规格说明书的测试 代码评审 代码分析,3,静态测试,定义 通过检查和评审软件而不是运行软件对软件进行测试的方法. 对象 各种与软件相关的有必要进行测试的产物，例如各类文档、源代码等.,4,静态测试方法,评审 1.对软件文档和代码由人进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见. IBM的工程师Michael Fagan于20世纪70年代提出,静态分析 通过工具对被测代码进行特性分析,5,V模型的

2、评审时间点,评审,评审,评审,评审,评审,评审,走读，静态分析,6,优点 1.充分发挥人的思维优势,易开展，不需特别条件 2.一旦发现错误，就知道错误的性质和位置，修改花费的代价低 3.使用这种方法，一次能揭示一批错误，而不是一次只揭示一个错误 按经验估算，一般能发现30%70%的逻辑设计和编码错误的缺陷。 IBM使用代码审查，错误检测效率占所有错误的80%。,静态测试的优缺点,缺点 1.静态代码检查非常耗费时间，而且代码检查需要丰富的知识和经验积累。 2.静态白盒测试一般面临的情况是不能善始善终，因为小组会认为不太好使，费用太高，没有产出。 3.对测试人员要求较高，要有编程经验，需要有知识和

3、经验的积累，能发现问题本身而非征兆。,7,评审的类型,评审类型的区别在于正式程度 评审越正式，发现的缺陷越多，但评审越正式，花费成本越高。 被评审对象越重要或者风险越高，采用的评审方式越正式 。,8,评审流程,流程 计划、介绍会议、准备、会议、返工、跟踪、因果分析 每个阶段参与的角色、输入、输出,9,审查流程,10,审查中的角色,作者 被评审对象的创建者，提供被评审对象及其相关信息 评审组长 组织评审会议，确保审查活动能够正确地进行 审查专家 发现被评审对象中的问题 读者 在会议上讲解被评审对象，使评审专家把精力集中在被评审对象本身而不是作者 记录员 记录会议阶段有价值的信息,11,1 计划

4、参与者：作者和评审组长 在这个阶段，需要开展如下工作： 选择评审组长 确定审查对象 确定审查专家 确定总体会议、会议次数和相应的时间表 准备和分发审查工作包， 审查包中包括被审查对象的初始可交付产品、相关参考文档、缺陷检查表、指导书、错误记录模版和其它材料,审查工作流程,12,2 总体会议 本阶段可选，主要目标是让审查专家熟悉被审查对象，包括对象特征、上下文、背景等 参与者：所有需要参加审查的人员 3 准备 参与者：审查专家 这是审查最重要的阶段。在这个阶段， 审查专家独立工作、逐行阅读被审查对象，将任何发现问题、疑问记录在审查意见单中 评审组长根据各个审查专家提交的意见决定是否按时或者推迟召

5、开审查会议,审查工作流程,13,4 会议 参与者：作者、评审组长、审查专家、读者、记录员 在会议阶段 读者分段逐个阅读审查对象，审查专家听取讲解并考虑是否有新的问题提出。 评审组长组织对所有审查意见单上的问题列表进行确认，作者确认是否是问题，记录员在问题列表上记录答复和在会上发现的新缺陷。 在会议结束前，所有人投票，给出对工作产品的审查结论。,审查工作流程,14,5 返工 参与者：作者 在此阶段，作者修改会议中确认的问题，输出修改后的交付产品 6 跟踪 参与者：评审组长/质量工程师/指定的审查专家 检查修改后的交付件，如果通过，则输出可基线的交付物,审查工作流程,15,审查工作流程,7 因果分

6、析 参与者：质量工程师 在这个阶段，开展如下工作： 分析缺陷原因 度量审查效率和效果,16,审查规则,为了更好地发挥审查的作用，在审查中有一组需要遵守的原则 作者不能担当评审组长、读者或记录员等角色，要保持开放的思想，接受别人的意见，避免争论 评审组长不要同时担任记录员 控制审查小组规模：37个审查专家为好,17,审查规则,遵守的原则： 审查专家要努力发现被审查对象中的问题，审查过程中始终保持对问题的敏感性 审查期间要努力发现问题不要试图去解决问题 会议限制在两个小时之内 在会议上，审查团队要保持一个适当的审查速度，每小时150200行代码或34页文档,18,软件评审指导书,目的：将评审过程和

7、规则以指导书的形式固定下来。 范围 评审角色及职责 过程准则 目标 进入标准 活动 退出标准 度量 相关资料 过程监控,19,检查软件的规格说明书一般采用逐行阅读说明书以发现缺陷的方式，规格说明书的测试应该在说明书整体或者部分完成后立即开展 原因 尽早发现缺陷 使说明书具有更好的可测试性 软件测试人员可以更加熟悉系统应用,测试规格说明书,20,测试规格说明书,具体方法 静态黑盒测试：由于考虑到规格说明书的重要性，很多软件项目选择审查作为评审规格说明书的方式. 在进行规格说明书审查时可以采用如下技术： 对说明书进行概要评审 对说明书进行详细评审,21,目标 发现特定的缺陷，比如大的原理性问题，遗

8、漏或过度复杂的描述等 可以使用如下技术 假设作为用户：质量就是满足用户要求 研究现有标准和基线 评审和测试类似软件系统,规格说明书的概要评审（1）,22,假设作为用户 从用户的角度检查规格书，可以问自己如下问题，如果我是软件的客户： 我需要什么样的功能？ 我需要的所有功能是否都包含在规格书中了？ 是否存在与现有系统冲突的功能？ 功能是否易于使用？ 性能如何？ 功能的安全情况如何？ 如果能从一些熟悉软件目标应用领域的人处获得支持，对评审过程将是非常有帮助的,规格说明书的概要评审（2）,23,研究现有标准和基线 当对规格书进行概要评审的时候，测试人员应该参考现有的标准和基线： 组织标准、术语和惯例

9、：软件应该使用终端用户的通用术语和惯例 工业标准：在某些工业领域，例如通讯、金融，有很多应用软件必须遵守的协议 政府标准 安全标准，等等 测试人员应该把相关标准作为规格说明书评审的一部分,规格说明书的概要评审（3）,24,评审和测试类似软件 没有什么比经验更好的东西了，从类似软件中可以得大量有用的信息，这些参考软件可能是： 正在开发系统的早期版本 组织内的类似软件 竞争对手产品,规格说明书的概要评审（4）,25,规格说明书的概要评审（4）,分析类似软件的时候，应密切关注如下问题并考虑这些是否会影响被测试系统： 特性是否有增删？ 代码变更比例如何？ 软件的复杂度是否有区别？ 可测试性如何？ 性能

10、、安全性和其他一些非功能特性如何？ 最后，不要忘了你可以从公共出版物和网上找到有价值的信息,26,一个好的规格说明书具有如下属性： 1 完整性：是否忘记或遗漏了什么内容？是否彻底？是否包含了该说明书所必须包含的所有信息？ 2 精确性：建议的提案是否正确？是否定义了合适的目标？是否有什么错误？ 3 准确性、明确而清晰：描述是否清晰明确，是否有歧义？是否易于阅读和理解？,规格说明书的详细评审（1）,27,规格说明书的详细评审（1）,4 一致性：特性描述内部和特性之间是否相互矛盾 5 相关性：细分特性是否必须？是否需要去除不必要的信息？特性是否可以跟踪到一个原始用户需求 6 可行性：项目计划和预算都

11、是明确的，在给定的人力、工具和资源条件下，特性能否实现？,28,一个好的规格说明书具有如下属性： 代码无关：规格书的目标是定义产品需求而不是软件设计，架构和代码 可测试的：特性是否可测试？是否提供了让测试人员得以验证功能的足够信息 检查规格说明书的同时，时刻关注评审的文字和图片是否具有这样的属性,规格说明书的详细评审（2）,29,问题词语列表 评审规格说明书的时候应密切关注下面的一些词汇以及这些词汇的上下文含义是否清晰，这些常常会带来缺陷： 总是、每个、所有、没有一个、从来不：这些词表示肯定和确定的含义，必须确认该用这些词语，或找出不该使用的理由 当然、所以、明显地、无疑、显然：这些词有劝说人

12、接受的意思，规格书中尽量避免,规格说明书的详细评审（3）,30,规格说明书的详细评审（3）,4 一些、有时、经常、通常、大部分、主要的、等等、类似、好、快、便宜、高效、小和稳定：这些词可测试性差，必须进一步定义以给出确切的含义描述 5 有把握的、处理过的、拒绝的、跳过的、去掉的：这些词可能隐藏一些本该详细说明的功能性需求 6 如果那么：这些描述依赖于其他因素，不可取,31,在代码全部或部分完成后，应立即进行逐行代码评审以发现缺陷 原因 发现缺陷越早越好 使得程序更具可测试性 软件测试人员可以更加熟悉系统,代码检查,32,评审的类型,评审的类型 代码审查 由若干程序员和测试员组成一个会审小组，通

13、过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步： 代码走查 让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组 。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍。 桌面评审 由程序员自查。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关文档。,33,代码评审,方法 静态白盒测试：很多软件项目团队选择审查作为评审核心代码的方式，采用走查和桌面检查作为一般代码的评审方式 团队采用如下原则进行代码评审效果更好 评审人员有程序开发语言的专业知识 有程序基线和标准供参考,34,编码规范 编码

14、规范是代码编写过程中必须遵循的规则，包含了程序开发的最佳实践、在编写代码时重复这些最佳实践有助于生产高质量的软件。,编码规范,35,代码检查表,代码检查表 代码检查表是对应于编码规范中的各个标准与规范开发的检查项，包含容易出错和以往在工作中遇到的典型错误，可以认为是在进行代码评审时用到的测试用例。 在进行代码评审时，评审专家会关注被评审代码是否符合检查表规范，如果不符合则很可能存在缺陷。,36,请注意 不同的编码语言和项目团队可能采用不同的标准和基线，适合项目的就是最好的 编码规范和检查表应该在一个项目完成后被检验和更新,编码规范和代码检查表,37,2.5静态分析,定义 静态分析是对被测程序进

15、行特性分析的一些方法的总称，一般借助工具进行 可提供的功能包括： 发现代码中的缺陷，包括 用错的局部变量和全程变量 不匹配的参数 不适当的循环嵌套和分支嵌套,38,静态分析,可提供的功能包括： 发现代码中的缺陷，包括 4 不适当的处理顺序 5 无终止的死循环 6 未定义的变量 7 不允许的递归 8 调用并不存在的子程序 9 遗漏了标号或代码 10 不恰当的连接等,39,静态分析,可提供的功能 找到潜伏着缺陷的根源。 未使用的变量 不会执行到的代码 未引用过的标号 可疑的计算 潜在的死循环等,40,静态分析,可提供的功能 提供间接涉及程序缺陷的信息：每一类型语句出现的次数、所用变量和常量的交叉引

16、用表、标识符的使用方式、过程的调用层次、违背编码规则等 为进一步查错作准备。,41,静态分析工具,说明 静态分析工具是一类实现静态分析方法的软件工具，通过对代码进行扫描并对其进行词法和语法分析，构造与代码结构特征相关的抽象模型以达到对代码进行某些方面分析的目的。,42,静态分析工具,基于数据流分析方法的静态分析工具，可提供的缺陷信息： 语法错误信息； 各种类型源语句出现的次数； 标识符使用的交叉索引； 标识符在每个语句中使用的各种情况，如数据源点、数据终点、调用参数、哑参数和下标等； 每个程序所调用的子程序和函数；,43,静态分析工具,可提供的缺陷信息： 6 未经初始化的变量； 7 未曾使用过的变量； 8 任何输入数据都执行不到的孤立代码段； 9 违背编码标准之处，包括背离语言标准以及用户制定的实用标准； 10 错用的全程变量、公用变量及参数表，如参数个数有误、类型不匹配、输入参数未经初始化、输出参数未赋值、输出参数虽赋值但未使用、对输入和输出均无用的参数等等。,44,静态分析工具,按工具来源分 商业工具 Klocwork Insight GIMPE