2 静态测试.ppt

6.模块性 是否采用了模块化的机制？ 设计是否使软件系统由一系列相对来说较小的、以层次结构相互联系的子程序组成？是否每一个子程序都只完成一个特定的功能？ 设计是否使用了特殊的规则来限制子程序的大小？ 7.可预测性 设计是否包含了子程序来提供在已经标识出的出错情况下所需的反应？ 所设计的计算机资源调度方式是否是确定的和可预测的，而不是动态的？ 设计是否使用了尽量少的中断和事件驱动，对使用这样的功能是否进行了论证？ 是否设计了在程序的运行过程中进行正确性检查来发现运行时刻的错误和违反运行许可的情况？ 8.健壮性 设计是否覆盖了需求定义中所要求的容错和故障弱化的需求？ 9.结构化 设计是否使用了层次式的逻辑控制结构？ 10.易追溯性 设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？ 设计是否标识出了设计中所包含的需求定义之外的功能？ 是否对所有函数都进行了适当的标识使代码能够唯一地引用该标识？ 设计规约是否包含修改历史记录，并使所有的对设计的修改和修改理由都记录在内并赋以编号了？ 设计规约是否包含了设计备案文档并记录了与设计有关的决策？ 11.易理解性 设计是否避免了不必要的成分和表达形式？ 设计文档是否不致造成歧义性解释？ 12.可验证性/易测试性 设计中对每一个函数的描述是否都使用了良好的术语和符号？是否可以验证它与需求定义相一致？ 是否定量地说明了使用条件、限制等内容？是否可以由此产生测试数据？ 内容 静态测试技术 代码审查 代码走查 静态测试的内容 需求定义的静态测试 设计文档的静态测试 源代码的静态测试???? 源代码的静态测试 对源代码的静态测试着重于分析实现是否正确、完备 1.完备性 代码是否完全、准确地实现了设计规约中所规定的内容？ 代码是否满足设计要求？ 代码是否创建了所需的数据库或其它初始化数据？ 是否有未引用的或未定义的变量、常量或数据类型？ 2.一致性 代码在逻辑上与设计规约一致吗？ 是否自始至终使用了相同的格式、调用约定、结构等等？ 3.正确性 代码是否符合标准？ 变量的定义和使用都正确吗？ 注释是否正确？ 子程序调用的参数个数正确吗？ 4.易修改性 代码中对常数的使用是否都通过符号来进行，使其便于修改？ 是否有交叉引用表或数据字典来表明程序对常量和变量的取接？ 代码是否由单入口、单出口的子程序构成？（错误处理除外） 代码是否避免了直接使用地址，而采用标号和符号常量？ 5.可预测性 是否避免了使用自我修改的代码？ 是否避免了依赖于程序设计语言中的缺省值的代码？ 代码是否包含无穷循环？ 是否避免了递归？ 6.健壮性 代码是否防止可以发现的运行时刻的错误？如下标变量越界，除数为零，变量值越界，栈溢出等等 7.结构化 程序的每一个功能是否都可以作为一块代码而识别出？ 循环是否只有一个入口？ 8.易追溯性 是否有一个交叉引用表，通过它可以便捷地从代码找到相应的设计？ 是否有修改历史记录，它记录对代码的所有修改历史和修改原因？ 9.易理解性 注释是否使用简洁明了的语言对每一个子程序都作了充分的描述？ 是否有不必要地复杂的代码？若有，是否使用了注释对其进行解释？ 是否使用了一致的格式（如缩进和空格的使用）？ 是否使用了便于记忆的命名约定？命名是否反映了变量的类型？ 匈牙利命名法 变量的有效值域是否定义了？ 代码中的公式是否使用了设计规约中相应数学模型的公式？ 10.可验证性 实现是否避免了使用测试难度大的技术和方法？ 对照条例的说明 对照条例并不是一成不变的 在静态测试的实践中，对照条例可根据实际情况进行适当的增减 特定的应用领域和特定的开发方法都会对静态测试提出一些特定的要求，这些要求可以正确地反映在静态测试的对照条例之中 回顾 静态测试技术 代码审查 代码走查 静态测试的内容 需求定义的静态测试 设计文档的静态测试 源代码的静态测试???? 指针的值是一块内存区域的地址。使用指针要求，它的值必须是指向一块分配给你使用的地址，且使用的内存不能超过它分配时的大小。 所谓指针悬挂是指指针指向了一块没有分配给用户使用的内存。指针悬挂一般可能是由于指针未初始化，或指针拷贝后删除了指针等原因造成。 * 代码走查的缺点 代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例游历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全 内容 静态测试技术 代码审查 代码走查 静态测试的内容 需求定义的静态测试 设计文档的静态测试 源代码的静态测试???? 静态测试的内容 针对不同的软件中间产品，静态测试的内容也不尽相同 对不同的文档进行静态测试的内容可以体现在对特定文档的测试对照条例中 下面以软件开发过程中的几个有代表性的主要文档和代码，列举静态测试的对照条例，以说明静态测试的内容 需