没有合适的资源?快使用搜索试试~ 我知道了~
理论计算机科学电子札记148(2006)89-111www.elsevier.com/locate/entcs软件测试导论卢西亚诺·巴雷西米兰理工大学电子与信息学院意大利米兰MauroPezz`e2米兰大学信息、系统和通信学院意大利米兰摘要大型软件系统的开发是一个复杂且容易出错的过程。故障可能发生在任何开发阶段,必须尽早识别和消除故障,以阻止其传播并降低验证成本。质量工程师必须从早期阶段就参与开发过程,以确定所需的质量并估计其对开发过程的影响。他们的任务跨越整个开发周期,并通过维护和事后分析超越产品部署。开发和实施有效的质量过程不是一项简单的任务,但它要求我们将许多与质量相关的活动与产品特性、过程组织、可用资源和技能以及预算约束相结合。本文讨论了一个好的质量过程的主要特征,然后调查的关键测试阶段,并提出了现代功能和基于模型的测试方法。关键词:软件质量,软件测试,集成测试,系统和验收测试,功能测试,基于模型的测试。1介绍大型软件产品的开发涉及许多活动,需要适当地协调以满足期望的需求。其中1电子邮件地址:baresi@elet.polimi.it2电子邮件地址:pezze@disco.unimib.it1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi:10.1016/j.entcs.2005.12.01490L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89任务,我们可以区分主要对产品的构建做出贡献的活动,以及旨在检查开发过程和所生产工件的质量的活动这种分类并不准确,因为大多数活动在某种程度上既有助于促进发展,又有助于检查质量。在某些情况下,这种活动的特征描述不够精确,但有助于识别开发过程的一个重要线索,包括所有与质量相关的活动,通常被称为质量过程。质量过程不是一个阶段,而是贯穿整个开发周期:它从可行性研究开始,通过维护和事后分析超越产品部署。与产品相关的质量必须在可行性研究中定义;必须尽早检查和分析需求和设计规范,以识别和删除设计错误,否则很难发现并且删除成本高昂;必须在早期设计阶段设计和计划测试,以改进规范并减少交付测试不佳和低质量产品的机会,并且必须通过不同的构建和发布多次执行,以避免产品功能退化。质量过程包括许多互补的活动,这些活动必须适当地混合以适应特定的开发过程,并满足成本和质量要求。质量工程师有时必须面对矛盾的要求,如保持低成本,保证高质量,避免干扰开发过程,并满足严格的期限。选择一组合适的质量活动是困难的,需要有丰富的软件验证经验,丰富的设计和开发知识,良好的管理和计划背景,以及在不同方面和需求之间进行协调的出色质量活动解决两类不同的问题:发现缺陷和评估产品的准备程度。质量不能在过程结束时添加,但必须在整个开发周期中强制执行重要的故障类别很难揭示,也很难从最终产品中去除。许多分析和测试技术的目标是发现故障,然后消除故障。在开发过程中识别和消除故障当然有助于提高最终产品的质量,但不能保证在产品交付后没有可能持续存在的故障。继续寻找错误,直到所有的错误都被发现和删除,将导致执行质量活动永远没有任何理由。用户感兴趣的是解决问题,并从可靠性、可用性、成本以及最终满足用户期望的能力方面来衡量L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)8991或已删除的错误。用户可以容忍产品中的一些恼人的故障,这些故障可以节省成本地解决他们的问题,但不接受关键故障(即使它们非常罕见)或过于频繁的恼人故障。因此,将旨在揭示故障的质量活动与根据可靠性和可用性评估产品就绪性的活动配对是很重要的大多数质量活动是独立于开发进行的,但它们的有效性在很大程度上取决于开发过程的质量。例如,当规范结构良好时,需求规范的评审和检查比编写糟糕时更有效,当软件根据良好的设计原则实现时,集成测试比没有连贯方法开发时更有效。质量活动可以通过提供关于故障和常见错误的原因的反馈来帮助提高开发实践的质量本文的其余部分组织如下。第二节讨论了质量过程的主要特征,并强调了良好质量计划的设计。第3节介绍了验证和确认活动之间的区别。第4节通过对一些流行的现代方法进行抽样,并突出它们的互补性,来解决功能测试和基于模型的测试的问题第5节描述了测试活动的不同层次,并介绍了模块、集成、系统和验收测试的主要方法。第6节总结了论文,并确定了相关的开放性研究问题。2质量过程质量过程涉及许多活动,这些活动可分为五大类:计划和监控、规范验证、测试用例生成、测试用例执行和软件验证以及过程改进。计划和监控活动旨在将质量活动导向满足初始质量要求的产品。规划活动从开发的早期阶段开始,识别所需的质量,定义早期分析和测试计划,并通过监控质量过程,细化和调整质量过程,以处理新问题并避免新问题,从而贯穿整个开发过程。偏离原计划会导致项目失败。可验证质量标准的内部一致性和与相应质量标准的一致性。种内一致性验证旨在揭示和消除质量标准的不一致或92L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89旨在揭示开发过程中的偏差,这些偏差表现为与相应规范的差异或详细规范中的缺失元素规范可以通过许多技术进行验证,从简单的语法检查和低技术检查到模型检查和形式验证。测试用例通常从规范中生成,并与来自应用程序环境,开发技术和代码覆盖率的信息集成。应用环境和开发技术可以提供常见故障和风险的信息 许多组织收集来自遗留系统的通用测试套件,并以特定应用程序的回归测试套件或众所周知的功能的通用套件的形式表征特定应用程序环境。编程语言和开发技术存在不同的弱点,可能导致特定类别的错误。例如,C++在内存管理方面的自由性带来了众所周知的风险,这些风险可能导致危险的内存泄漏,这可以通过严格的设计和编程实践加以限制,但无法避免,并适当地与分析和测试相结合。代码覆盖率表示未进行充分测试的代码区域,并可能建议额外的测试用例以完成功能测试套件或表示设计不良的代码。测试用例可能并且应该在相应的规范可用时尽快生成。早期的测试用例生成具有明显的优势,可以减轻调度问题:测试可以与开发活动并行生成,因此可以从关键路径中排除此外,测试执行可以在相应的代码准备好后立即开始,从而减少编码后的测试时间早期生成的测试用例也有帮助验证规范的重要作用经验表明,许多规范错误比在设计或验证期间更容易早期发现等到规范用于编码时可能为时已晚,并可能导致高昂的回收成本和昂贵的项目延迟。许多现代方法学建议早期生成测试用例,直到极端编程的情况下,用测试用例生成代替模块规范测试用例可能需要在没有完整系统的情况下执行。这可能是由于增量测试模块而不等待整个系统的开发的决定,或者是由于需要隔离被测模块以专注于特定功能并促进故障的本地化。在没有整个系统的情况下执行测试用例需要开发足够的扩展,即,一种替代系统缺失部分的结构适当的扩展包括驱动程序、存根和L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)8993神谕驱动程序和存根通过为被测模块(驱动程序)准备激活环境和模拟执行被测模块(存根)可能需要的缺失组件的行为来替代执行环境 Oracle评估执行的测试用例的结果并发出异常行为的信号。为了建立足够的规模,软件工程师必须在成本和收益之间找到一个很好的折衷方案。准确的缩放对于快速测试执行非常有用,但是它可能非常昂贵并且危险地出错。廉价的sca封装可以降低成本,但对于执行测试可能是无用的。测试可以揭示多种失效,但可能不足以揭示其他失效,因此应使用替代验证活动进行补充。例如,净室方法[7]建议测试与代码检查相补充,以揭示单元级别的错误。过程改进主要集中在共享相似过程、工程团队和开发环境的项目集群质量专家收集和分析当前项目的数据,以识别常见问题并减少其影响。问题可以通过改变开发活动来消除,也可以通过引入特定的质量活动来缓解,以便尽早消除问题。虽然在当前项目中已经采取了一些纠正措施,但在许多情况下,纠正措施通常应用于未来的项目。2.1质量计划质量工程师应在设计周期的早期阶段设计质量计划根据公司的测试策略和质量工程师的经验测试策略描述了公司的质量基础设施,包括过程问题,例如,采用特定的开发过程,组织问题,例如,外包特定测试活动、工具和开发元素的选择,例如,使用特定工具套件的需要,以及任何其他表征和影响质量计划的要素。然后对初始计划进行细化,以考虑到有关正在进行的项目的增量一旦设计规范可用,详细说明模块测试活动。当计划不能详细和适应项目需要时,必须用应急计划代替当前计划,以应对新的不可预见的情况。质量计划应包括控制和监测质量过程所需的所有信息,从一般信息(如待测项目)到非常详细的信息(如单个质量活动的时间安排和为执行这些活动所分配的资源一个好的质量计划的主要要素是:94L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89测试项目表征必须测试的项目,例如指示将测试的系统的版本或配置待测特征是指在待测项目所包含的所有特征中,必须进行测试的特征。未测试的功能表示计划中未考虑的功能。这有助于检查计划的完整性,因为我们可以检查在选择要测试的功能方法描述要选择的方法。例如,我们可以要求检查所有模块,我们可以根据公司标准为子系统和系统测试规定特定的测试技术。通过/未通过标准定义了验收标准,即,用于确定被测软件是否准备就绪的标准例如,我们可以容忍一些中等影响的故障,但在交付模块之前要求没有严重和关键的故障。暂停和恢复标准描述了无法有利地执行测试活动的条件。例如,当故障率阻止被测系统的合理执行时,我们可能决定暂停测试活动,只有在“健全测试”成功后才恢复测试,该测试检查了被测单元的最低可执行性水平。风险及或有事项识别风险及界定合适的应急计划。测试可能面临许多其他开发活动所共有的两种风险:例如,人员(技术状态丧失)、技术(对技术不熟悉)和计划(某些测试任务延迟)风险,以及测试特有的风险,例如,开发(向测试组交付质量差的组件)、执行(执行测试用例时的意外延迟)和需求(关键需求)风险。可交付件列出了所有必需的可交付件。任务和进度计划阐明了根据开发、时间和资源限制安排的任务中的整体质量过程,以满足最后期限。早期的计划是详细的,而与发展的进展,以调整项目结构。例如,早期计划指出了通用模块测试和检查任务,这些任务将在设计确定系统的特定模块时详细说明。阶段和责任确定质量阶段和分配责任。环境需求是指可能源自环境的任何要求,例如,运行测试用例所需的特定设备2.2监控质量过程必须对质量过程进行监控,以揭示偏差和意外事件,并尽早使质量活动适应新的情景。监控可以采取两种形式:对活动进度的经典监控和对测试结果的定量参数的评估进度监督包括定期收集有关已完成工作量的信息,并将其与计划进行比较:质量工程师记录每项活动的开始和结束日期、消耗的资源和进度,并对当前计划的偏差做出反应,当偏差是可容忍的时,通过调整它,或者当偏差是关键时,采用应急计划定量进展的评价是困难的,只是最近才得到利用。它包括收集有关L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89951601401201008060402001 2 3 4 5 6 7 8 9 10构建严重重度中度Fig. 1.系统随时间构建的典型故障分布。断层的分布规律,并与历史资料进行对比。就故障频率和不同故障类别的分布而言,故障暴露在类似项目中遵循类似模式图1的图表取自[9],说明了故障在版本上的分布,考虑了三个严重级别该图清楚地表明,故障发生率在第一次构建时增长,然后下降。故障数量以不同的速度减少:临界和严重故障比中度故障减少得更快,我们甚至可以预期中度故障会略有增长故障的不同分布表明质量过程中可能存在异常:早期版本中的故障发生率不增加可能表明测试不佳,而后期版本中的故障发生率不减少可能表明故障诊断和排除不佳IBM在90年代初引入的正交缺陷分类(ODC)提出了详细的故障分类,并建议监控不同的分布,以揭示质量过程中可能存在的问题关于ODC的详细信息可以在[3,1]中找到尽管有可用的技术和工具,质量过程在很大程度上取决于人。责任分配是质量战略和计划的关键要素与许多其他方面一样,没有唯一的解决方案,但方法取决于组织,流程和项目。大型组织通常喜欢将开发和质量团队分开,而小型组织和敏捷流程(例如,极限编程)倾向于将开发和质量责任分配给同一个团队。将开发团队和质量团队分开,可以鼓励对质量进行客观判断,故障96L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89实际需要和限制验证要求规格交付的包裹验证图二、验证与验证的不同视角被排程压力所颠覆,却限制了排程自由,需要两个团队之间良好的沟通机制。3验证和确认旨在检查实现与其规范的一致性的活动称为验证活动,而旨在检查系统与用户期望之间的一致性的活动称为验证活动。验证和验证之间的区别在图2中得到了非正式的说明,Barry Boehm [ 2 ]对此进行了很好的阐述,他将验证描述为“构建正确的系统”,将验证描述为“构建正确的系统”。验证和核查活动相辅相成。验证可涉及所有开发阶段,包括用户对需求和设计规范的评审,但用户评审的范围受到用户理解设计和开发细节的能力的限制。因此,主要确认活动集中在最终产品上,用户可在验收测试期间对其进行广泛测试。用户软件具有许多特性,包括可靠性、可用性、安全性、互操作性等。例如,Web应用程序能够以低于给定阈值τ的响应时间为给定数量的N个用户提供服务,可以通过模拟N个用户的存在并测量响应时间来验证。其他属性可能难以验证,并且是验证的自然目标例如,用户从Web应用程序轻松获取所需信息的能力很难验证,但可以验证,例如,通过监视L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)8997用户的抽样人群最终,属性的可验证性取决于属性的表达方式例如,Web应用程序的一个属性表示为:用户必须能够轻松地将物品添加到购物车中而不会遇到令人讨厌的延迟,这无法直观地验证,因为它涉及主观感受(“轻松”和“令人然而,同样的属性表示为:用户必须能够从主页开始不超过4次鼠标点击将给定的项目添加到购物车,并且当应用程序同时为多达一万个用户提供服务时,应用程序的延迟不得超过点击后的一秒,这是可以验证的,因为主观感受被呈现为可量化的实体(因此,系统测试在编写需求规格说明时就开始了。成熟的开发过程安排检查活动以评估其可测试性,从而最大限度地提高软件产品的可验证性。不同属性的验证和确认需要特定的方法。可靠性属性可以使用下一节讨论的功能和基于模型的测试技术进行验证,但是可用性属性需要特殊用途的技术来验证。在这种情况下,标准流程包括以下主要步骤:• 使用经典检验技术和特设检查表进行检验规范。• 测试通过静态模拟用户界面产生的早期原型.• 与可用性专家和最终用户一起测试增量发布• 考虑最终系统和验收测试,包括基于专家的检查和测试、基于用户的测试、比较测试以及自动分析和检查。我们可以注意到,可用性测试严重依赖于用户,不像功能和基于模型的测试不需要用户干预。基于用户的测试经过仔细的计划和评估:可用性团队识别用户类别,根据识别的类别选择合适的人群样本,定义能够很好地代表系统的常见和关键用途的交互集,仔细监控所选用户与系统的交互,并最终评估结果。关于可用性测试的更多细节可以在[13]中找到98L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)894功能和基于模型的测试转到验证,功能测试是设计测试用例的基本技术它适用于需求规格说明和设计过程的所有级别,从系统到模块测试,它有效地发现了一些通常逃避基于代码和基于故障的测试的故障,它可以应用于程序行为的任何描述,最后,功能测试用例的设计和执行通常比通过其他技术设计的测试更便宜函数规范是对程序预期行为的描述可以通过多种方式给出具体说明。从测试的角度来看,我们区分了用自然语言表达的规范和用某些(半)形式语言表达的规范,例如,有限状态机、决策表、控制流程图、UML图。 当规范用自然语言表达时。功能测试技术定义了一组步骤,帮助分析规范以获得一组令人满意的测试用例。当规格作为(半)正式模型给出时,功能测试包括应用合适的标准来提取一组测试用例。我们也将此活动称为基于模型的测试。4.1功能测试现代通用功能测试方法包括类别划分[14],组合[4]和基于目录的[12]测试。类别划分测试适用于用自然语言表达的规范,包括三个主要步骤。我们开始将规格分解为可独立测试的特性:测试设计者识别可独立测试的规格项,并识别确定所考虑特性(类别)行为的参数和环境元素。例如,如果我们测试一个Web应用程序,我们可以将目录处理程序功能识别为一个可独立测试的特性。以下摘录的规格根据上一个销售期的销售额和库存量如果在最后一个销售周期中,订单数量低于给定阈值t1,或者如果订单数量低于阈值t2> t1,并且库存量高于阈值s2,则暂停产品的生产。如果某个项目不在生产中,前一时期的订单量保持在t1以下,库存量降到阈值s1 t2> t2类型的商品个人smax[single]> smax[error]不可用[if assmbl][error]组装的[assmbl]图三.类别划分测试:一个简单的类别、选择和约束的例子。每个类别的选项都列在相应的列中。约束条件显示在方括号中。example. 然而,在其他情况下,选择并不自然地受到约束,并且通过考虑所有可能的选择组合而生成的测试用例的数量可能超过分配给测试的预算例如,让我们考虑贴现政策的非正式规定以下摘录的折扣政策处理程序的具体说明根据客户的状态和购买金额确定适用的折扣。折扣适用于个人和教育机构。如果所考虑的销售期内的订单量分别超过阈值o1或阈值o2> o1,则应用额外的折扣。 如果当前发票的金额或当前销售周期中的发票总额超过给定阈值(对于当前发票,i1和i2> i1,对于周期中的发票总额,t1和t2>t1),也应用折扣。折扣可以无限制地累积信用记录有风险的客户不符合任何折扣资格。图4中的选择都是从上面的规范中衍生出来的,它们都不是自然约束的,因此我们得到了一个组合数量的测试用例。在当前的示例中,它上升到182个测试用例,并且当类别或选择的数量增加时,它会像大多数真实情况一样指数地增长。强制人工约束没有帮助,因为它通过消除可能揭示重要故障的值的组合来减少生成的测试用例的数量一种不同的方法在于限制组合L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89101客户订单数金额发票总额贷方类型当期发票当期情况个体≤o1≤i1≤t1正常业务≤o2≤i2≤t2风险教育> o2> i2> t2见图4。 一组没有自然约束通过只覆盖选择的成对组合例如,图4中的所有成对组合可以用少于18个测试用例来覆盖生成仅覆盖成对组合的测试用例被称为组合测试,并且基于实验证据,即大多数失败取决于单个选择或选择的成对组合,很少取决于许多不同选择的特定组合因此,覆盖选择的所有成对类别划分和组合测试可以有效地结合起来,首先限制选择的组合,然后只覆盖成对组合。在为已识别类别选择选项时,我们识别正常值以及边界和误差条件。一般来说,许多故障隐藏在特殊情况下,这取决于所考虑的元素的类型。例如,当处理一个范围[低,高]的值时,测试专家建议至少考虑边界内的一个值,边界本身的低和高,每个边界之前和之后的值,以及至少另一个范围外的值专家测试设计人员的知识可以在目录中获取,这些目录列出了每种规格必须考虑的所有可能情况我们可以建立通用和专用目录。第一种可以在大多数情况下使用,而第二种仅适用于以特定情况为特征 目录适用于结构良好的规范。 因此,一般来说,基于目录的测试首先以前置和后置条件、变量、定义和函数的形式转换规范,然后应用目录来导出一组完整的测试用例。4.2基于模型的测试当规格用(半)形式语言表示时,我们可以通过将测试生成标准应用于这些模型来导出测试用例测试设计人员专注于测试的创造性步骤(有限状态模型的推导),并使用自动化技术来完成重复性任务(测试用例生成标准的应用)。在本文中,我们专注于有限状态102L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89clearCart()addItem(item,quantity)addItem(item,quantity)购物车()removeItem(item,quantity)没有购物车空购物车已满购物车clearCart()buy()buy()removeItem(item,quantity)准备购买自动机,但同样的方法可以应用于几个不同的模型。当规范描述有限状态集之间的转换时,通常很自然地导出一个有限状态模型来生成测试用例规范。例如,让我们考虑以下的非正式规格,Web应用程序的shoppingCart功能购物车可以通过以下功能进行操作• 创建一个新的空购物车。• addItem(item,quantity)将指定数量的商品添加到购物车中。• removeItem(item,quantity)从购物车中删除指定数量的商品• clearCart()清空购物车,不管它的内容是什么。• buy()冻结购物车的内容并计算价格。或者,可以使用图5的有限状态机对购物车进行建模。它并不取代非正式的规范,但涵盖了与国家有关的方面。测试用例可以通过导出覆盖有限状态机的不同元素的调用序列来生成一个简单的标准要求覆盖所有转换(转换覆盖)。复杂的标准要求覆盖不同种类的路径(单状态路径覆盖、单过渡路径覆盖、边界内部环路覆盖)。图五、从购物车的非正式规范中提取的有限状态机模型通常,有限状态行为是用模型来呈现的,这些模型提供了简化模型的功能。Statecharts是最著名的例子之一例如,在图6的Statecharts中,我们将图5的有限状态机的empyCart和filledCart状态分组为单个或分解状态,从而将两个购买边合并为一个。在大多数情况下,我们可以很容易地扩展有限状态机的标准,并添加新的标准,L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89103clearCart()addItem(item,quantity)购物车()addItem(item,quantity)noCartbuy()购物车填写购物车removeItem(item,quantity)clearCart()removeItem(item,quantity)新模式的具体结构。例如,对于大的状态图,我们可以通过只覆盖状态图的转换而不是等效有限状态机的所有转换来减少生成的测试用例的大小在这个例子中,我们只覆盖了一次transitionbuy,而不是等价机器中的两次图六、 上述购物车的Statecharts规格5检测水平软件开发涉及不同的抽象层次:模块或组件,可以为特定系统开发或从以前的系统或库中重用;子系统,通过集成相关组件集获得;最终系统,通过将组件和子系统组装到满足初始需求的应用程序中测试在每个水平上进行,如图7的经典V模型所示。我们经常区分模块、集成、系统和验收测试。5.1模块测试模块或组件首先被隔离验证,通常由开发人员自己检查单个模块是否按预期运行(模块测试)。彻底的模块测试对于识别和删除故障非常重要,否则在以后的开发阶段很难识别这些故障,并且删除这些故障的成本很高。模块测试包括功能测试和功能测试用例可以使用适当的功能或基于模块的测试技术从模块规范中导出,如前一节所述。功能测试可能无法揭示某些类别的问题,因为开发人员可能以不同的方式实现相同的功能,并且从给定功能导出的测试用例可能无法覆盖所有可能的实现。一个直观的例子是一个设计良好的排序例程,它实现了不同的算法来处理非常小的集合、相当大的集合和更大的集合104L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89见图7。V模型可用内存。我们都知道,一个简单的二次算法,如bubleort,是足够的排序小集,而快速排序可能是首选的排序大集,适合在内存中,但集大于可用的分类是排序更好的算法,如树排序。如果算法的选择留给程序员,而不包括在规范中,则在不知道此选择的情况下导出的功能测试用例可能无法覆盖整个实现,即使设计良好。结构测试通过覆盖代码的结构来补充功能测试,从而处理功能测试中不包括的情况结构化测试通常分为两个阶段:首先,程序员使用简单的覆盖率工具测量代码覆盖率,这些工具指示覆盖的代码数量并突出显示代码中未覆盖的元素,然后生成遍历未覆盖元素的测试用例。可以通过考虑守则的不同要素来衡量覆盖范围。最简单的覆盖率标准关注语句,并测量测试用例执行的语句的百分比分支和条件覆盖标准度量测试执行的分支或条件的数量。路径覆盖标准测量测试覆盖的路径数量。不同的路径覆盖标准可以基于路径的选择方式来识别其他标准涉及数据流读者可以在[5]中找到关于代码覆盖率的更多覆盖标准是指所有考虑的要素,例如,语句是静态标识的,因此也包括不可执行的元素。不幸的是,识别可执行元素的问题是不可判定的,因此我们不能自动地只选择可执行元素的正确子集。实际需要和约束验收测试系统测试/分析传奇集成测试/分析验证验证模块测试模块组件质量标准子系统子系统设计系统集成系统规范交付的包裹L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89105的部分。在大多数情况下,代码覆盖率并不被用作绝对指标,而是被用作监控模块测试活动的近似度量例如,如果我们提到语句覆盖率,则高达10-15%的不可执行语句的存在可能是可接受的,但是更高百分比的不可执行语句,即,语句覆盖率低于85-90%可能表明设计不好,导致太多不可执行语句,说明不好,不允许导出一组合适的功能测试用例,或使用一组不充足的测试用例进行浅模块测试。当覆盖率低于可接受的阈值时,测试设计人员和开发人员会仔细检查模块,以识别和修复问题。在某些关键情况下,检查测试未覆盖的所有元素,以了解它们是否可以被覆盖或激发不可执行语句的存在。例如,RTCA/DO-178 B“机载系统和设备认证中的软件考虑”及其欧洲等同的EUROCAE ED-12 B(航空电子行业常用的质量标准)要求对机载软件进行修改后的条件充分性(MCDC)标准适用于基本条件,即,谓词的基本组成部分,用于选择要执行的程序分支,并要求显示每个基本条件,也就是说,对于每个基本条件C,存在两个测试用例,其中除了C之外的所有条件的真值都相同,并且复合条件作为整体对于这些测试用例中的一个评估为真,而对于另一个评估为假5.2集成和基于组件的测试单个模块的质量是必要的,但不足以保证最终系统的质量。低质量模块的故障会致命地导致系统故障,这些系统故障通常难以诊断,并且难以消除且费用昂贵。不幸的是,许多细微的故障都是由精心设计的模块之间的意外交互引起的。在1996年7月4日导致火箭损失的阿丽亚娜5号事故[11]和1999年9月23日火星气候轨道器未能进入火星轨道[8]的调查报告中,描述了精心设计的软件模块之间意外相互作用的着名例子。在阿丽亚娜事故中,一个在阿丽亚娜4号之前的任务中充分测试和成功使用的模块这个模块负责计算水平偏差,它失败了,因为106L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89由于阿丽亚娜5号火箭的水平速度高于阿丽亚娜4号火箭,火星气候轨道器的故障是由喷气推进实验室开发的软件和主承包商洛克希德马丁公司开发的软件之间的意外相互作用洛克希德·马丁公司开发的软件以英制单位产生数据,而导航所需的航天器操作数据则以公制单位产生。这两个模块都很好地工作时,集成在系统中,指的是同质的测量系统,但失败时,不正确的集成。集成故障最终是由接口、资源使用或所需属性的不完整规范或错误实现不幸的是,完全指定所有模块交互可能是困难的或成本不合理例如,预测远程和明显不相关的模块之间的交互可能非常困难,这些模块共享一个临时隐藏文件,该文件碰巧被两个模块赋予相同的名称,特别是如果名称冲突很少出现并且仅在某些特定配置中出现。集成故障可能来自多种原因:• 对参数或数值的解释不一致,如火星气候解释为英制单位和公制单位;• 违反值域或容量/大小,因为它发生在Apache 2 Web服务器的某些版本中,这些版本在解析配置文件时扩展环境变量时可能会溢出缓冲器;• 对参数或资源的副作用,当模块使用它们的接口中没有明确提到的资源时可能会发生这种情况• 功能缺失或被误解,当不完整的规范被错误解释时可能会发生这种情况;• 非功能性问题,源自未指定的非功能性属性,如性能;• 动态不匹配,它源自意外的动态绑定。集成测试涉及许多通信模块。大爆炸测试,等待,直到所有模块集成,很少是有效的,因为集成故障可能隐藏在不同的模块,并保持未被捕获,或可能在故障发生后很久才出现,从而变得难以定位和删除。大多数集成测试策略建议以增量方式测试集成模块。集成策略可以分为结构化和功能驱动。结构性策略根据设计结构定义整合的顺序,包括自下而上和自上而下的方法,以及它们的组合,有时被称为三明治或骨干策略。它们包括根据L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89107分别从顶部、底部或两侧开始。任务驱动策略根据模块间的动态协作模式定义集成顺序,包括线程和关键模块策略。线程测试建议根据与系统特性相对应的执行线程来集成模块。关键模块测试根据描述模块关键性的相关风险因素集成模块。测试驱动的测试策略更好地匹配开发早期可执行系统的开发策略,因此可能受益于早期用户反馈,但它们通常需要比结构化策略更复杂的规划和管理因此,它们仅适用于大型系统,其优点克服了额外的成本。COTS组件的使用进一步使集成测试复杂化。组件与经典模块不同,可在不同的上下文中重复使用,而与其开发无关重用组件的系统设计人员通常无法访问这些组件的源代码或开发人员,而只能依赖于组件接口的规范此外,组件经常在开发时无法预见的环境中重用,它们的行为可能不完全符合特定的需求。在测试组件时,设计人员应识别组件的不同使用配置文件,并为每个识别的配置文件提供测试套件系统设计人员应将其需求与所提供的配置文件相匹配,并在导出特定于所考虑上下文的测试套件之前重新执行与已识别配置文件相关的集成测试5.3系统、验收和回归测试模块和集成测试可以对单个模块的质量及其交互提供信心,但不能对整个系统的行为提供信心。例如,知道模块正确地处理产品数据库并且产品数据库与计算价格的模块正确地互操作并不能确保整个系统实现系统需求中指定的折扣策略。此外,知道系统匹配需求规范并不能保证它的行为符合用户的期望,用户的期望可能与需求分析的结果不完全匹配。因此,我们需要根据其规格及用户需求测试整个系统,以完成系统测试验证整个系统与其规格之间的对应关系,而验收测试则验证系统与用户期望之间的对应关系108L. Baresi,M.Pezzè/Electronic Notes in Theoretical Computer Science 148(2006)89系统和验收测试考虑整个系统在功能和非功能方面的行为模块和集成测试主要基于软件的内部,用户很难访问因此,它们侧重于提供有用结果的核查活动,而不需要部署整个系统,也不需要用户在场。大多数模块和集成测试活动都集中在功能属性上,正如本节前面所讨论的。一些非功能属性,如模块性、可维护性和可测试性,可以通过设计规则强制执行,并在开发过程中使用简单的静态分析工具和手动检查进行检查,但不涉及广泛的测试。其他重要的非功能属性,如可用性和性能,可以通过良好的设计实践部分地实施,但它们的测试需要整个系统和用户的存在对早期原型进行性能和可用性测试和分析可以评估重要的设计决策并防止开发中的一些错误,但对部署系统进行测试对于提供可靠数据至关重要其他非功能属性,如安全性和安全性,不涉及测试团队,但由与测试团队并行工作的特殊专家团队考虑。由于软件的规模,结构测试对系统测试帮助不大。度量数百万行代码的代码覆盖率或识别尚未执行的路径几乎没有帮助。另一方面,识别出一组被忽略的特征并覆盖所有可能的情况对于揭示系统错误是非常重要的。因此,系统测试主要是基于功能和基于模型的测试。系统测试中最重要的问题是掌握可能非常庞大和复杂的需求规范幸运的是,规范是为软
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- RTL8188FU-Linux-v5.7.4.2-36687.20200602.tar(20765).gz
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
- SPC统计方法基础知识.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功