第2章软件测试基本技术.pptVIP

软件测试技术 ——静态测试与动态测试 软件测试方法 静态方法和动态方法 静态方法的主要特征是对测试对象测试时，不真正运行被测试的对象，只对被测对象进行特性分析。 动态方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析。 静态测试 测试对象：各种与软件相关的有必要测试的产物，如各类文档、源代码等。 静态测试包括：评审、静态分析等 评审：对软件元素或项目进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见。 通常由人来执行 静态分析:被测程序进行特性分析的一些方法的总称。 通常需要工具辅助 V模型的评审时间点 静态测试——评审方法 同行审查（peer to peer Review） 走查 （Walk Through） 会议审查（Inspection） 同行评审（peer Review） 由开发软件产品以外的其他人检查工作产品。 评审参与者主要采用一行一行阅读被审对象的形式发现被测对象中的缺陷。 例如：基于代码的同行评审 走查 （Walk Through） 会议审查 （Inspection） 静态测试——会议审查 评审的技术 走查与审查的比较 问题 需求缺陷 缺陷修复代价 需求评审重要性的直观描述 需求评审重要性表现方面 发现需求定义中的问题，尽早发现缺陷，降低劣质成本。 保证软件需求的可测试性。 与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。 更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。 确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。 测试需求 功能性测试需求 用户界面及其显示要求 非功能性需求 软件即服务SaaS SaaS的非功能性需求 正确理解需求的过程 需求评审的标准 正确性 完备性 易理解性 一致性 可行性 易修改性 易测试性 易追溯性 需求规格说明书评审 多层次审查:high-level ? low-level 分类别审查 分阶段审查 不应该使用含义模糊的表述，如： 有时，多数情况下，一般，可能，差不多，较好等 所有术语均应有明确的定义，消除歧义。 同一术语不要描述意义不同的多个对象，同一对象尽量只对应一个术语。 设计评审 系统设计的评审标准 设计技术评审标准。稳定、清晰、合理 非功能性质量特性的设计评审要求。安全、性能、稳定、扩展、可靠。 评审的输入：体系结构文档、设计规范与指南、风险列表 评审的输出：经认可的软件体系结构文档、变更需求、评审记录 评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。 系统架构设计的审查 组件设计的审查 界面设计的审查 系统部署设计的审查 静态测试——代码检查 代码检查包括代码走查、桌面检查、代码审查等 代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷； 代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等 检查内容： 代码与详细设计的一致性 代码是否与标准规范相符 可读性如何 代码的逻辑表达是否正确 代码结构的合理性 编码规范和代码检查表 编码规范 编码规范是代码编写过程中必须遵守的规则。 不同的编码语言和项目团队可能采用不同的标准和基线，适合项目的就是最好的 代码检查表 代码检查表是对应于编码规范中的各个标准与规范开发的检查项，包含容易出错和以往在工作中遇到的典型错误，可以认为是在进行代码评审时用到的测试用例。 在进行代码评审时，评审专家会关注被评审代码是否符合检查表规范，如果不符合则很可能存在缺陷。 编码规范和检查表应该在一个项目完成后被检验和更新。 静态测试——代码检查 定义 是不执行程序，对被测程序进行特性分析的一些方法的总称，一般借助工具进行。 可提供的功能包括: 发现代码中的缺陷，包括： 用错的局部变量和全局变量 不匹配的参数 不适当的循环嵌套和分支嵌套 不适当的处理顺序 无终止的死循环 未定义的变量 不允许的递归 调用不存在的子程序 遗漏了标号或代码 不恰当的连接 可提供的功能 找到潜伏着的缺陷 未使用的变量 不会执行到的代码 未引用过的标号 可疑的计算 潜在的死循环 提供间接涉及程序缺陷的信息：每一类型语句出现的次数、所有变量和常量的交叉引用表、标识符的使用方式、过程的调用层次、违背编码规则等。 为进一步查错作准备。 静态测试工具 直接对代码进行语法扫描、分析，生成系统的调用关系图，找出不符合编码规范的地方 PC-Lint ： C/C++代码静态分析工具 LogiScope：C/C++、Java、Ada代码静态分析工具 PMD：一种开源、分析Java代码错误的工