4测试基础-静态测试.ppt

* 测试基础 – 静态测试 测试基础 – 静态测试 概述 评审 代码检查 * 测试基础 – 静态测试 静态测试 该方法是指在不真正运行被测试程序的情况下检查程序的运行情况，只对被测对象(设计或代码)进行特性分析。 因此，静态测试常称为“分析”，静态分析是对被测对象进行特性分析的一些方法的总称。 主要特征 不动态运行程序； 充分发挥人的思维优势； 易开展，不需特别条件，但可能非常耗时； 对测试人员要求较高，要有编程经验，需要有知识和经验的积累，能发现问题本身而非征兆。 * 测试基础 – 静态测试 为什么要静态测试 因软件的复杂性，可能导致软件结构不够合理、混乱，代码编写不够规范，内部存在一些不易察觉的错等，使软件运行出错，维护不便。 静态测试内容 主要包括：各阶段的文档评审、代码检查、代码度量等。 静态测试可由人工进行，也可借助软件工具自动进行。? 可以做静态分析的工具很多，出名的有LOGICSCOPE，C++ ?TEST，LDRA ?TESTBED，PRQA ?C/C++，MACABE ?IQ，以及Rational的Purify、Quantify和PureCoverage等 ? * 测试基础 – 静态测试 概述 评审 代码检查 * 静态测试 评审 评审是对所有人工静态分析和具体文档检查技术的通称。 评审对象：开发项目中所有文档及项目外有价值的文档。 如：合同、需求定义、设计规格说明、程序代码、测试计划和手册等。 评审是一种保证质量的方法 评审的积极作用 可降低消除缺陷的成本 可缩短开发时间 可减少动态测试时间和成本 可减少系统安装后的变更申请 降低系统运行故障率 检查团对活动，改进团队成员的工作方法 * 静态测试 评审潜在的问题 注意不要使作者感到严格检查是针对他人而非他提交的文档。 评审的成本和收益 评审的成本大概占整个开发预算的10%~15%,包括评审过程、评审分析和过程改进的工作量。估计节约的成本约为14%~25%。（参见：Bush M. “Software Quality:The use of formal inspections at the Jet Propulsion Laboratory”，Proceedings of the 12th ICSE,IEEE 1990,pp 196-199.） 如评审有效，应能发现70%以上的文档缺陷。（参见：Gilb，T.，Graham,D.；Software Inspections，Addison-wesley,1996） * 静态测试 能促使评审成功的因素（[IEEE 1028]建议） 每次评审都事先定于一个明确的目标； 根据每个人的知识和技能水平选择合适的评审参与者。 * 静态测试 通用评审过程（参考：[IEEE 1028]） 评审活动分6个步骤：计划、概述、准备、检查（评审会议）、返工和跟踪。 计划 要评审的文档；评审技术；估算评审工作量；评审检查点；组建评审团队；确保文档处于一个可评审状态；会议的时间和地点（如有的话）等。 概述（开工会） 为参加评审的人提供所有必需信息。 准备 评审人必须各自为评审会议做准备。 * 静态测试 检查（评审会议） 会议应有主持人。 目的除了发现缺陷外，还包括判断评审对象是否满足需求以及是否符合标准。 评审会议的一些通用准则： 1）评审会议的时间限制在2小时内； 2）如有评审人缺席或准备不充分，主持人有权取消或中止会议； 3）检查对象是被提交的文档，而非作者； 评审人必须注意他们的言语及表达方式 作者不应为自己或文档辩护 4）主持人不应同时作为评审人； * 静态测试 检查（评审会议）（续） 5）不讨论常见的风格问题（方针之外的问题）； 6）开发方案和对应的讨论不是评审团队的任务； 7）每个评审人员必须有机会充分表达他们的论点； 8）会议纪要必须完整表达评审人的意见； 9）问题不应以命令的形式写给作者； 10）问题必须划分为不同的权重：严重缺陷、重要缺陷、一般缺陷、好的； 11）评审团队应对评审对象给出最后意见： 接受（无需修改） 有条件接受（需修改，但不需进一步评审） 不接受（需进一步评审或其他的检查） * 静态测试 检查（评审会议）（续） 12）要有会议纪要及总结 包括会议中讨论的问题或发现问题的列表，评审总结报告等。 返工 经理决定接受评审团队意见修正缺陷，或选择另外的方法（经理必须对此全权负责） 跟踪 专人跟踪缺陷的修改。 * 静态测试 评审角色和职责 经理 确保文档、必需的资源可用，同时选择评审人； 经理不一定得是管理层人员（导致大家“人心恍惚”） 主持人 管理评审有关的工作：计划、准备并保证评审有序进行且满足它的目标，收集评审数据、发布评审报告等。 作者 文档的创建者，如为多人，应是主要负责人。 不要把针