静态测试

静态测试概述

静态检查好比审查(reviews)和基于工具的代码和文档分析能够很好的改进质量。静态测试没有测试数据和测试执行。目的是发现缺陷和与规格说明书、相关标准及项目计划的误差，并能够优化开发流程。侧重于缺陷预防。

评审的对象为书面能够看到的内容，涉及合同、需求、设计规格、程序代码、测试计划、测试用例、测试报告、手册等等。一般须要须要各部门人员通力合做来完成。

评审系统地使用人的分析和思考能力来检查和评估问题。

审查是软件开发重要环节之一，也是测试活动之一，即静态测试——评审。借助审查保证用户需求在市场/产品需求文档及其相关文档中获得准确、完整、无歧义的反映，并使各种开发人员在需求理解上达成一致。

软件评审是对软件元素或者项目状态的一种评估手段，以肯定其是否与计划的结果保持一致，并使其获得改进。一般须要仔细阅读来理解和检查。相关标准参见IEEE 1028。

评审能减小缺陷、下降后期开发测试等成本，加强更多人员对产品和质量责任感的好处。据统计评审能够发现多达70%的缺陷，减小14–25%的研发时间。

评审须要有明确的目的、选择合适的评选者。

部分结构良好的文档，好比UML文档，可用先用工具发现一部分问题。

标准评审流程

标准的评审流程有计划，kick-off, 我的准备，评审会议、修正以及跟踪组成。

计划阶段管理层须要肯定哪些须要评审；评审须要什么技术；参与评审的人员；并和项目计划联系在一块儿。复杂的评审还须要创建进入和退出标准。评审未必会覆盖因此文档，因此还须要考虑不评审的风险。

kick-off：主要会议评审作材料和人员准备及培训等。并制定评审检查表。复杂的评审须要检查进入标准。

我的准备：参评者须要精读相关材料并准备好缺陷、问题和评论。

修正： 管理层对问题进行分析，确认哪些目前须要修改。

跟踪： 修改较大的状况下，须要第2次会议评审，通常只评审修改的部分。改动小的状况下可不开会离线评审。评审会议及其结果须要评估，以方便后期改进评审流程。检查表等也要适时调整。复杂的文档还须要检查退出准则。

评审会议： 一般由项目部主持，能够由其余懂得外交策略者代理。主持人全部专家能及时到场，确认评审会议的结果是接受或者须要改进甚至重写。

• 输出：小结报告（包含评审对象、与会者及角色、发现的问题简介、结论；发现的问题列表。

• 评审的规则：

• 评审会议一般不建议超过2个小时，并保证每间隔50分钟能休息10分钟，以保持你们的头脑清醒，提升效率。

• 与会者不能到场或者评审人员准备不充分，主持人能够取消或者中止评审。

• 评审的是文档等材料，而不是做者。与会人员尽可能保持公正，对事不对人。评审者要注意表达方式，尽可能避免冲突。做者不要竭力维护本身或者文档（可是能够解释）。

• 主持人不能参与具体评审。

• 不得讨论风格（手册以外的）等与主题无关的问题。

• 评审团队不讨论解决方案，这些会下整理好再另找时间讨论。

• 每一个评审者有机会充分展现本身及相关问题。

• 与会者达成的协议必须一致。

• 问题尽可能不能对做者的命令形式体现，尽可能以建议的方式展现。

• 分区域进行评审并有分级：Critical，Major，Minor，Good。

• 评审结论：Accept (不须要修改), Accept (须要修改，可是不须要评审)，Do not accept（须要从新评审）

• 评审者签名。

修正： 管理层对问题进行分析，确认哪些目前须要修改。

跟踪： 修改较大的状况下，须要第2次会议评审，通常只评审修改的部分。改动小的状况下可不开会离线评审。 评审会议及其结果须要评估，以方便后期改进评审流程。检查表等也要适时调整。复杂的文档还须要检查退出准则。

评审会议角色和责任

管理者：选择评审的对象及相关资源和人员，一般是技术总监组成。管理者通常不建议参加具体评审，以避免评审不能自由发挥，再者，管理者可能由于时间等缘由不真正了解技术细节。

主持人：执行评审，全流程跟踪，并发出评审报告。注意要保持中立。

做者：若是做者有多个，须要一个统筹负责。做者要明白评审是为了提升产品质量。

