全部科目 > 软件评测师 >
2019年下半年 上午试卷 综合知识
第 56 题
知识点 测试策略   软件测试策略   软件生命周期测试策略   生命周期  
章/节 软件测试类型  
 
 
以下关于软件生命周期测试策略的叙述中，不正确的是（ ）。
 
  A.  在软件分析阶段进行需求说明书评测
 
  B.  在软件概要设计阶段进行概要设计说明书评测
 
  C.  在软件详细设计阶段进行详细设计说明书评测
 
  D.  在软件开发阶段进行编码规范评测
 
 




 
 
相关试题     软件生命周期测试策略 

  第9题    2010年下半年  
软件设计阶段一般又可分为（9)。

  第64题    2012年下半年  
以下关于系统测试的叙述，不正确的是（64）。

  第52题    2018年下半年  
集成测试的集成方式不包括( )。

 
知识点讲解
· 测试策略
· 软件测试策略
· 软件生命周期测试策略
· 生命周期
 
        测试策略
        由于标准符合性测试的不同分类，其相应的测试原理也不尽相同。
               数据内容类标准
               如《教育管理信息化标准》（第1部分《学校管理信息标准》），在测试工具设计上，其实现原理如下所示。
               . 将符合标准的信息集（表结构）与代码集（表内容）构建在测试工具数据库中，即建立标准模板；
               . 测试工具通过ODBC、JDBC等数据库连接方式连接被测软件的数据库；
               . 测试工具提供人工或自动方式建立模板库与被测库之间的关联，读取并验证相关数据表信息；
               . 生成信息集与代码集标准符合性检测结果报告。
               注意，在实际应用中，从易维护的角度出发，被测软件的代码集可能不是多个不同类别的小代码表集，而是一个包含各种类别的大代码表，但测试工具模板库往往是多个不同类别的小代码表集，这就要求测试工具能够实现一对多或多对多的关联设置。
               而对于检察机关网络应用软件的数据格式规范与代码符合性规范的测试工具，可采用网上已有的相关工具或自行开发。如数据格式规范测试可辅助采用已有的XML解析器进行，而代码符合性规范可采取自行开发测试工具方式执行，测试步骤包括工具中建立标准模板、连接被测软件、与标准模板比对测试和输出测试结果。
               通信协议类标准
               测试工具的实现原理与第一类标准基本相似，如中国远程教育CELTS-20教学管理标准中的，基于HTTP协议绑定规范的，测试工具可以这样实现：①建立标准模拟课件；②导入模拟课件到被测平台；③测试工具自动运行模拟课件，主动与被测平台进行数据通信；④将二者通信内容与工具中的标准模板内容进行比较，得出比较分析结果。
               开发接口类标准
                      SQL标准符合性测试
                      按照SQL92/97标准，全面测试一个SQL产品的功能特性。在详细研究美国标准技术研究所（NIST）的测试用例库（即在整个测试过程中，只需要执行全部的测试用例文件，最后统计通过的测试用例即可）的基础上，可自行开发一个集测试和结果的定量分析于一体的自动化测试工具，利用该测试工具可以直接选择被测文件，运行并统计运行的结果。
                      通过的入门级测试用例数占入门级测试用例总数的比例，即为入门级测试通过率。通过的过渡级测试用例数占过渡级测试用例总数的比例，即为过渡测试通过率。
                      为了保证测试结果的真实性，还可采用交互式测试用例验证测试结果，如果发现问题，则相应的嵌入式测试用例的结果视为不通过。
                      ODBC标准
                      可采用SWsoft Inc开发的ODBC2.5标准符合性测试工具进行测试。在此基础上，按照ODBC3.0标准对测试用例进行相当规模的修改和扩充，并且将微软的QUICK TEST测试工具的部分模块集成到该测试工具中，同时对测试结果进行了定量的分析。
                      其中，对API函数的测试，参照微软的测试工具（QuickTest）对每个函数选定一种最简单的参数组合来测试，仅用其作简单的支持性测试。此项测试根据通过测试的函数的百分比来计算。对于其他的更重要的应用功能，是通过其他更详细、更复杂的测试用例来验证的，其执行结果的成功与否直接记录为测试结果。
                      JDBC标准
                      可在SUN公司开发的JDBC标准符合性测试工具基础上，按照JDBC3.0标准对测试用例进行修改和扩充，同时加入对测试结果的定量分析功能。
                      JDBC标准符合性测试完成后，统计各个接口或类中API函数通过的测试用例点的数量，按用例通过的比例和每个类或接口所占的权值计算总体得分。
               信息编码类标准
               例如，对GB 18030中文符合性测试，包括字汇完整性和体系正确性两方面。
               对于字汇完整性可采用抽样测试的方法，其过程如下。
               . 生成标准测试文件。即依照GB 18030的字符集生成字符数据文件（如.TXT），包括GB 18030中定义的全部汉字区、符号区、保留区和用户自定义区。
               . 运行被测软件，打开已生成的标准文本文件，将屏幕显示内容与GB 18030中指定内容进行对比，记录屏幕显示对比结果。
               . 运行待测软件，打开已生成的文本文件并打印其内容，将打印结果与GB 18030中指定内容进行对比，记录打印对比结果。
               . 抽样对比。例如：抽样方法可定义为单字节抽样率达到100%，双字节1区抽样率达到约20%，双字节2区抽样率达到约15%，双字节3区抽样率达到约10%，双字节4区抽样率达到约5%，双字节5区抽样率达到约20%和四字节区抽样率达到约5%。抽样范围包括边界字符和中间随机字符，如有错误则抽样率加倍，直至抽样率达到100%。各区矩阵的抽样率均应达到100%。抽样对比测试办法如下：单字节区，逐字对比。双字节1～5区，以第一字节相同的所有字符构成一个矩阵为一个检查单位，每矩阵抽查第一个字符、最后一个字符，在其他字符中按前述抽样率随机抽查数个字符，如果被抽样字符中出现对比结果不符合现象，或发现明显的“？”、方框、连续空白，则按前述抽样方法进行。双字节用户区1～3，与用户文档中承诺的用户自定义字符列表或用户自定义界面的输入结果进行对比，抽样率为10%；如没有用户自定义字符，则应不显示字符。四字节区，每区抽查第一个字符、最后一个字符，在其他字符中随机抽查数个字符（区抽样率≥5%），如果被测字符中出现对比结果不符合现象，或发现明显的“？”、方框、空白，则对比整个矩阵。
               对于体系正确性测试，其测试过程包括：
               . 生成随机文件，即从GB 18030定义的全部字符中随机抽取，而形成的大于5000字符的文本。文本中包括单字节区、各双字节区、四字节区中的字符，所有字符随机组合。
               . 编辑处理，即在被测的软件平台上，将已生成的随机文件打开，并进行编辑处理，包括插入字符、删除字符、存储字符、复制粘贴、打印等操作，各类操作均包括单字节区、各双字节区、四字节区中的字符。
               . 记录结果，即记录编辑处理文本文件的结果。
               对于字汇完整性，符合以下所有条件的，字汇完整性成绩为通过，其他情况为不通过。
               . 单字节区显示和打印的符合率均等于100%。
               . 双字节各区显示和打印的符合率均大于98%。
               . 四字节区显示和打印的符合率均大于97%。
               对于体系正确性，插入字符、删除字符、存储字符、复制粘贴、打印等编辑操作处理正确为通过，出现乱字符、多字符、丢字符或其他影响编辑操作的处理结果为不通过。只有在字汇完整性与体系正确性的成绩均为通过时，总成绩为通过。其他情况为不通过。
               目前，由于GB 18030的测试主要依靠人工验证，所以测试过程相对繁琐一些。
 
        软件测试策略
        测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。如下图所示显示出软件测试经历的4个步骤。
        
        软件测试的过程
        开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。
               测试信息流
               测试信息流如下图所示。测试过程需要以下三类输入。
               
               测试信息流
               软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。
               测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。
               测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。
               测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。
               排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。
               通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍。
               分析设计阶段
               分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。
                      需求说明书评测
                      由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
                      因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
                      什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
                      . 编制良好的需求说明书8条原则。
                      1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
                      原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
                      原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
                      原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
                      原则4：规格说明必须包括系统运行的环境。
                      原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
                      原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
                      原则7：规格说明必须容许不完备性并允许扩充。
                      原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。
                      尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。
                      . 需求说明书的框架。
                      需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。
                      
                      需求说明书的框架
                      . 需求说明书评测内容。
                      需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：
                      ①系统定义的目标是否与用户的要求一致；
                      ②系统需求分析阶段提供的文档资料是否齐全；
                      ③文档中的所有描述是否完整、清晰，准确地反映用户要求；
                      ④与所有其他系统成份的重要接口是否都已经描述；
                      ⑤被开发项目的数据流与数据结构是否足够、确定；
                      ⑥所有图表是否清楚，在不补充说明时能否理解；
                      ⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
                      ⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；
                      ⑨设计的约束条件或限制条件是否符合实际；
                      ⑩是否考虑了开发的技术风险；
                      ?是否考虑过软件需求的其他方案；
                      ?是否考虑过将来可能会提出的软件需求；
                      ?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
                      ?有没有遗漏、重复或不一致的地方；
                      ?用户是否审查了初步的用户手册或原型；
                      ?项目开发计划中的估算是否受到了影响。
                      为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。
                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                      
                      需求说明书评测规范
                      
                      在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。
                      概要设计说明书评测
                      . 设计说明书的框架。如下表所示为软件设计规格说明的大纲。
                      
                      软件设计规格说明大纲
                      软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
                      . 概要设计说明书评测的内容。
                      ①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。
                      ②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
                      ③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
                      ④实用性：即确认该软件设计对于需求的解决方案是否实用。
                      ⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
                      ⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
                      ⑦质量：即确认该软件设计是否表现出良好的质量特征。
                      ⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。
                      ⑨限制：评估对该软件的限制是否现实，是否与需求一致。
                      ⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。
                      在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
                      为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：
                      ①设计出来的结构应是分层结构，从而建立软件成分之间的控制。
                      ②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
                      ③设计应当既包含数据抽象，也包含过程抽象。
                      ④设计应当建立具有独立功能特征的模块。
                      ⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。
                      ⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
                      根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。
                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                      
                      概要设计说明书评测规范
                      
                      详细设计说明书评测
                      详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。
                      填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                      
                      详细设计说明书评测规范
                      
                      软件编码规范评测
                      程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。
                      . 源程序文档化。
                      ①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。
                      名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。
                      ②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。
                      序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。
                      功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。
                      ③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。
                      . 数据说明。
                      在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。
                      ①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
                      ②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
                      ③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
                      . 语句结构。
                      在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
                      比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。
                      . 输入和输出
                      输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。
                      ①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
                      ②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；
                      ③使输入的步骤和操作尽可能简单，并保持简单的输入格式；
                      ④输入数据时，应允许使用自由格式输入；
                      ⑤应允许缺省值；
                      ⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
                      ⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；
                      ⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；
                      ⑨给所有的输出加注解，并设计输出报表格式。
               开发阶段
                      单元测试
                      单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
                      . 单元测试的内容。
                      在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。
                      在单元测试中进行的测试工作如下图所示，需要在五个方面对所测模块进行检查。
                      
                      单元测试的工作
                      ①模块接口测试。
                      在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。
                      当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。
                      ②局部数据结构测试。
                      模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对模块的影响也需要查清。
                      ③路径测试。
                      由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。
                      常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。
                      常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；“差1”错，即不正确地多循环一次或少循环一次；错误的或不可能的循环中止条件；当遇到发散的迭代时不能中止的循环；不适当地修改了循环变量等。
                      ④错误处理测试。
                      比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。
                      ⑤边界测试。
                      在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
                      此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
                      虽然模块测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料，必须妥善保存。
                      总之，模块测试针对的程序规模较小，易于查错；发现错误后容易确定错误的位置，易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。
                      . 单元测试的步骤。
                      通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
                      模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：
                      驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。
                      桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
                      所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。
                      
                      单元测试的测试环境
                      模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。
                      当然，如果一个模块要完成多种功能，且以程序包（package）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
                      集成测试
                      集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
                      . 组装时需要考虑的问题。
                      ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
                      ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
                      ③各个子功能组合起来，能否达到预期要求的父功能；
                      ④全局数据结构是否有问题；
                      ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
                      因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
                      子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
                      选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
                      . 模块组装成为系统的方式。
                      模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
                      ①一次性组装方式（big bang）。
                      它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
                      
                      一次性组装方式
                      在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
                      ②增殖式组装方式。
                      这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
                      . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
                      
                      自顶向下的增殖方式
                      自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
                      . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
                      以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
                      
                      一次性组装方式
                      
                      自底向上的增殖方式
                      . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
                      自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
                      自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
                      在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
                      . 满足某些软件需求；
                      . 在程序的模块结构中位于较高的层次（高层控制模块）；
                      . 较复杂、较易发生错误；
                      . 有明确定义的性能要求。
                      在做回归测试时，也应该集中测试关键模块的功能。
                      . 集成测试的组织和实施。
                      集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
                      ①采用何种系统组装方法来进行集成测试。
                      ②集成测试过程中连接各个模块的顺序。
                      ③模块代码编制和测试进度是否与集成测试的顺序一致。
                      ④测试过程中是否需要专门的硬件设备。
                      解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
                      在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
                      . 集成测试完成的标志。
                      集成测试完成的标志主要有以下几项。
                      ①成功地执行了测试计划中规定的所有集成测试。
                      ②修正了所发现的错误。
                      ③测试结果通过了专门小组的评审。
                      集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
                      在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
                      集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
                      确认测试
                      确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
                      . 进行有效性测试。
                      有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。
                      在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。
                      ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。
                      ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
                      . 软件配置复查。
                      软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
                      在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。
                      系统测试
                      系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。
                      系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
                      验收测试
                      验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。
                      目前在国内实际软件开发，特别是系统集成的过程中，验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是，验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。
                      近年来，越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义，因此，由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构，根据系统的需求分析、用户手册、培训手册等，在开发人员及最终使用人员的配合下，完成对系统全面的测试工作。
               软件验证与确认（V&V）过程
               软件的验证与确认（V&V）是贯穿软件生命周期的重要的质量保证过程，国际标准化组织IEEE在1986年颁布了软件V&V标准，又于1998年修订颁布了IEEE/ANSI Std 1012-1998软件验证与确认计划。标准规定了软件验证和确认过程（简称V&V）和软件验证和确认计划（简称SVVP）编制要求。我国软件验证与确认（V&V）的国家标准也即将颁布实施，将在我国软件的质量保证和软件测试的工作中发挥重要作用。
               软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。
               软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。下面重点介绍软件V&V中的测试过程与管理。
                      V&V基本概念
                      . 验证（Verification）：通过检查和提供客观证据，证实规定的需求已满足。
                      . 确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。
                      . 独立验证和确认（IV&V Independent Verification and Validation）：由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。
                      V&V框架是由与软件开发过程同步的V&V过程、各阶段的V&V活动和任务组成的，如下图所示。
                      
                      V&V结构
                      对每个V&V活动都规定了它的输入、任务和输出，如下图所示。
                      
                      V&V活动过程
                      软件V&V过程
                      . 软件生存周期的V&V过程框架。
                      整个软件生存周期的V&V过程框架结构描述了各阶段的V&V过程、活动和任务的层次关系，如下图所示。
                      
                      V&V过程、活动和任务的层次关系
                      . 软件开发过程的V&V概述。
                      IEEE Std 1012-1998中开发过程的V&V，如下图所示。
                      
                      软件开发过程的V&V
                      软件V&V过程中的测试
                      . 测试过程。
                      GB/T 18905.5中规定的开发过程中的软件测试过程包括：测试计划过程、测试设计过程、测试执行过程和测试结束过程。如下图所示。
                      
                      软件测试过程
                      . 需求V&V活动中的测试。
                      需求V&V活动中有两项测试任务：系统V&V测试计划生成和验证、验收V&V测试计划生成和验证。两项V&V的任务、输入和输出如下表所示。
                      
                      需求V&V活动中的测试任务、输入和输出
                      
                      . 设计V&V活动中的测试。
                      设计V&V活动中有三项测试任务：单元V&V测试计划生成和验证、集成V&V测试计划生成和验证与V&V测试计划生成和验证。三项V&V的任务、输入和输出如下表一和如下表二所示。
                      
                      设计V&V活动中的测试任务、输入和输出
                      
                      
                      设计V&V活动中的测试任务、输入和输出（续）
                      
                      . 实现V&V活动中的测试。
                      实现V&V活动中有三项测试任务：V&V测试用例生成和验证、V&V测试规程生成和验证以及部件V&V测试计划执行和验证。三项V&V的任务、输入和输出如下表所示。
                      
                      实现V&V活动中的测试任务、输入和输出
                      
                      软件测试V&V活动
                      测试V&V活动覆盖了集成测试、系统测试和验收测试。测试V&V活动及它与软件生存期的关系如下图所示。V&V的目标是确保通过执行集成测试、系统测试和验收测试使软件需求和分配给软件的系统需求得到满足。
                      
                      V&V测试产品和测试执行任务的时段图
                      测试的V&V工作应生成自己的V&V测试件（包括计划、设计、用例和规程），执行并记录自己的测试，并对照软件需求验证测试计划、设计、用例、规程和结果；测试的V&V工作应验证测试活动和测试件（包括计划、设计、用例、规程和执行结果）。测试V&V活动的任务、输入与输出的关系如下表一和如下表二所示。
                      
                      测试V&V活动中的测试任务、输入和输出
                      
                      测试V&V活动中的测试任务、输入和输出（续）
 
        软件生命周期测试策略
               软件开发与软件测试
               在W模型中，我们对软件的需求、设计测试进行了阐述，本节重点强调软件生命周期中程序开发部分需要经历的若干个测试级别，采用V模型来进行介绍。
               软件开发过程是一个自顶向下，逐步细化的过程。首先，在软件计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束及一些有效性准则。接着进入软件开发，进行软件设计，把设计用某种程序设计语言转换成程序代码。而测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。当然不排除两者平行地进行测试。
               如下图所示，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统整体出发，运行系统，看是否满足要求。
               
               软件测试与软件开发过程的关系
               软件测试策略
               测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。如下图所示显示出软件测试经历的4个步骤。
               
               软件测试的过程
               开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。
                      测试信息流
                      测试信息流如下图所示。测试过程需要以下三类输入。
                      
                      测试信息流
                      软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。
                      测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。
                      测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。
                      测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。
                      排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。
                      通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍。
                      分析设计阶段
                      分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。
                             需求说明书评测
                             由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
                             因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
                             什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
                             . 编制良好的需求说明书8条原则。
                             1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
                             原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
                             原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
                             原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
                             原则4：规格说明必须包括系统运行的环境。
                             原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
                             原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
                             原则7：规格说明必须容许不完备性并允许扩充。
                             原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。
                             尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。
                             . 需求说明书的框架。
                             需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。
                             
                             需求说明书的框架
                             . 需求说明书评测内容。
                             需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：
                             ①系统定义的目标是否与用户的要求一致；
                             ②系统需求分析阶段提供的文档资料是否齐全；
                             ③文档中的所有描述是否完整、清晰，准确地反映用户要求；
                             ④与所有其他系统成份的重要接口是否都已经描述；
                             ⑤被开发项目的数据流与数据结构是否足够、确定；
                             ⑥所有图表是否清楚，在不补充说明时能否理解；
                             ⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
                             ⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；
                             ⑨设计的约束条件或限制条件是否符合实际；
                             ⑩是否考虑了开发的技术风险；
                             ?是否考虑过软件需求的其他方案；
                             ?是否考虑过将来可能会提出的软件需求；
                             ?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
                             ?有没有遗漏、重复或不一致的地方；
                             ?用户是否审查了初步的用户手册或原型；
                             ?项目开发计划中的估算是否受到了影响。
                             为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。
                             填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                             
                             需求说明书评测规范
                             
                             在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。
                             概要设计说明书评测
                             . 设计说明书的框架。如下表所示为软件设计规格说明的大纲。
                             
                             软件设计规格说明大纲
                             软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
                             . 概要设计说明书评测的内容。
                             ①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。
                             ②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
                             ③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
                             ④实用性：即确认该软件设计对于需求的解决方案是否实用。
                             ⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
                             ⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
                             ⑦质量：即确认该软件设计是否表现出良好的质量特征。
                             ⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。
                             ⑨限制：评估对该软件的限制是否现实，是否与需求一致。
                             ⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。
                             在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
                             为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：
                             ①设计出来的结构应是分层结构，从而建立软件成分之间的控制。
                             ②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
                             ③设计应当既包含数据抽象，也包含过程抽象。
                             ④设计应当建立具有独立功能特征的模块。
                             ⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。
                             ⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
                             根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。
                             填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                             
                             概要设计说明书评测规范
                             
                             详细设计说明书评测
                             详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。
                             填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
                             
                             详细设计说明书评测规范
                             
                             软件编码规范评测
                             程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。
                             . 源程序文档化。
                             ①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。
                             名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。
                             ②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。
                             序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。
                             功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。
                             ③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。
                             . 数据说明。
                             在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。
                             ①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
                             ②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
                             ③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
                             . 语句结构。
                             在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
                             比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。
                             . 输入和输出
                             输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。
                             ①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
                             ②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；
                             ③使输入的步骤和操作尽可能简单，并保持简单的输入格式；
                             ④输入数据时，应允许使用自由格式输入；
                             ⑤应允许缺省值；
                             ⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
                             ⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；
                             ⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；
                             ⑨给所有的输出加注解，并设计输出报表格式。
                      开发阶段
                             单元测试
                             单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
                             . 单元测试的内容。
                             在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。
                             在单元测试中进行的测试工作如下图所示，需要在五个方面对所测模块进行检查。
                             
                             单元测试的工作
                             ①模块接口测试。
                             在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。
                             当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。
                             ②局部数据结构测试。
                             模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对模块的影响也需要查清。
                             ③路径测试。
                             由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。
                             常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。
                             常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；“差1”错，即不正确地多循环一次或少循环一次；错误的或不可能的循环中止条件；当遇到发散的迭代时不能中止的循环；不适当地修改了循环变量等。
                             ④错误处理测试。
                             比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。
                             ⑤边界测试。
                             在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
                             此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
                             虽然模块测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料，必须妥善保存。
                             总之，模块测试针对的程序规模较小，易于查错；发现错误后容易确定错误的位置，易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。
                             . 单元测试的步骤。
                             通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。
                             模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：
                             驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。
                             桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
                             所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。
                             
                             单元测试的测试环境
                             模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。
                             当然，如果一个模块要完成多种功能，且以程序包（package）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
                             集成测试
                             集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
                             . 组装时需要考虑的问题。
                             ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
                             ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
                             ③各个子功能组合起来，能否达到预期要求的父功能；
                             ④全局数据结构是否有问题；
                             ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
                             因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
                             子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
                             选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
                             . 模块组装成为系统的方式。
                             模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
                             ①一次性组装方式（big bang）。
                             它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
                             
                             一次性组装方式
                             在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
                             ②增殖式组装方式。
                             这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
                             . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
                             
                             自顶向下的增殖方式
                             自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
                             . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
                             以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
                             
                             一次性组装方式
                             
                             自底向上的增殖方式
                             . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
                             自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
                             自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
                             在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
                             . 满足某些软件需求；
                             . 在程序的模块结构中位于较高的层次（高层控制模块）；
                             . 较复杂、较易发生错误；
                             . 有明确定义的性能要求。
                             在做回归测试时，也应该集中测试关键模块的功能。
                             . 集成测试的组织和实施。
                             集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
                             ①采用何种系统组装方法来进行集成测试。
                             ②集成测试过程中连接各个模块的顺序。
                             ③模块代码编制和测试进度是否与集成测试的顺序一致。
                             ④测试过程中是否需要专门的硬件设备。
                             解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
                             在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
                             . 集成测试完成的标志。
                             集成测试完成的标志主要有以下几项。
                             ①成功地执行了测试计划中规定的所有集成测试。
                             ②修正了所发现的错误。
                             ③测试结果通过了专门小组的评审。
                             集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
                             在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
                             集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
                             确认测试
                             确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
                             . 进行有效性测试。
                             有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。
                             在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。
                             ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。
                             ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
                             . 软件配置复查。
                             软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
                             在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。
                             系统测试
                             系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。
                             系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
                             验收测试
                             验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。
                             目前在国内实际软件开发，特别是系统集成的过程中，验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是，验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。
                             近年来，越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义，因此，由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构，根据系统的需求分析、用户手册、培训手册等，在开发人员及最终使用人员的配合下，完成对系统全面的测试工作。
                      软件验证与确认（V&V）过程
                      软件的验证与确认（V&V）是贯穿软件生命周期的重要的质量保证过程，国际标准化组织IEEE在1986年颁布了软件V&V标准，又于1998年修订颁布了IEEE/ANSI Std 1012-1998软件验证与确认计划。标准规定了软件验证和确认过程（简称V&V）和软件验证和确认计划（简称SVVP）编制要求。我国软件验证与确认（V&V）的国家标准也即将颁布实施，将在我国软件的质量保证和软件测试的工作中发挥重要作用。
                      软件的V&V过程是确定按照规定的软件过程开发的产品是否符合活动的要求，软件是否满足它的预期用途和用户需要。软件的V&V过程包括软件产品和过程的分析、评价、评审、审核、评估和测试。
                      软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。下面重点介绍软件V&V中的测试过程与管理。
                             V&V基本概念
                             . 验证（Verification）：通过检查和提供客观证据，证实规定的需求已满足。
                             . 确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。
                             . 独立验证和确认（IV&V Independent Verification and Validation）：由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。
                             V&V框架是由与软件开发过程同步的V&V过程、各阶段的V&V活动和任务组成的，如下图所示。
                             
                             V&V结构
                             对每个V&V活动都规定了它的输入、任务和输出，如下图所示。
                             
                             V&V活动过程
                             软件V&V过程
                             . 软件生存周期的V&V过程框架。
                             整个软件生存周期的V&V过程框架结构描述了各阶段的V&V过程、活动和任务的层次关系，如下图所示。
                             
                             V&V过程、活动和任务的层次关系
                             . 软件开发过程的V&V概述。
                             IEEE Std 1012-1998中开发过程的V&V，如下图所示。
                             
                             软件开发过程的V&V
                             软件V&V过程中的测试
                             . 测试过程。
                             GB/T 18905.5中规定的开发过程中的软件测试过程包括：测试计划过程、测试设计过程、测试执行过程和测试结束过程。如下图所示。
                             
                             软件测试过程
                             . 需求V&V活动中的测试。
                             需求V&V活动中有两项测试任务：系统V&V测试计划生成和验证、验收V&V测试计划生成和验证。两项V&V的任务、输入和输出如下表所示。
                             
                             需求V&V活动中的测试任务、输入和输出
                             
                             . 设计V&V活动中的测试。
                             设计V&V活动中有三项测试任务：单元V&V测试计划生成和验证、集成V&V测试计划生成和验证与V&V测试计划生成和验证。三项V&V的任务、输入和输出如下表一和如下表二所示。
                             
                             设计V&V活动中的测试任务、输入和输出
                             
                             
                             设计V&V活动中的测试任务、输入和输出（续）
                             
                             . 实现V&V活动中的测试。
                             实现V&V活动中有三项测试任务：V&V测试用例生成和验证、V&V测试规程生成和验证以及部件V&V测试计划执行和验证。三项V&V的任务、输入和输出如下表所示。
                             
                             实现V&V活动中的测试任务、输入和输出
                             
                             软件测试V&V活动
                             测试V&V活动覆盖了集成测试、系统测试和验收测试。测试V&V活动及它与软件生存期的关系如下图所示。V&V的目标是确保通过执行集成测试、系统测试和验收测试使软件需求和分配给软件的系统需求得到满足。
                             
                             V&V测试产品和测试执行任务的时段图
                             测试的V&V工作应生成自己的V&V测试件（包括计划、设计、用例和规程），执行并记录自己的测试，并对照软件需求验证测试计划、设计、用例、规程和结果；测试的V&V工作应验证测试活动和测试件（包括计划、设计、用例、规程和执行结果）。测试V&V活动的任务、输入与输出的关系如下表一和如下表二所示。
                             
                             测试V&V活动中的测试任务、输入和输出
                             
                             测试V&V活动中的测试任务、输入和输出（续）
 
        生命周期
        IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。
        （1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。
        （2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。
        （3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。
        （4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。
        （5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有