《《静态测试技术》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《静态测试技术》PPT课件.ppt（78页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、-静态测试技术静态测试技术软件测试方法和技术软件测试方法和技术由安博测试空间技术中心由安博测试空间技术中心http:/ 62303260 62303230静态测试的特点静态测试的特点静态测试不必动态的执行程序，也就是不必进静态测试不必动态的执行程序，也就是不必进行测试用例设计和结果判读等工作；行测试用例设计和结果判读等工作；静态测试可以由人手工方式进行，充分发挥人静态测试可以由人手工方式进行，充分发挥人的优势，行之有效。的优势，行之有效。解铃还须系铃人，由于人的思维及交流障碍而造成解铃还须系铃人，由于人的思维及交流障碍而造成的逻辑错误，有人通过逻辑思维去解决，是一种非的逻辑错误，有人通过逻辑思
2、维去解决，是一种非常有效的方法；常有效的方法；特别是在充分利用人思维互补的情形，检验出错误特别是在充分利用人思维互补的情形，检验出错误的水平非常高。的水平非常高。静态测试实施不需要特别条件，容易开展静态测试实施不需要特别条件，容易开展静态测试的内容静态测试的内容主要由人工进行主要由人工进行 代码审查代码审查(Code Inspection)代码走查代码走查(Walkthrough)桌面检查桌面检查技术审查技术审查主要由软件工具自动进行的静态分析主要由软件工具自动进行的静态分析 广义的理解，还包括软件需求分析和设广义的理解，还包括软件需求分析和设计阶段的技术评审计阶段的技术评审代码审查和代码走查
3、代码审查和代码走查由若干程序员与测试员组成一个小组，集由若干程序员与测试员组成一个小组，集体阅读并讨论程序，或者用体阅读并讨论程序，或者用“脑脑”执行并执行并检查程序的过程检查程序的过程 分两步完成分两步完成 预先作一定的准备工作预先作一定的准备工作 然后举行会议进行讨论然后举行会议进行讨论 会议的主题是发现错误而不是纠正错误会议的主题是发现错误而不是纠正错误桌面检查桌面检查程序员阅读自己所编的程序程序员阅读自己所编的程序 缺点：缺点：第一，由于心理上的原因，容易对自己的程序的偏第一，由于心理上的原因，容易对自己的程序的偏爱，没有发现错误的欲望（这和已经知道了程序错爱，没有发现错误的欲望（这和
4、已经知道了程序错了读程序找错误所在极为不同）了读程序找错误所在极为不同）第二，由于人的思维定势，有些习惯性的错误自己第二，由于人的思维定势，有些习惯性的错误自己不易发现不易发现 第三，如果根本对功能理解错了，自己不易纠正第三，如果根本对功能理解错了，自己不易纠正 所以这种方法效率不高，可作为个人自我检查所以这种方法效率不高，可作为个人自我检查程序中明显的疏漏或笔误程序中明显的疏漏或笔误代码审查与代码走查的优点代码审查与代码走查的优点不仅比桌面检查优越得多，而且与动态测试的不仅比桌面检查优越得多，而且与动态测试的方法相比也有很多优点方法相比也有很多优点 第一，使用这种方法测试，一旦发现错误，就知
5、道第一，使用这种方法测试，一旦发现错误，就知道错误的性质和位置，因而调试所花费的代价低错误的性质和位置，因而调试所花费的代价低 第二，使用这种方法一次能揭示一批错误，而不是第二，使用这种方法一次能揭示一批错误，而不是一次只揭示一个错误一次只揭示一个错误又，如果使用动态测试，通常仅揭示错误的征又，如果使用动态测试，通常仅揭示错误的征兆。兆。程序不终止运行，而对错误的性质和位置还得程序不终止运行，而对错误的性质和位置还得逐个查找。逐个查找。代码审查与代码走查的效果代码审查与代码走查的效果经验表明，使用这种方法能够优先的发现经验表明，使用这种方法能够优先的发现3070的逻辑设计和编码错误的逻辑设计和
6、编码错误IBM使用代码审查方法表明，错误的检测使用代码审查方法表明，错误的检测效率高达全部查出错误的效率高达全部查出错误的80Myers的研究发现代码审查和代码走查平的研究发现代码审查和代码走查平均查出全部错误的均查出全部错误的70%代码审查、代码走查与动态测试相互补充代码审查、代码走查与动态测试相互补充研究表明使用代码审查和代码走查发现某研究表明使用代码审查和代码走查发现某类错误比用动态测试更有效，而对另一类类错误比用动态测试更有效，而对另一类错误情况正好相反错误情况正好相反由此可见代码审查和代码走查方法与动态由此可见代码审查和代码走查方法与动态测试结合，测试效果更佳。测试结合，测试效果更佳
7、。代码审查的测试内容代码审查的测试内容检查代码和设计的一致性检查代码和设计的一致性检查代码对标准的遵循、可读性检查代码对标准的遵循、可读性检查代码的逻辑表达的正确性检查代码的逻辑表达的正确性检查代码结构的合理性检查代码结构的合理性代码审查的组成和方式代码审查的组成和方式代码审查由一组程序和错误检查技术组成代码审查由一组程序和错误检查技术组成以代码审查组方式组织以代码审查组方式组织代码审查组代码审查组 通常由四人组成，其中一人为组长通常由四人组成，其中一人为组长 组长是关键，最好是一个称职的程序员，但不是被测组长是关键，最好是一个称职的程序员，但不是被测试程序的编写者，也不需要对所检查的程序很熟
8、悉，但试程序的编写者，也不需要对所检查的程序很熟悉，但需要较强的组织协调和语言能力需要较强的组织协调和语言能力 组长的职责包括分配资料、安排计划、主持开会、记组长的职责包括分配资料、安排计划、主持开会、记录并保存被发现的错误录并保存被发现的错误 其余成员包括资深程序员、程序编写者与专职测试人其余成员包括资深程序员、程序编写者与专职测试人员员 根据测试的组织方式（如内部测试和独立测试）不同，根据测试的组织方式（如内部测试和独立测试）不同，代码审查小组组成可以调节，但组长角色不能变动代码审查小组组成可以调节，但组长角色不能变动代码审查的步骤代码审查的步骤准备准备程序阅读程序阅读审查会议审查会议跟踪
9、及报告跟踪及报告准备准备组长提前把程序目录表和设计说明书等材料分组长提前把程序目录表和设计说明书等材料分配给小组成员配给小组成员小组成员熟悉这些材料小组成员熟悉这些材料由被测程序的设计和编码人员向审查组详细说由被测程序的设计和编码人员向审查组详细说明所准备的材料，特别是代码的主要功能与功明所准备的材料，特别是代码的主要功能与功能间的关系能间的关系程序阅读程序阅读审查组人员仔细阅读代码和相关材料审查组人员仔细阅读代码和相关材料对照代码审查单标出明显缺陷及错误对照代码审查单标出明显缺陷及错误审查会议审查会议审查会由组长主持审查会由组长主持首先由程序员逐句阐明程序的逻辑，在此过程中可由程首先由程序员
10、逐句阐明程序的逻辑，在此过程中可由程序员或其他小组成员提出问题，追踪错误是否存在序员或其他小组成员提出问题，追踪错误是否存在经验证明在上述阐述过程中，有很多错误由讲述程序者经验证明在上述阐述过程中，有很多错误由讲述程序者而不是其他小组成员发现而不是其他小组成员发现大声地朗读程序给听众，这样简单的工作是有效的错误大声地朗读程序给听众，这样简单的工作是有效的错误检测技术检测技术然后利用代码审查单来分析讨论然后利用代码审查单来分析讨论组长负责讨论沿着建设性的方向前进，而其他人则集中组长负责讨论沿着建设性的方向前进，而其他人则集中注意力发现错误，但不去纠正错误注意力发现错误，但不去纠正错误跟踪和报告跟
11、踪和报告会后把发现的错误登记造表并交给程序开发人会后把发现的错误登记造表并交给程序开发人员员如果发现错误较多或发现重大错误，那么在改如果发现错误较多或发现重大错误，那么在改正之后，组长要再次组织审查会议正之后，组长要再次组织审查会议为了改进以后的审查工作，对错误登记表也要为了改进以后的审查工作，对错误登记表也要分析，归类和精炼分析，归类和精炼以第三方测试的方式进行代码审查以第三方测试的方式进行代码审查应就发现的缺陷及错误与软件开发人员讨论应就发现的缺陷及错误与软件开发人员讨论避免由于理解不一致产生问题，形成共同认可避免由于理解不一致产生问题，形成共同认可的审查结果的审查结果审查会议的时间审查会
12、议的时间大约以大约以1.52小时为宜小时为宜审查会需要高度集中注意力，时间太长反而容审查会需要高度集中注意力，时间太长反而容易使效率降低易使效率降低每次会议可能处理一个或几个模块每次会议可能处理一个或几个模块代码审查单代码审查单代码审查单是代码审查过程所用的主要技术代码审查单是代码审查过程所用的主要技术通常是把程序设计及编码中可能发生的各种错通常是把程序设计及编码中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型误进行分类，对每一类列举出尽可能多的典型错误，然后制成表格错误，然后制成表格其它测试中发现的错误也要及时归入代码审查其它测试中发现的错误也要及时归入代码审查单，形成某一类型软件
13、针对性的代码审查单，单，形成某一类型软件针对性的代码审查单，以供审查时使用以供审查时使用G.J.Myers的代码审查单（部分）的代码审查单（部分）数据引用错误数据引用错误是否引用了未赋值或者未初始化的变量？是否引用了未赋值或者未初始化的变量？所有的数组引用，其下标值是否都在各自的相应维所有的数组引用，其下标值是否都在各自的相应维数定义界内？数定义界内？所有的数组引用，每一个下表是否是整数值？所有的数组引用，每一个下表是否是整数值？所有引用的指针或变量当前是否已经分配储存了？所有引用的指针或变量当前是否已经分配储存了？（即是否存在（即是否存在“悬挂引用悬挂引用”的问题）的问题）在检索操作或下标引
14、用数组时，是否存在在检索操作或下标引用数组时，是否存在“差差1”的的错误？错误？To be continueG.J.Myers的代码审查单（部分）的代码审查单（部分）数据说明错误数据说明错误所有变量是否都显示地说明了？所有变量是否都显示地说明了？是否每个变量都赋予正常的长度、类型和存储分类是否每个变量都赋予正常的长度、类型和存储分类？变量的初始化和它的存储类型是否有矛盾？变量的初始化和它的存储类型是否有矛盾？To be continueG.J.Myers的代码审查单（部分）的代码审查单（部分）计算错误计算错误 是否使用过非一致的数据类型的变量进行运算？是否使用过非一致的数据类型的变量进行运算？
15、是否存在混合运算？是否存在混合运算？赋值语句的目标变量是否比其右边的表达式小赋值语句的目标变量是否比其右边的表达式小代码审查单的其他内容代码审查单的其他内容还可以包括编程风格、标准、规范的符合性方还可以包括编程风格、标准、规范的符合性方面的内容面的内容 在代码审查单的错误登记表中，应写明所查出在代码审查单的错误登记表中，应写明所查出的错误的类型、错误类别、错误的严重程度、的错误的类型、错误类别、错误的严重程度、错误的位置、错误的原因等信息。错误的位置、错误的原因等信息。阅读的方法阅读的方法要仔细阅读需求设计等文档，特别是了解软件要仔细阅读需求设计等文档，特别是了解软件的整体物理意义、应用背景以
16、及在大系统中的的整体物理意义、应用背景以及在大系统中的地位地位对大型软件而言，这些信息会在阅读程序时有对大型软件而言，这些信息会在阅读程序时有效地帮助读者从一定的高度审视，而不是停留效地帮助读者从一定的高度审视，而不是停留在逐行扫描代码在逐行扫描代码有些错误要有整体观才能发现有些错误要有整体观才能发现阅读结构化代码的两种方法阅读结构化代码的两种方法追踪通过每个子程序的主要逻辑行，主要逻辑追踪通过每个子程序的主要逻辑行，主要逻辑行全部跟踪完，然后开始跟踪第二条路径行全部跟踪完，然后开始跟踪第二条路径相当于深度优先遍历。相当于深度优先遍历。按排列顺序追踪代码，从主要行开始，然后检按排列顺序追踪代码
17、，从主要行开始，然后检查较低层的程序段查较低层的程序段相当于广度优先遍历相当于广度优先遍历两种阅读方法的综合使用两种阅读方法的综合使用这两种方式的差别在于何时进入下层模块，选这两种方式的差别在于何时进入下层模块，选择那种方式要视具体程序特点而定择那种方式要视具体程序特点而定广度优先遍历有助于很快地了解程序的全貌广度优先遍历有助于很快地了解程序的全貌深度优先适于详细查阅功能处理步骤深度优先适于详细查阅功能处理步骤应综合使用上述两种方法，在头一两遍阅读时，应综合使用上述两种方法，在头一两遍阅读时，采用广度优先，然后用深度优先采用广度优先，然后用深度优先程序阅读的次数程序阅读的次数Beizer提出至
18、少要读程序提出至少要读程序4次，分别针对印刷错次，分别针对印刷错误、数据结构、控制流和处理误、数据结构、控制流和处理4次阅读要比读一次能更快、更容易、更可靠的次阅读要比读一次能更快、更容易、更可靠的完成任务完成任务代码审查的辅助工具代码审查的辅助工具汇编或编译器生成的交叉引用表（变量、标号、汇编或编译器生成的交叉引用表（变量、标号、子程序）子程序）逆向工程工具（例如从源代码生成流程图）逆向工程工具（例如从源代码生成流程图）带有快速查找的编辑器带有快速查找的编辑器代码走查代码走查代码走查与代码审查相似，它也是由一组程序代码走查与代码审查相似，它也是由一组程序和错误检查技术组成，只是程序和错误检查
19、技和错误检查技术组成，只是程序和错误检查技术不完全相同。术不完全相同。代码走查组代码走查组 代码走查以小组方式进行代码走查以小组方式进行 代码走查组包括代码走查组包括 组长，类似代码审查组长组长，类似代码审查组长 秘书，负责记录发现的错误，要有一定水平秘书，负责记录发现的错误，要有一定水平 测试人员，应是具有经验的程序设计人员，或精通测试人员，应是具有经验的程序设计人员，或精通程序设计语言的人员，或从未介入被测试程序的设程序设计语言的人员，或从未介入被测试程序的设计工作的技术人员（这样的人没有被已有的设计框计工作的技术人员（这样的人没有被已有的设计框住），没有约束，比较容易发现问题。住），没有
20、约束，比较容易发现问题。代码走查的过程代码走查的过程与代码审查过程相似与代码审查过程相似先把材料交给每个小组人员，让他们认真研究先把材料交给每个小组人员，让他们认真研究程序，然后再召开代码走查会议。程序，然后再召开代码走查会议。代码走查会议的内容代码走查会议的内容与代码审查不同，不是读程序和使用代码审查单，而是与代码审查不同，不是读程序和使用代码审查单，而是由被指定的作为测试员的小组成员提供若干测试用例由被指定的作为测试员的小组成员提供若干测试用例（程序的输入数据和期望的输出结果），让参加会的成（程序的输入数据和期望的输出结果），让参加会的成员当计算机，在会议上对每个测试用例用头脑来执行程员当
21、计算机，在会议上对每个测试用例用头脑来执行程序，也就是用测试用例沿程序逻辑走一遍，并由测试人序，也就是用测试用例沿程序逻辑走一遍，并由测试人员讲述程序执行过程，在纸上或黑板上监视程序状态员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）（变量的值）每次开会时间以每次开会时间以12小时为宜，但不允许中断小时为宜，但不允许中断如果发现问题由秘书记下来，中间不讨论任何纠错问题，如果发现问题由秘书记下来，中间不讨论任何纠错问题，主要是发现错误主要是发现错误测试用例在代码走查中的作用测试用例在代码走查中的作用代码走查中，测试用例并不是关键，也并不是代码走查中，测试用例并不是关键，也并不是仅想验证
22、这几个测试用例运行是否正确，人脑仅想验证这几个测试用例运行是否正确，人脑毕竟比计算机慢太多毕竟比计算机慢太多这里这里测试用例是作为怀疑程序逻辑与计算错误测试用例是作为怀疑程序逻辑与计算错误的启发点，在随测试实例游历程序逻辑时，在的启发点，在随测试实例游历程序逻辑时，在怀疑程序的过程中发现错误怀疑程序的过程中发现错误这样，比几个测试用例本身直接发现的错误要这样，比几个测试用例本身直接发现的错误要多得多多得多代码走查中的缺点代码走查中的缺点代码走查使用测试用例启发检测错误，人们注代码走查使用测试用例启发检测错误，人们注意力会相对集中在随测试用例游历的程序逻辑意力会相对集中在随测试用例游历的程序逻辑
23、路径上，不如代码审查检查的范围广，错误覆路径上，不如代码审查检查的范围广，错误覆盖面全。盖面全。技术评审技术评审综合运用走查和审查技术，逐页、逐节地检查综合运用走查和审查技术，逐页、逐节地检查软件开发前期需求分析和设计的文档，对软件软件开发前期需求分析和设计的文档，对软件的需求，设计结构等方面提出问题的需求，设计结构等方面提出问题评审也被当作一种管理工具，经过评审不仅可评审也被当作一种管理工具，经过评审不仅可以提高各阶段软件产品的质量，还可以收集到以提高各阶段软件产品的质量，还可以收集到一些有关该软件产品质量的数据一些有关该软件产品质量的数据技术评审属于广义的测试范畴，也是一种质量技术评审属于
24、广义的测试范畴，也是一种质量保证手段保证手段软件开发过程中每个阶段的评审都必须十分正软件开发过程中每个阶段的评审都必须十分正规的，严格的加以定义，并根据规程实施。规的，严格的加以定义，并根据规程实施。静态测试的内容静态测试的内容针对不同的软件中间产品，静态测试的内容也针对不同的软件中间产品，静态测试的内容也不尽相同；不尽相同；对不同的文档进行静态测试的内容可以体现在对不同的文档进行静态测试的内容可以体现在对特定文档的测试对照条例中。对特定文档的测试对照条例中。下面以软件开发过程中的几个有代表性的主要下面以软件开发过程中的几个有代表性的主要文档和代码，列举静态测试的对照条例，以说文档和代码，列举
25、静态测试的对照条例，以说明静态测试的内容：明静态测试的内容：需求定义的静态测试对照条例需求定义的静态测试对照条例对需求定义的测试着重于测试对用户需求的描对需求定义的测试着重于测试对用户需求的描述和解释是否完整、准确；述和解释是否完整、准确；下面是根据有关标准整理而成的对需求定义进下面是根据有关标准整理而成的对需求定义进行静态测试的对照条例。我们把这些条例按照行静态测试的对照条例。我们把这些条例按照所测试的软件质量因素分成所测试的软件质量因素分成10组：组：To be continue需求定义的静态测试对照条例需求定义的静态测试对照条例兼容性兼容性界面需求是否使软硬件系统具有兼容性？界面需求是否
26、使软硬件系统具有兼容性？需求定义的静态测试对照条例需求定义的静态测试对照条例完备性完备性需求定义是否包含了有关文件（指质量手册、质量计划以及其它需求定义是否包含了有关文件（指质量手册、质量计划以及其它有关文件）中所规定的需求定义所应该包含的所有内容？有关文件）中所规定的需求定义所应该包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？的所有需求？功能性需求是否覆盖了所有非正常情况的处理？功能性需求是否覆盖了所有非正常情况的处理？是否对各种操作模式（如正常、非正常、有干扰等等）下的环境是否对各种操作模式（如正
27、常、非正常、有干扰等等）下的环境条件都作了规定？条件都作了规定？是否对所有功能与时间有关的方面都作了考虑？是否对所有功能与时间有关的方面都作了考虑？是否识别出了所有与时间因素有关的功能？它们的时间准则是否是否识别出了所有与时间因素有关的功能？它们的时间准则是否都说明了？都说明了？时间准则的最大、最小执行时间是否都定义了？时间准则的最大、最小执行时间是否都定义了？是否识别并定义了在将来可能会变化的需求？是否识别并定义了在将来可能会变化的需求？需求定义的静态测试对照条例需求定义的静态测试对照条例完备性（续）完备性（续）是否定义了系统所有的输入？是否定义了系统所有的输入？是否标识清楚了系统输入的来源
28、？是否标识清楚了系统输入的来源？是否识别出了系统的输出？是否识别出了系统的输出？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的值域、单位、格式等等？是否说明了系统输入、输出的值域、单位、格式等等？是否说明了如何进行系统输入的合法性检查？是否说明了如何进行系统输入的合法性检查？是否定义了系统输入、输出的精度？是否定义了系统输入、输出的精度？是否定义了系统性能的各个方面？是否定义了系统性能的各个方面？在不同负载情况下，系统的生产率如何？在不同负载情况下，系统的生产率如何？在不同的情况下，系统的响应时间如何？在不同的情况下，系统的响应时间如何？系统对软件、
29、硬件或电源故障必须作什么样的反应？系统对软件、硬件或电源故障必须作什么样的反应？是否充分地定义了关于人机界面的需求？是否充分地定义了关于人机界面的需求？需求定义的静态测试对照条例需求定义的静态测试对照条例一致性一致性各个需求之间是否一致？是否有冲突和矛盾？各个需求之间是否一致？是否有冲突和矛盾？所规定的模型、算法和数值方法是否相容？所规定的模型、算法和数值方法是否相容？是否使用了标准的术语和定义形式？是否使用了标准的术语和定义形式？需求是否与其软硬件操作环境相容？需求是否与其软硬件操作环境相容？是否说明了软件对其系统和环境的影响？是否说明了软件对其系统和环境的影响？是否说明了环境对软件的影响？
30、是否说明了环境对软件的影响？需求定义的静态测试对照条例需求定义的静态测试对照条例正确性正确性需求定义是否满足标准的要求？需求定义是否满足标准的要求？算法和规则是否有科技文献或其它文献作为基础？算法和规则是否有科技文献或其它文献作为基础？有哪些证据说明用户提供的规则或规定是正确的？有哪些证据说明用户提供的规则或规定是正确的？是否定义了对在错误、危险分析中所识别出的各种故是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？障模式和错误类型所需的反应？是否参照了有关的标准？是否参照了有关的标准？是否对每一个需求都给出了理由？理由是否充分？是否对每一个需求都给出了理由？理由是否充
31、分？对设计和实现的限制是否都有论证？对设计和实现的限制是否都有论证？需求定义的静态测试对照条例需求定义的静态测试对照条例可行性可行性需求定义是否使软件的设计、实现、操作和维护都可需求定义是否使软件的设计、实现、操作和维护都可行？行？所规定的模型、数值方法和算法是否对待解问题合适所规定的模型、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？是否能够在相应的限制条件下实现？是否能够达到关于质量的要求？是否能够达到关于质量的要求？需求定义的静态测试对照条例需求定义的静态测试对照条例易修改性易修改性对需求定义的描述是否易于修改（例如，是否采用良对需求定义的描述是否易于修改（例如，是否
32、采用良好的结构和交叉引用表等等）？好的结构和交叉引用表等等）？是否有冗余的信息？是否一个需求被定义多次？是否有冗余的信息？是否一个需求被定义多次？需求定义的静态测试对照条例需求定义的静态测试对照条例健壮性健壮性是否有容错的需求？是否有容错的需求？需求定义的静态测试对照条例需求定义的静态测试对照条例易追溯性易追溯性是否可从上一阶段的文档查找到需求定义中的相应内是否可从上一阶段的文档查找到需求定义中的相应内容？容？需求定义是否明确的表明前阶段中提出的有关需求和需求定义是否明确的表明前阶段中提出的有关需求和设计限制都已经被覆盖了？（例如，使用覆盖矩阵或设计限制都已经被覆盖了？（例如，使用覆盖矩阵或交
33、叉引用表）？交叉引用表）？需求定义是否便于向后继续开发阶段查找信息？需求定义是否便于向后继续开发阶段查找信息？需求定义的静态测试对照条例需求定义的静态测试对照条例易理解性易理解性是否每一个需求都只有一种解释？是否每一个需求都只有一种解释？功能性需求是不是以模块方式描述的，是否明确的标功能性需求是不是以模块方式描述的，是否明确的标识出了其功能？识出了其功能？是否有术语定义一览表？是否有术语定义一览表？是否使用了形式化或半形式化的语言？是否使用了形式化或半形式化的语言？语言是否有歧义性？语言是否有歧义性？需求定义中是否只包含了必要的实现细节而不包含不需求定义中是否只包含了必要的实现细节而不包含不必
34、要的实现细节？是否过分细致了？必要的实现细节？是否过分细致了？需求定义是否足够清楚和明确使其能够作为开发设计需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？规约和功能性测试数据的基础？需求定义的描述是否将对程序的需求和所提供的其它需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？信息分离开来了？需求定义的静态测试对照条例需求定义的静态测试对照条例易测试性和可验证性易测试性和可验证性需求是否可以验证？（即是否可以检验软件是否满足需求是否可以验证？（即是否可以检验软件是否满足了需求？）了需求？）是否对每一个需求都指定了验证过程？是否对每一个需求都指定了验证过程
35、？数学函数的定义是否使用了精确定义的语法和语义符数学函数的定义是否使用了精确定义的语法和语义符号？号？设计文档的静态测试对照条例设计文档的静态测试对照条例对设计文档的静态测试着重于分析设计是否与需对设计文档的静态测试着重于分析设计是否与需求定义一致，所采用的数值方法和算法是否适用求定义一致，所采用的数值方法和算法是否适用于待解问题，程序的设计中对程序的划分是否与于待解问题，程序的设计中对程序的划分是否与待解问题相适应，需求是否都被满足了等等。待解问题相适应，需求是否都被满足了等等。设计文档的静态测试对照条例设计文档的静态测试对照条例-完备性完备性软件设计规约是否包含了有关文件（指质量手册、软件
36、设计规约是否包含了有关文件（指质量手册、质量计划及其它有关文件）中所规定的所有内容质量计划及其它有关文件）中所规定的所有内容？是否有充分的数据（如逻辑结构图、算法、存储是否有充分的数据（如逻辑结构图、算法、存储分配图等）来保证设计的完整性？分配图等）来保证设计的完整性？算法、公式等是否充分、准确、完善？算法、公式等是否充分、准确、完善？是否在设计中明确地说明了产品的开发中所需要是否在设计中明确地说明了产品的开发中所需要的软件、硬件和测试所需要的软硬件？的软件、硬件和测试所需要的软硬件？对于每一个程序界面，设计是否都实现了所要求对于每一个程序界面，设计是否都实现了所要求的行为？的行为？To be
37、 continue设计文档的静态测试对照条例设计文档的静态测试对照条例-完备性完备性是否标识出了程序的每一个输入、输出和数据库是否标识出了程序的每一个输入、输出和数据库成分？其描述是否详细到了可以编码的程度了？成分？其描述是否详细到了可以编码的程度了？是否说明了程序的操作环境？是否说明了程序的操作环境？是否包含了所有的处理步骤？是否包含了所有的处理步骤？是否给出了每一个决策点的所有出口转向？是否给出了每一个决策点的所有出口转向？设计是否考虑到了所有可能的情况和条件？设计是否考虑到了所有可能的情况和条件？设计是否指明了在出现异常情况和不正当输入的设计是否指明了在出现异常情况和不正当输入的情况下的
38、行为？情况下的行为？设计是否参照了有关的设计标准？设计是否参照了有关的设计标准？设计文档的静态测试对照条例设计文档的静态测试对照条例一致性一致性在设计文档中，是否始终使用标准的术语和定义在设计文档中，是否始终使用标准的术语和定义？文档的风格和详细程度是否前后始终一致？文档的风格和详细程度是否前后始终一致？界面之间是否相容？界面之间是否相容？设计是否包含内在矛盾？设计是否包含内在矛盾？模型、算法和数值方法之间是否在数学上是相容模型、算法和数值方法之间是否在数学上是相容的？的？输入输出的格式是否一致？输入输出的格式是否一致？类似的功能和相关的功能的设计是否一致？类似的功能和相关的功能的设计是否一致
39、？计算中的输入、输出和数据库成分的计量单位和计算中的输入、输出和数据库成分的计量单位和计算精度是否一致？逻辑表达式是否一致？计算精度是否一致？逻辑表达式是否一致？设计文档的静态测试对照条例设计文档的静态测试对照条例正确性正确性设计文档是否满足有关标准的要求？设计文档是否满足有关标准的要求？设计是否只完成需求定义中要求的功能？若包含设计是否只完成需求定义中要求的功能？若包含额外的功能，则这些功能的必要性是否经过论证额外的功能，则这些功能的必要性是否经过论证？测试文档是否准确？测试文档是否准确？设计逻辑是否正确？即，程序是否会完成所需的设计逻辑是否正确？即，程序是否会完成所需的功能？功能？设计是否
40、与所描述的操作环境相一致？设计是否与所描述的操作环境相一致？界面的设计是否与文档所描述的界面部分一致？界面的设计是否与文档所描述的界面部分一致？对于设计者不能选择的输入输出和数据库成分的对于设计者不能选择的输入输出和数据库成分的数据格式、内容和数据率，设计是否正确地给予数据格式、内容和数据率，设计是否正确地给予了安排？了安排？设计文档的静态测试对照条例设计文档的静态测试对照条例可行性可行性所设计的模型、算法和数值方法对于应用领域来所设计的模型、算法和数值方法对于应用领域来说是否可以接受？说是否可以接受？设计能否在所规定的限制条件下和开发代价下实设计能否在所规定的限制条件下和开发代价下实现？现？
41、在可用的资源条件下，所设计的功能能实现吗？在可用的资源条件下，所设计的功能能实现吗？设计文档的静态测试对照条例设计文档的静态测试对照条例易修改性易修改性设计是否使用了信息隐藏技术？设计是否使用了信息隐藏技术？模块的组织使对一条需求的改变只影响较少的模块模块的组织使对一条需求的改变只影响较少的模块对于可能改变的数据与函数的结构的设计使它门的界面对对于可能改变的数据与函数的结构的设计使它门的界面对于单个函数的改变不敏感于单个函数的改变不敏感将数据结构的取接、数据库的取接和将数据结构的取接、数据库的取接和I/O的取接从应用程的取接从应用程序中分离开来，并使用专门的程序来完成之，不使用全局序中分离开来
42、，并使用专门的程序来完成之，不使用全局可取接的数据可取接的数据功能分解成一系列子程序，使每一个子程序都具有最大限功能分解成一系列子程序，使每一个子程序都具有最大限度的内部紧密联系和最低限度的互相依赖度的内部紧密联系和最低限度的互相依赖高内聚、低耦合高内聚、低耦合每一个子程序都只有一个功能吗？每一个子程序都只有一个功能吗？设计文档的静态测试对照条例设计文档的静态测试对照条例模块性模块性是否采用了模块化的机制？是否采用了模块化的机制？设计是否使软件系统由一系列相对来说较小的、设计是否使软件系统由一系列相对来说较小的、以层次结构相互联系的子程序组成？是否每一个以层次结构相互联系的子程序组成？是否每一
43、个子程序都只完成一个特定的功能？子程序都只完成一个特定的功能？设计是否使用了特殊的规则来限制子程序的大小设计是否使用了特殊的规则来限制子程序的大小？设计文档的静态测试对照条例设计文档的静态测试对照条例可预测性可预测性设计是否包含了子程序来提供在已经标识出的设计是否包含了子程序来提供在已经标识出的出错情况下所需的反应？出错情况下所需的反应？所设计的计算机资源调度方式是否是确定的和所设计的计算机资源调度方式是否是确定的和可预测的，而不是动态的？可预测的，而不是动态的？设计是否使用了尽量少的中断和事件驱动，对设计是否使用了尽量少的中断和事件驱动，对使用这样的功能是否进行了论证？使用这样的功能是否进行
44、了论证？是否设计了在程序的运行过程中进行正确性检是否设计了在程序的运行过程中进行正确性检查来发现运行时刻的错误和违反运行许可的情查来发现运行时刻的错误和违反运行许可的情况？况？设计文档的静态测试对照条例设计文档的静态测试对照条例结构化结构化设计是否使用了层次式的逻辑控制结构？设计是否使用了层次式的逻辑控制结构？设计文档的静态测试对照条例设计文档的静态测试对照条例易追溯性易追溯性设计文档中是否包含设计与需求定义中的需求、设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？设计限制等内容的对应关系？设计是否标识出了设计中所包含的需求定义之设计是否标识出了设计中所包含的需求定义之外的
45、功能？外的功能？是否对所有函数都进行了适当的标识使代码能是否对所有函数都进行了适当的标识使代码能够唯一地引用该标识？够唯一地引用该标识？设计规约是否包含修改历史记录，并使所有的设计规约是否包含修改历史记录，并使所有的对设计的修改和修改理由都记录在内并赋以编对设计的修改和修改理由都记录在内并赋以编号了？号了？设计规约是否包含了设计备案文档并记录了与设计规约是否包含了设计备案文档并记录了与设计有关的决策？设计有关的决策？设计文档的静态测试对照条例设计文档的静态测试对照条例易理解性易理解性设计是否避免了不必要的成分和表达形式？设计是否避免了不必要的成分和表达形式？设计文档是否不致造成歧义性解释？设计
46、文档是否不致造成歧义性解释？设计文档的静态测试对照条例设计文档的静态测试对照条例可验证性可验证性/易测试性易测试性设计中对每一个函数的描述是否都使用了良好设计中对每一个函数的描述是否都使用了良好的术语和符号？是否可以验证它与需求定义相的术语和符号？是否可以验证它与需求定义相一致？一致？是否定量地说明了使用条件、限制等内容？是是否定量地说明了使用条件、限制等内容？是否可以由此产生测试数据？否可以由此产生测试数据？源代码的静态测试源代码的静态测试对源代码的静态测试着重于分析实现是否正确、对源代码的静态测试着重于分析实现是否正确、完备。完备。源代码的静态测试对照条例源代码的静态测试对照条例完备性完备
47、性代码是否完全、准确地实现了设计规约中所规代码是否完全、准确地实现了设计规约中所规定的内容？定的内容？代码是否满足设计要求？代码是否满足设计要求？代码是否创建了所需的数据库或其它初始化数代码是否创建了所需的数据库或其它初始化数据？据？是否有未引用的或未定义的变量、常量或数据是否有未引用的或未定义的变量、常量或数据类型？类型？源代码的静态测试对照条例源代码的静态测试对照条例一致性一致性代码在逻辑上与设计规约一致吗？代码在逻辑上与设计规约一致吗？是否自始至终使用了相同的格式、调用约定、是否自始至终使用了相同的格式、调用约定、结构等等？结构等等？源代码的静态测试对照条例源代码的静态测试对照条例正确性
48、正确性代码是否符合标准？代码是否符合标准？变量的定义和使用都正确吗？变量的定义和使用都正确吗？注释是否正确？注释是否正确？子程序调用的参数个数正确吗？子程序调用的参数个数正确吗？源代码的静态测试对照条例源代码的静态测试对照条例易修改性易修改性代码中对常数的使用是否都通过符号来进行，代码中对常数的使用是否都通过符号来进行，使其便于修改？使其便于修改？是否有交叉引用表或数据字典来表明程序对常是否有交叉引用表或数据字典来表明程序对常量和变量的取接？量和变量的取接？代码是否由单入口、单出口的子程序构成？代码是否由单入口、单出口的子程序构成？（错误处理除外）（错误处理除外）代码是否避免了直接使用地址，而
49、采用标号和代码是否避免了直接使用地址，而采用标号和符号常量？符号常量？源代码的静态测试对照条例源代码的静态测试对照条例可预测性可预测性是否避免了使用自我修改的代码？是否避免了使用自我修改的代码？是否避免了依赖于程序设计语言中的缺省值的是否避免了依赖于程序设计语言中的缺省值的代码？代码？代码是否包含无穷循环？代码是否包含无穷循环？是否避免了递归？是否避免了递归？源代码的静态测试对照条例源代码的静态测试对照条例健壮性健壮性代码是否防止可以发现的运行时刻的错误？如代码是否防止可以发现的运行时刻的错误？如下标变量越界，除数为零，变量值越界，栈溢下标变量越界，除数为零，变量值越界，栈溢出等等出等等源代码
50、的静态测试对照条例源代码的静态测试对照条例结构化结构化程序的每一个功能是否都可以作为一块代码而程序的每一个功能是否都可以作为一块代码而识别出？识别出？循环是否只有一个入口？循环是否只有一个入口？源代码的静态测试对照条例源代码的静态测试对照条例易追溯性易追溯性是否有一个交叉引用表，通过它可以便捷地从是否有一个交叉引用表，通过它可以便捷地从代码找到相应的设计？代码找到相应的设计？是否有修改历史记录，它记录对代码的所有修是否有修改历史记录，它记录对代码的所有修改历史和修改原因？改历史和修改原因？源代码的静态测试对照条例源代码的静态测试对照条例易理解性易理解性注释是否使用简洁明了的语言对每一个子程序注