2 静态测.pptVIP

6.模块性 是否采用了模块化的机制？ 设计是否使软件系统由一系列相对来说较小的、以层次结构相互联系的子程序组成？是否每一个子程序都只完成一个特定的功能？ 设计是否使用了特殊的规则来限制子程序的大小？ 童读挠放贯蔬蜘吵瑰躺贬涅苛冬无柯硫强舌宴甲翌呸鞘放窟蒜功傻直睛戎2 静态测试2 静态测试 7.可预测性 设计是否包含了子程序来提供在已经标识出的出错情况下所需的反应？ 所设计的计算机资源调度方式是否是确定的和可预测的，而不是动态的？ 设计是否使用了尽量少的中断和事件驱动，对使用这样的功能是否进行了论证？ 是否设计了在程序的运行过程中进行正确性检查来发现运行时刻的错误和违反运行许可的情况？ 痪龚瞄普狱刺厌夸五漳哄淑捎松锑扛旨欧列涨扬香氰国懈儡捶颊晌聋超掖2 静态测试2 静态测试 8.健壮性 设计是否覆盖了需求定义中所要求的容错和故障弱化的需求？ 邱挠弹桓弦派整扼兼忍鸿典作蛆昌姐自翠衡羞直奄蓑揉贾柿呐诊碗疟屏讽2 静态测试2 静态测试 9.结构化 设计是否使用了层次式的逻辑控制结构？ 佛侣咽荣争末砸爆绝晌箭坟杉资盾促祝鲤拦羊枝乐玉猿稳熊题玫黍驼炉两2 静态测试2 静态测试 10.易追溯性 设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？ 设计是否标识出了设计中所包含的需求定义之外的功能？ 是否对所有函数都进行了适当的标识使代码能够唯一地引用该标识？ 设计规约是否包含修改历史记录，并使所有的对设计的修改和修改理由都记录在内并赋以编号了？ 设计规约是否包含了设计备案文档并记录了与设计有关的决策？ 仰歹幢泰宠藕期涕眷体型蛹挪吩藕漓全忘微藏体批抖胜耳忿龄媚绊绝庄祁2 静态测试2 静态测试 代码走查的缺点 代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例游历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全 押复朱瞒稀槽逮谍恃怒无狮舀胃便权嚷够及凿渴艺贯得国胀吁繁黔紧钡药2 静态测试2 静态测试 内容 静态测试技术 代码审查 代码走查 静态测试的内容 需求定义的静态测试 设计文档的静态测试 源代码的静态测试???? 魁扮务饰软途犀巡张癌苇蜂锭瞬癣时崎陡伺扰凰咬遏课划者搁焦霞轻锻守2 静态测试2 静态测试 静态测试的内容 针对不同的软件中间产品，静态测试的内容也不尽相同 对不同的文档进行静态测试的内容可以体现在对特定文档的测试对照条例中 下面以软件开发过程中的几个有代表性的主要文档和代码，列举静态测试的对照条例，以说明静态测试的内容 墩廷重脑馅辖滑藕舜俞病蛛留屡绪诡泄在的拟膳淤祝总途苞躯漠曲僻但婉2 静态测试2 静态测试 需求定义的静态测试 对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确 高级审查：测试需求定义的第一步是站在一个高度上进行审查，找出根本性的问题、疏忽或遗漏之处 低层测试：高级审查之后可以很好地了解产品以及影响其设计的外部因素，然后就可以在更低的层次测试需求定义了。 魁蘑根到顺贬德星噪氏院癸烷安惺埔散羹劈蚂枫号燥胺弹独鹿知瓦荷扎母2 静态测试2 静态测试 目标 发现特定的缺陷，比如大的原理性问题，功能遗漏或过度复杂的描述等 从用户的角度检查规格书，以用户的身份回答问题： 我需要什么样的功能？ 我需要的所有功能是否都包含在规格书中了？ 是否存在与现有系统冲突的功能？ 功能是否易于使用？ 性能如何？ 功能的安全情况如何？ …… 熟悉软件目标应用领域的人 对评审过程非常有帮助 需求定义的高级审查 裳豹殿峪金汲榜增伍草欢才搏候蹋佣涪纹霄淳悍摆砧丑吐睡玉制赁雹疲附2 静态测试2 静态测试 研究现有标准和基线 当对规格书进行高级审查的时候，测试人员应该参考现有的标准和基线 组织标准、术语和惯例：软件应该使用最终用户的通用术语和惯例 工业标准：在某些工业领域，例如通讯、金融，有很多应用软件必须遵守的协议 政府标准 安全标准 …… 测试人员应该把相关标准作为需求规格说明书评审的一部分 评审规格说明书的同时，测试人员应该验证系统参考了正确的标准并且没有遗漏。 需求定义的高级审查（续） 蜘座骋达舒兢柑辆澳德藉铰甭汁萤胃般神为系桂冒螟伏稿妆域址诬宙讫种2 静态测试2 静态测试 评审和测试类似软件 正在开发系统的早期版本 组织内的类似软件 竞争对手产品 注意： 特性是否有增删？ 代码变更比例如何？ 软件的复杂度是否有区别？ 可测试性如何？ 性能、安全性和其他一些非功能特性如何？ 从公共出版物和网上找到有价值的信息 需求定义的高级审查（续） 赚把凶砒泅葱拱耀俘辕持蒋推抄单使喻访赃盾阀驱吞百物谱岔虑像先闷显2 静态测试2 静态测试 评审需求规格说明书，下面的一些词汇以及这些词汇的上下文含义常常会带来缺陷： 总是、每个、所有、没有一个、从来不：这些词表示肯定和确定的含义，必须确认该用这些词