4测试基础-态测试.pptVIP

* 测试基础 – 静态测试 纶革范吞脆指嘴嗽细排职坤劲变翠师志悉谊抵伤暖愧倪惧梆港薪腐帽罚酒4测试基础-态测试4测试基础-态测试 测试基础 – 静态测试 概述 评审 代码检查 * 蚌贿曹盛贷鸵雀衫呐灸添芽耐唁见扣钞迪宛卿猖凸踊塌沫孰数顺阐敦宣坍4测试基础-态测试4测试基础-态测试 测试基础 – 静态测试 静态测试 该方法是指在不真正运行被测试程序的情况下检查程序的运行情况，只对被测对象(设计或代码)进行特性分析。 因此，静态测试常称为“分析”，静态分析是对被测对象进行特性分析的一些方法的总称。 主要特征 不动态运行程序； 充分发挥人的思维优势； 易开展，不需特别条件，但可能非常耗时； 对测试人员要求较高，要有编程经验，需要有知识和经验的积累，能发现问题本身而非征兆。 * 偏镣串冗限姐匙恋象钒假知柳凌恕冤回碎汛涯摹住数聪您续斡邀独辈甜祖4测试基础-态测试4测试基础-态测试 测试基础 – 静态测试 为什么要静态测试 因软件的复杂性，可能导致软件结构不够合理、混乱，代码编写不够规范，内部存在一些不易察觉的错等，使软件运行出错，维护不便。 静态测试内容 主要包括：各阶段的文档评审、代码检查、代码度量等。 静态测试可由人工进行，也可借助软件工具自动进行。? 可以做静态分析的工具很多，出名的有LOGICSCOPE，C++ ?TEST，LDRA ?TESTBED，PRQA ?C/C++，MACABE ?IQ，以及Rational的Purify、Quantify和PureCoverage等 ? * 头老余咀表山鳃撂轩瑰庚艰捂妊份枢暗喝栖瑞堑愈佑境又块裙晴赞彤拆琅4测试基础-态测试4测试基础-态测试 测试基础 – 静态测试 概述 评审 代码检查 * 迭慌耍硬狡洱趁业咳哨乎茶裳啮犹襄行绪蝴鸟食链簇视涎诬鸽捶右伟凝或4测试基础-态测试4测试基础-态测试 静态测试 评审 评审是对所有人工静态分析和具体文档检查技术的通称。 评审对象：开发项目中所有文档及项目外有价值的文档。 如：合同、需求定义、设计规格说明、程序代码、测试计划和手册等。 评审是一种保证质量的方法 评审的积极作用 可降低消除缺陷的成本 可缩短开发时间 可减少动态测试时间和成本 可减少系统安装后的变更申请 降低系统运行故障率 检查团对活动，改进团队成员的工作方法 * 热蹲弃智蚤炸买胜腰茨税膜恐版嘎结灾柔俩纂坡褪绚希忆荚吟妒原俘缘冈4测试基础-态测试4测试基础-态测试 静态测试 评审潜在的问题 注意不要使作者感到严格检查是针对他人而非他提交的文档。 评审的成本和收益 评审的成本大概占整个开发预算的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） * 粮肤狐辱缀欣璃仿晓蚁膘妖腊谓浴岳侗柏音昔凑谱搭梆疹辐俱嫩敛茅妇引4测试基础-态测试4测试基础-态测试 静态测试 能促使评审成功的因素（[IEEE 1028]建议） 每次评审都事先定于一个明确的目标； 根据每个人的知识和技能水平选择合适的评审参与者。 * 就犯辟镊更客垢幼恩鲸旋咨逝哆苦遂套杠淑辛己棠饯坎荐栈珠赌缅寝溜脑4测试基础-态测试4测试基础-态测试 静态测试 通用评审过程（参考：[IEEE 1028]） 评审活动分6个步骤：计划、概述、准备、检查（评审会议）、返工和跟踪。 计划 要评审的文档；评审技术；估算评审工作量；评审检查点；组建评审团队；确保文档处于一个可评审状态；会议的时间和地点（如有的话）等。 概述（开工会） 为参加评审的人提供所有必需信息。 准备 评审人必须各自为评审会议做准备。 * 蛔芜备郧础卧黑篡褒疚推样里调懂晕桶崇轰鼎仔耳摆大塞伤盲恤惋撼础裹4测试基础-态测试4测试基础-态测试 静态测试 检查（评审会议） 会议应有主持人。 目的除了发现缺陷外，还包括判断评审对象是否满足需求以及是否符合标准。 评审会议的一些通用准则： 1）评审会议的时间限制在2小时内； 2）如有评审人缺席或准备不充分，主持人有权取消或中止会议； 3）检查对象是被提交的文档，而非作者； 评审人必须注意他们的言语及表达方式 作者不应为自己或文档辩护 4）主持人不应同时作为评审人； * 澈汐拿炯呀么刽针凸汲奶颁敬笆满正徊益小痉攘杀咆绅运埋衰萝憨途诀洋4测试基础