评审者：从不一样角度(好比开发、测试、架构、产品、运维等）评审对象，尽可能控制在5人之内。不一样的评审者可有不一样的分工。标准评审中，评审者须要在会前发送本身发现的问题和建议给主持人。

记录员：记录问题（难题、action、决定、建议等）。一般由做者兼任。

评审方法

审查：是最标准的评审流程。后面会有详细描述。其余评审都是它的精简。适用于主要的需求，设计和测试文档等。

结对评审：一般用户开发互相评审代码。能够没有会议，可是要深刻到文档的每一行。

走查：通常用于不是特别重要的文档，做者主持会议，讲述主要流程，好比代码走读。能够共同窗习提升。主持人须要抓住重点，深刻关键点。

轮查：相似于走查，可是只抽查部分流程。

非正式评审：能够没有会议的评审，一般用于部门内部，好比测试用例的组内评审。可是要有评审的纪要。

评审的技术

检查表、场景分析、头脑风暴和工具等

检查表（checklist）是一种经常使用的的质量保证手段，也是正式技术评审的必要工具，评审过程每每由检查表驱动。一份精心设计的检查表，对于提升评审效率、改进评审质量具备很大帮助。

• 可靠性。人们借助检查表以确认被检查对象的全部质量特征均获得知足，避免遗漏任何项目

• 效率。检查表概括了全部检查要点，比起冗长的文档，使用检查表具备更高的工做效率。

需求分类

需求分为功能性需求和非功能性需求，功能性的需求相对容易肯定，非功能性的需求难以肯定。

• 必须清楚需求

• 明确需求的优先级

• 需求分解得越细，对测试用例的设计质量越有帮助

• 需求仍是衡量测试覆盖率的重要依据

• 需求是规划具体项目资源和时间的基础。

功能性需求主要是根据产品规格说明书来检验被测试的系统是否知足软件各方面的功能的使用要求，包括用户界面的友好性。

• 程序安装、启动正常，有相应的提示框、错误提示

• 各项功能符合设计要求，正常运行并输出正确结果

• 功能逻辑合理，并能处理各类异常操做

• 能接受正确的数据输入，输出结果准确，格式清晰

• 系统的各类状态按照业务流程而变化并保持稳定

• 支持各类应用环境，能配合硬件设备

用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦

• 通用框架、浮动窗口和文字等总体布局合理

• 文字显示正常，且内容格式正确、美观。

• 色彩协调，风格先后一致，

• 文字标记和超连接能够打开和跳转成功

KISS – Keep it simple, stupid, Don’t make me think

• 非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不一样的项目类型差别较大。

• 客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。

• Web应用系统对性能、安全性等有很高要求

• 客户端/服务器应用系统。

• 大型复杂企业级系统。

SaaS (Software as a Service)是软件服务模式，厂商将应用软件统一部署在本身的服务器上，客户能够根据本身实际需求定购所需的应用软件服务。主要分为On-Demand Service和On-Premise Service。

• 软件运行的服务质量（QoS, Quality of service）

• QoS要求是指定某些系统特性的技术规范。

SaaS的非功能性需求：

• 性能要求，系统响应能力。

• 可用性, 7x24 不间断服务

• 可伸缩性，系统容量扩充能力，使系统能够支持来自扩大用户群体的额外负载。

• 安全性要求，肯定可能潜在的安全威胁并找处处理策略。

• 可维护性要求，对部署系统进行维护的难易程度，可维护性与可用性之间关系密切

正确理解需求的过程

见ppt上面的图

需求评审重要性

• 发现需求定义中的问题，尽早发现缺陷，下降劣质成本。

• 保证软件需求的可测试性。

• 与市场、产品、开发等相关人员在需求理解上认识一致，以避免后期的争吵。

• 更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。

• 肯定测试目标与范围。虽然此后需求会发生变动，但能获得有效控制，下降测试风险。

需求评审重要性

• 正确性

• 完备性

• 易理解性

• 一致性

• 可行性

• 易修改性

• 易测试性

• 易追溯性

详细准则请参考评审检查表

测试人员在需求评审中做用

需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，一般经过正式的评审会议来进行。而测试人员主要起着评审员的做用，检查需求定义是否合理和清楚。

• 明确本身的角色和责任

• 熟悉评审内容，为评审作好准备

• 针对问题阐述观点，而非针对我的

• 从客户角度想问题，多问几个为何

• 在会前或会后提出本身建设性的意见

• 对发现的问题跟踪到底

• 针对需求文档等报告问题

设计评审

成功的产品开发和演化依赖于体系结构恰当的选择。软件设计通常能够分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中获得准确和完整的表示，也就是保证产品规格说明书的质量。

• 系统架构的审查

• 设计规格说明书的审查

• 系统部署设计的审查

• 多层次审查:high-level及low-level

系统设计的评审标准

• 设计技术评审标准。稳定、清晰、合理

• 非功能性质量特性的设计评审要求。安全、性能、稳定、扩展、可靠。

• 评审的输入：体系结构文档、设计规范与指南、风险列表

• 评审的输出：经承认的软件体系结构文档、变动需求、评审记录

• 评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。

系统设计的评审标准

系统架构设计的基本要求就是保证系统具备高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中获得充分考虑。

采用分层评审和总体评审相结合，通过总体评审到分层评审、再从分层评审到总体评审的过程，这样既能确保评审的深度，又能确保评审的一致性

• 整个系统不该该存在单一故障点

• 系统是否创建了故障转移机制

• 是否创建了良好的负载平衡机制

• 关键业务 或关键任务 ？

组件设计的审查

• 功能和接口定义正确

• 算法的有效性和优化

• 合理的数据结构、数据流和控制流

• 可测试性 等

要特别注意模块的独立性，尽可能减小耦合性。

界面设计的审查

• 易懂性、易用性

• 一致性和规范性

• 美观与协调性

• 遵照惯例和通用法则

• 独特性

• 快捷方式的组合

• 自助功能

• 错误保护

UI标准中描述了字体 ，颜色搭配等规范。

界面设计的审查

系统部署设计的审查是基于软件服务的质量目标，用来审查软件部署的目标、策略是否合理，是否获得完全的执行。

• 着重是否服从和遵照部署设计的技术规范

• 逻辑设计的审查

• 物理设计的审查

• 可用性设计的审查

• 可伸缩型设计的验证

• 安全性设计的验证

静态分析

静态分析和评审相似，但使用了工具。前提是文档要遵循必定的格式，好比UML、HTML、XML等。通常在单元和集成测试阶段使用。通常的公司只有代码符合静态分析的标准。

静态分析可能会误报，建议使用时的输出信息从简单到详细。静态分析不能发现变量除零等动态错误，可是能发现违反编程规范、易出错的数据结构等问题。通常的编译器都有静态分析功能，还有专门的分析器，能发现的错误以下：

• 语法错误

• 违反编程标准和约定

• 控制流异常

• 数据流异常

• 安全隐患（缓冲区溢出及没有检查输入数据的边界等）

编译器

• 生成不一样的程序元素的交叉引用列表（例如，变量，函数）

• 严格检查数据和变量的数据类型使用

• 检测未声明的变量

• 检测dead代码

• 检测边界溢出

• 检查接口的一致性

• 检查跳转的label

约定和标准的符合性

好比python中的https://pypi.python.org/pypi/pep8和https://pypi.python.org/pypi/autopep8等。

数据流分析

主要分析数据流异常，好比变量未赋值就引用，或者变量从未使用。主要分为3类：Defined (d)、Referenced (r)、Undefined (u)。异常分类：

• ur-anomaly:读取未定义的变量

• du-anomaly：变量定义但未使用

• dd-anomaly：变量被连续赋值两次，第一次的赋值没有使用过

实例：

void exchange (int& Min, int& Max) {
  int Help;
  if (Min > Max) {
    Max = Help;
    Max = Min;
    Help = Min;
  }}

Help未赋值就引用；Max连续赋值2次；Help的最后赋值没有任何引用。

控制流分析

控制流中，单个或多个程序语句用节点表示，这些语句做为一个总体执行。程序执行的改变由if等语句决定，控制流程图能够清晰地看出控制流异常。控制流图一般用工具生成。若是部分图或者整个图很复杂，事件也难以理解，一般就须要调整。

维度计算：v(G) = e - n + 2。e为边数(edge),n为节点数(node)。McCabe建议维度尽可能不要超过10。 v(G) = cyclomatic number of the graph G e = number of edges of the control flow graph n = number of nodes of the control flow graph

参考资料

• 需求与设计的评审

• Rocky.Nook.Software.Testing.Foundations.4th.Edition.Mar.2014

• 做者博客：http://my.oschina.net/u/1433482

• 类型：翻译