|
知识路径: > 软件评测知识 > 软件测试基本概念 >
|
被考次数:11次
被考频率:高频率
总体答错率:40%  
知识难度系数:
|
由 软考在线 用户真实做题大数据统计生成
|
相关知识点:63个
|
|
|
|
|
软件测试使用各种术语描述软件出现的问题,通用的术语如下:
|
|
|
|
|
|
. 软件失效(software failure)。
|
|
|
区分这些术语的概念很重要,它关系到测试工程师对软件失效现象与机理的深刻理解,而这些概念常常在文献中被混淆。本书将根据国际经典软件测试论著,对软件失效的机理进行阐述。
|
|
|
由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效机理可能有不同的表现形式。但总的说来,软件失效机理可描述为:软件错误→软件缺陷→软件故障→软件失效。
|
|
|
①软件错误:在可以预见的时期内,软件仍将由人来开发。在整个软件生存期的各个阶段,都贯穿着人的直接或间接的干预。然而,人难免犯错误,这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生。可见,软件错误是一种人为过程,相对于软件本身,是一种外部行为。
|
|
|
②软件缺陷:软件缺陷是存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差,如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障,这时称软件缺陷被激活。
|
|
|
③软件故障:软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如,软件处于执行一个多余循环过程时,我们说软件出现故障。此时若无适当措施(容错)加以及时处理,便产生软件失效。显然,软件故障是一种动态行为。
|
|
|
④软件失效:软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。
|
|
|
综上所述,软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时,便产生一个软件故障;同一个软件缺陷在不同条件下被激活,可能产生不同的软件故障。软件故障如果没有及时的容错措施加以处理,便不可避免地导致软件失效;同一个软件故障在不同条件下可能产生不同的软件失效。
|
|
|
在软件生存期中存在和产生形形色色的软件错误、缺陷、故障和失效。不同的软件,其错误、缺陷、故障和失效无论在表现形式、性质乃至数量上都可能大不相同,试图对它们作一个全面而详细的阐述是不现实的,所以有必要加以区别对待。关于“错误”的广义定义是:不正确的事务和行为。在1999年(美)John D. Musa的《软件可靠性工程》书中,关于“软件错误”是这样描述的:“错误是在系统运行时,引起或可能潜在地引起失效的缺陷,是一种面向开发的概念。”例如,当用户单击某个具体的菜单时,本应在屏幕上出现特定的对话框,但是却没有出现。这种行为就是一个失效。造成这种失效的错误可能是遗漏代码。这里给出的定义是“电气与电子工程师协会(IEEE)”和“美国标准协会(ASA)”的标准,是通过引起失效和错误的系统成分,来定义失效和错误的。这些成分一般是硬件、软件和人。
|
|
|
John D. Musa在1999年对软件错误的定义是:软件错误是代码中的缺陷,是由错误引起的,是由一个或多个人的不正确或遗漏行为造成的。例如,系统工程师在定义需求时可能会犯错误,从而导致代码错误,而代码错误又导致在一定条件下执行系统时出现失效。“缺陷”是指欠缺或不够完备的地方。软件的欠缺和不完备主要是针对产品说明书而言的。2001年(美)Ron Patten著的《软件测试》一书对软件缺陷进行了定义。按照一般定义,只要软件出现的问题符合下列5种情况的任何一种,就叫做软件缺陷:①软件未达到产品说明书中标明的功能;②软件出现了产品说明书中指明的不会出现的错误;③软件功能超出了产品说明书指明的范围;④软件未达到产品说明书虽未指出但应达到的目标;⑤软件测试人员认为软件难以理解、不易使用、运行速度慢,或最终用户认为不好使用。实践表明,大多数软件缺陷产生的原因并非源自编程错误,主要来自于产品说明书的编写和产品方案设计。
|
|
|
产品说明书成为软件缺陷的罪魁祸首,是因为产品说明书编写得不全面、不完整和不准确,而且经常更改,或者整个开发组没有很好地沟通和理解。这也就是出自于软件需求说明书本身的问题,或开发人员对需求说明书的理解与沟通不足。
|
|
|
软件缺陷的第二大来源是设计方案,也就是软件设计说明书。这是程序员开展软件计划和构架的地方,就像建筑师为建筑物绘制蓝图一样。这里产生软件缺陷的原因与产品说明书或需求说明书是一样的,片面、多变、理解与沟通不足。
|
|
|
总之,软件缺陷是开发的软件与软件需求说明书、设计说明书的不一致;软件的实现未满足应达到目标的用户潜在需求。故障是指一个实体发生障碍和毛病。软件故障在ISO 14598软件产品评价标准中的定义是:计算机程序中的不正确的步骤、过程或数据定义。
|
|
|
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态,软件出现故障若无适当措施(容错)加以及时处理,便产生软件失效。显然,软件故障是一种动态行为。
|
|
|
在软件设计和编程过程中,花费很大的精力确保软件系统能从各种故障导致的失效中恢复。当遇到软件出现故障时,系统不能像软件设计和用户要求那样运行而导致失效,就需要有故障恢复措施,以保证故障恢复后的继续执行。软件失效是系统行为对用户要求的偏离,是一种面向用户的概念。这就是说,失效意味着系统的运行。只有在执行程序过程中才会发现软件失效,发现的潜在失效可以是设计审查、代码阅读和其他方法产生的结果。有的项目组还把文档错误计算在软件错误之内,这一般是不正确的,因为文档并不直接影响程序的执行。因为用户接受的是程序使用的错误信息,文档错误可能会导致用户的失效。但是,用户并不是软件成分,不能把用户看成是与失效和可靠性有关的单独的系统成分。
|
|
|
对失效严重程度进行分类,主要是为了结合失效频率来解决失效优先级的确定。常见的分类标准包括对人员生命、成本和系统能力的影响。失效强度常常应用于软件可靠性工程中,最初是指单位时间内的失效次数;基于软件大量的使用经验,失效强度表示为每个自然单元出现的失效数目更加方便。失效强度是表示可靠性的另一种形式。
|
|
|
关于概念不可能彼此分得很清楚,实际上也没有太大的必要。目前软件测试界一般主要使用缺陷(defect)和错误(error)这两个词。在测试过程中,我们找到的错误会有不同的类型,对错误的分析与管理是十分重要的。
|
|
|
|
通过对错误分布情况的仔细分析,可以帮助我们将测试的主要精力更好地集中到最有价值的地方,如下图显示了缺陷与错误的分布情况。
|
|
|
|
|
开发早期的错误通常是很多的,而且令人讨厌的是它们还会转移到后期。这和制造业的装配线类似,如果一个坏零件或次品被允许上线,从这点开始,包含它的组件就是“坏”的,如果该组件下了线,并出了厂门,情况就会更糟糕,就得为那个坏零件付出代价。换句话说,错误不是自封闭的,当它们转移到后面的组件中时,往往会以新的形势出现。
|
|
|
所有的错误都是要付出代价的。没有被发现的错误,以及那些在开发过程中很晚才被发现的错误都是成本非常高的,没有被发现的错误就在系统中迁移、扩散,最终导致系统失效。直到很晚才被发现的错误常常造成代价昂贵的返工。那些没有被发现的错误导致系统失效,造成严重的财产损失,有时还会带来法律上的麻烦,系统将终身为此付出高昂的代价。
|
|
|
这意味着测试是贯穿开发全过程的工作,也意味着对最终产品的测试仅仅是软件质量大战中的一个战役,而且不是代价最高的战役。今天,40%~70%的软件开发时间和资源都花在查错和纠错上。不幸的是大多数组织还没有一套办法来准确地计算成本,不管怎样,在使用测试资源方面任何有意义的改进都能极大地降低开发成本。
|
|
|
|
软件存在的缺陷与错误会带来软件失败的风险,重要软件故障与失效会导致重大经济损失与灾难。在报告软件缺陷时,一般要讲明如何处置它们。测试员要对软件缺陷分类,以简明扼要的方式指出其影响,以及修改的优先次序。给软件缺陷与错误划分严重性和优先级的通用原则是:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一般的严重性和优先级的划分用数字1~4表示,有的小数字表示的级别最高;而有的用大数字表示级别高。同样的错误和缺陷,在不同的开发过程或软件的不同部分,严重性和优先级将有所变化,要具体情况具体分析。
|
|
|
|
软件测试的主要目的在于发现软件存在的错误(Bug),如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除软件错误,保证要发布的软件符合需求设计的目标。在实际的软件测试过程中,每个Bug都要经过测试、确认、修复、验证等的管理过程,这是软件测试的重要环节。
|
|
|
|
为了正确地跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作为一条记录输入指定的错误跟踪管理系统。
|
|
|
目前已有的错误跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、Mozilla公司的Buzilla软件(免费软件),以及国内的微创公司的BMS软件,这些软件在功能上各有特点,可以根据实际情况选用。当然,也可以自己开发缺陷跟踪软件,例如基于Notes或是ClearQuese开发的错误跟踪管理软件。
|
|
|
作为一个错误跟踪管理系统,需要正确记录错误信息和错误处理信息的全部内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
正确的错误数据库权限管理是错误跟踪管理系统的重要考虑要素,一般要保证对于添加的错误不能从数据库中删除。
|
|
|
|
|
|
. 打开(Open):被确认并分配给相关开发人员处理。
|
|
|
. 修正(Fixed):开发人员已完成修正,等待测试人员验证。
|
|
|
|
. 延期(Deferred):不在当前版本修复的错误,下一版修复。
|
|
|
|
|
|
. 测试人员提交新的错误入库,错误状态为“New”。
|
|
|
|
①如果确认是错误,分配给相应的开发人员,设置状态为“Open”。
|
|
|
②如果不是错误,则拒绝,设置为“Declined”状态。
|
|
|
. 开发人员查询状态为“Open”的错误,做如下处理。
|
|
|
|
|
③如果不能解决的错误,要留下文字说明并保持错误为“Open”状态。
|
|
|
④对于不能解决和延期解决的错误,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。
|
|
|
. 测试人员查询状态为“Fixed”的错误,验证错误是否已解决,做如下处理。
|
|
|
|
|
|
|
①为了保证错误处理的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复。
|
|
|
②每次对错误的处理都要保留处理信息,包括处理姓名、时间、处理方法、处理意见、Bug状态。
|
|
|
③拒绝或延期处理错误不能由程序员单方面决定,应该由项目经理、测试经理和设计经理共同决定。
|
|
|
④错误修复后必须由报告错误的测试人员验证,确认已经修复后,才能关闭错误。
|
|
|
. 加强测试人员与程序员之间的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法,以及必要的测试用例。
|
|
|