静态测试
静态测试概述
静态检查比如审查(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
类型：翻译