|
|
知识路径： > 软件评测知识 > 软件测试类型 > 按工程阶段分类 >
|
被考次数：37次
被考频率：高频率
总体答错率：43%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：掌握
相关知识点：54个
|
|
|
|
|
|
|
在W模型中，我们对软件的需求、设计测试进行了阐述，本节重点强调软件生命周期中程序开发部分需要经历的若干个测试级别，采用V模型来进行介绍。
|
|
|
|
软件开发过程是一个自顶向下，逐步细化的过程。首先，在软件计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束及一些有效性准则。接着进入软件开发，进行软件设计，把设计用某种程序设计语言转换成程序代码。而测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。当然不排除两者平行地进行测试。
|
|
|
|
如下图所示，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统整体出发，运行系统，看是否满足要求。
|
|
|
|
|
|
|
|
|
|
测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。如下图所示显示出软件测试经历的4个步骤。
|
|
|
|
|
|
|
|
开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。
|
|
|
|
|
|
|
|
|
|
|
|
软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。
|
|
|
|
测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集。
|
|
|
|
测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。
|
|
|
|
测试之后，要对所有测试结果进行分析，即将实测的结果与预期的结果进行比较。如果发现出错的数据，就意味着软件有错误，就需要开始排错（调试）。即对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。
|
|
|
|
排错的过程是测试过程中最不可预知的部分，即使是一个与预期结果只相差0.01%的错误，也可能需要花上一个小时、一天、甚至一个月的时间去查找原因并改正错误。也正是因为排错中的这种固有的不确定性，使得我们很难确定可靠的测试进度。
|
|
|
|
通过收集和分析测试结果数据，开始针对软件建立可靠性模型。如果经常出现需要修改设计的严重错误，那么软件质量和可靠性就值得怀疑，同时也表明需要进一步测试。如果与此相反，软件功能能够正确完成，出现的错误易于修改，那么就可以断定：或者是软件的质量和可靠性达到可以接受的程度，或者是所作的测试不足以发现严重的错误。如果测试发现不了错误，那么几乎可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用过程中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40~60倍。
|
|
|
|
|
|
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。
|
|
|
|
|
|
由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
|
|
|
|
因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
|
|
|
|
什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
|
|
|
|
|
|
1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
|
|
|
|
原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
|
|
|
|
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
|
|
|
|
原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
|
|
|
|
|
|
原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
|
|
|
|
原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
|
|
|
|
|
|
原则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）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
|
|
|
|
|
|
集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
|
|
|
|
|
|
①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
|
|
|
|
②一个模块的功能是否会对另一个模块的功能产生不利的影响；
|
|
|
|
|
|
|
|
⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
|
|
|
|
因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
|
|
|
|
子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
|
|
|
|
选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
|
|
|
|
|
|
模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
|
|
|
|
|
|
它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
|
|
|
|
|
|
|
|
在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
|
|
|
|
|
|
这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
|
|
|
|
. 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
|
|
|
|
|
|
|
|
自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
|
|
|
|
. 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
|
|
|
|
以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
|
|
|
|
|
|
|
|
|
|
|
|
. 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
|
|
|
|
自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
|
|
|
|
自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
|
|
|
|
在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
|
|
|
|
|
|
. 在程序的模块结构中位于较高的层次（高层控制模块）；
|
|
|
|
|
|
|
|
|
|
|
|
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
|
|
|
|
|
|
|
|
③模块代码编制和测试进度是否与集成测试的顺序一致。
|
|
|
|
|
|
解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
|
|
|
|
在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
|
|
|
|
在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
|
|
|
|
集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
|
|
|
|
|
|
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
|
|
|
|
|
|
有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。为此，需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时，对其他软件需求，例如可移植性、可靠性、易用性、兼容性、可维护性等，也都要进行测试，确认是否满足。
|
|
|
|
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类。
|
|
|
|
①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而接受了这部分程序。
|
|
|
|
②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
|
|
|
|
|
|
软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
|
|
|
|
在确认测试的过程中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。
|
|
|
|
|
|
系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。
|
|
|
|
系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
|
|
|
|
|
|
验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。
|
|
|
|
目前在国内实际软件开发，特别是系统集成的过程中，验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是，验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。
|
|
|
|
近年来，越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义，因此，由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构，根据系统的需求分析、用户手册、培训手册等，在开发人员及最终使用人员的配合下，完成对系统全面的测试工作。
|
|
|
|
|
|
软件的验证与确认（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中的测试过程与管理。
|
|
|
|
|
|
. 验证（Verification）：通过检查和提供客观证据，证实规定的需求已满足。
|
|
|
|
. 确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。
|
|
|
|
. 独立验证和确认（IV&V Independent Verification and Validation）：由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。
|
|
|
|
V&V框架是由与软件开发过程同步的V&V过程、各阶段的V&V活动和任务组成的，如下图所示。
|
|
|
|
|
|
|
|
对每个V&V活动都规定了它的输入、任务和输出，如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
整个软件生存周期的V&V过程框架结构描述了各阶段的V&V过程、活动和任务的层次关系，如下图所示。
|
|
|
|
|
|
|
|
|
|
IEEE Std 1012-1998中开发过程的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活动的任务、输入与输出的关系如下表一和如下表二所示。
|
|
|
|
|
|
|
|
|
|
|
