静态测试技术.pptVIP

程序阅读的次数Beizer提出至少要读程序4次，分别针对印刷错误、数据结构、控制流和处理4次阅读要比读一次能更快、更容易、更可靠的完成任务第30页，共78页，星期日，2025年，2月5日代码审查的辅助工具汇编或编译器生成的交叉引用表（变量、标号、子程序）逆向工程工具（例如从源代码生成流程图）带有快速查找的编辑器第31页，共78页，星期日，2025年，2月5日代码走查代码走查与代码审查相似，它也是由一组程序和错误检查技术组成，只是程序和错误检查技术不完全相同。第32页，共78页，星期日，2025年，2月5日代码走查组代码走查以小组方式进行代码走查组包括组长，类似代码审查组长秘书，负责记录发现的错误，要有一定水平测试人员，应是具有经验的程序设计人员，或精通程序设计语言的人员，或从未介入被测试程序的设计工作的技术人员（这样的人没有被已有的设计框住），没有约束，比较容易发现问题。第33页，共78页，星期日，2025年，2月5日代码走查的过程与代码审查过程相似先把材料交给每个小组人员，让他们认真研究程序，然后再召开代码走查会议。第34页，共78页，星期日，2025年，2月5日代码走查会议的内容与代码审查不同，不是读程序和使用代码审查单，而是由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）每次开会时间以1－2小时为宜，但不允许中断如果发现问题由秘书记下来，中间不讨论任何纠错问题，主要是发现错误第35页，共78页，星期日，2025年，2月5日测试用例在代码走查中的作用代码走查中，测试用例并不是关键，也并不是仅想验证这几个测试用例运行是否正确，人脑毕竟比计算机慢太多这里测试用例是作为怀疑程序逻辑与计算错误的启发点，在随测试实例游历程序逻辑时，在怀疑程序的过程中发现错误这样，比几个测试用例本身直接发现的错误要多得多第36页，共78页，星期日，2025年，2月5日代码走查中的缺点代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例游历的程序逻辑路径上，不如代码审查检查的范围广，错误覆盖面全。第37页，共78页，星期日，2025年，2月5日技术评审综合运用走查和审查技术，逐页、逐节地检查软件开发前期需求分析和设计的文档，对软件的需求，设计结构等方面提出问题评审也被当作一种管理工具，经过评审不仅可以提高各阶段软件产品的质量，还可以收集到一些有关该软件产品质量的数据技术评审属于广义的测试范畴，也是一种质量保证手段软件开发过程中每个阶段的评审都必须十分正规的，严格的加以定义，并根据规程实施。第38页，共78页，星期日，2025年，2月5日静态测试的内容针对不同的软件中间产品，静态测试的内容也不尽相同；对不同的文档进行静态测试的内容可以体现在对特定文档的测试对照条例中。下面以软件开发过程中的几个有代表性的主要文档和代码，列举静态测试的对照条例，以说明静态测试的内容：第39页，共78页，星期日，2025年，2月5日需求定义的静态测试对照条例对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确；下面是根据有关标准整理而成的对需求定义进行静态测试的对照条例。我们把这些条例按照所测试的软件质量因素分成10组：Tobecontinue……第40页，共78页，星期日，2025年，2月5日需求定义的静态测试对照条例兼容性 界面需求是否使软硬件系统具有兼容性？第41页，共78页，星期日，2025年，2月5日需求定义的静态测试对照条例完备性需求定义是否包含了有关文件（指质量手册、质量计划以及其它有关文件）中所规定的需求定义所应该包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？功能性需求是否覆盖了所有非正常情况的处理？是否对各种操作模式（如正常、非正常、有干扰等等）下的环境条件都作了规定？是否对所有功能与时间有关的方面都作了考虑？是否识别出了所有与时间因素有关的功能？它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了？是否识别并定义了在将来可能会变化的需求？第42页，共78页，星期日，2025年，2月5日需求定义的静态测试对照条例完备性（续）是否定义了系统所有的输入？是否标识清楚了系统输入的来源？是否识别出了系统的输出？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的值域、单位、格式等等？是否说明了如何进行系统输入的合法性