软件测试教程(第2版)课件第2章-软件缺陷

第2章软件缺陷2.1软件缺陷概述2.1.1

软件缺陷的定义2.1.2软件缺陷分析2.1.3软件缺陷的种类2.1.4

软件缺陷的产生2.1.5

软件缺陷数目估计2.1.6软件测试效率分析2.2软件缺陷管理2.2.1

缺陷管理的目标2.2.2

缺陷报告2.2.3

软件缺陷管理流程2.2.4

缺陷管理工具2软件缺陷22.1.1软件缺陷的定义软件没有达到产品说明书表明的功能程序中存在语法错误程序中存在拼写错误程序中存在不正确的程序语句软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标测试员或用户认为软件的易用性差2.1软件缺陷概述32.1.1软件缺陷的定义缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷文档缺陷文档在静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷。代码缺陷对代码进行同行评审、审计或代码走查过程中发现的缺陷。2.1软件缺陷概述42.1.1软件缺陷的定义测试缺陷由测试执行活动发现的被测对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题）的缺陷。测试活动内部测试、连接测试、系统集成测试、用户验收测试，测试活动中发现的缺陷为测试缺陷。过程缺陷通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员等。2.1软件缺陷概述52.1.2软件缺陷分析软件缺陷是影响软件质量的重要与关键因素之一，发现与排除软件缺陷是软件生命周期中的重要工作之一。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。发现与排除软件缺陷需要大量的花费。美国国防部的数据表明，在IT产品中，大约42%的资金是用于与软件缺陷相关的工作上。目前在美国，软件测试的花费占整个软件费用的53%～87%。因此，对软件缺陷及其相关问题进行研究是极为有价值的。2.1软件缺陷概述62.1.2软件缺陷分析软件工程师在工作中一般会引入大量的缺陷。统计表明，有经验的软件工程师的缺陷引入率一般是50～250个缺陷/KLOC，平均的缺陷引入率在100个缺陷/KLOC以上。即使软件工程师学过软件缺陷管理之后，平均的缺陷引入率也在50个缺陷/KLOC。目前高水平的软件组织所生产的软件可以达到的缺陷密度为2～4个缺陷/KLOC，一般的软件组织所生产的软件其缺陷密度为4～40个缺陷/KLOC，NASA的软件的缺陷密度可以达到0.1个缺陷/KLOC。2.1软件缺陷概述72.1.2软件缺陷分析开发低缺陷密度的软件需要大量的花费。在上世纪九十年代，NASA的软件平均一行代码需要1000$，而一般CMM5的软件开发成本是CMM1的几倍甚至几十到上百倍。影响软件缺陷数目的因素很多。在不同的软件阶段，软件的缺陷密度是不同的。从宏观上看，包括管理水平、技术水平、测试水平等。从微观上看，软件规模、软件复杂性复杂性、软件类型、测试工具、测试自动化程度、测试支撑环境、开发成本等。初始的软件缺陷密度一般是靠经验来估计的。2.1软件缺陷概述82.1.3软件缺陷的种类输入/输出缺陷2.1软件缺陷概述9类型举例输入不接受正确输入接受不正确输入描述有错或遗漏参数有错或遗漏输出格式有错结果有错在错误的时间产生正确的结果不一致或遗漏结果不合逻辑的结果拼写/语法错误修饰词错误2.1.3软件缺陷的种类逻辑缺陷遗漏情况重复情况极端条件出错解释有错遗漏条件外部条件有错错误变量的测试不正确的循环迭代错误的操作符2.1软件缺陷概述102.1.3软件缺陷的种类计算缺陷不正确的算法遗漏计算不正确的操作数不正确的操作括号错误精度不够错误的内置函数2.1软件缺陷概述112.1.3软件缺陷的种类接口缺陷不正确的中断处理I/O时序有错调用了错误的过程调用了不存在的过程参数不匹配不兼容的类型2.1软件缺陷概述122.1.3软件缺陷的种类数据缺陷不正确的初始化不正确的存储/访问错误的标志/索引值不正确的打包/拆包使用了错误的变量错误的数据引用缩放数据范围或单位错误2.1软件缺陷概述不正确的数据维数不正确的下标不正确的类型不正确的数据范围传感器数据超出限制不一致数据132.1.4软件缺陷的产生软件缺陷的来源疏忽造成的错误（Carelessnessdefect，CD）不理解造成的错误（Misapprehenddefect，MD）二义性造成的错误(Ambiguitydefect，AD)遗漏造成的错误（Skipdefect，SD）MD、AD、SD三类缺陷主要存在于软件开发的前期阶段，而在实施第三方测试时，一般不会存在这三类缺陷。由疏忽造成的错误是必然的，也是多种多样的，此类错误不可预测也不可估计。2.1软件缺陷概述142.1.4软件缺陷的产生疏忽造成的错误（CD）的主要来源显式约束造成的错误：设A是程序中的一个元素（一条语句、语句的一部分、语句的集合），由于A，在A之前或之后必须要跟另外一个动作B，则称为显式约束。如果B不存在或B不是A所要求的，则都是错误。隐式约束造成的错误：设A是程序中的一个元素（一条语句、语句的一部分、语句的集合），根据程序的语义，A必须满足某些约束，否则就是错误。2.1软件缺陷概述152.1.5软件缺陷数目估计撒播模型静态模型覆盖率预测模型2.1软件缺陷概述16乒乓球法（参入黑球）撒播模型是利用概率论的方法来估算程序中的错误数目，其基本原理类似于估计一个大箱子中存放的乒乓球的数目。假设一个大箱子里有许多白色的乒乓球N，向箱子里置入M个黑色的乒乓球，并将箱中的球搅拌均匀，然后，从箱子中随机的取出足够多的球，假设白色的乒乓球有n个，黑色的乒乓球m个，则可以根据下列公式估计N撒播模型17Mills缺陷预测（植入缺陷）用人工随机的向待估算的软件置入错误；然后进行测试，待测试到足够长的时间后，对所测试到的错误进行分类，看看哪个是人工置入的错误，哪个是程序中固有的错误；最后，根据上述公式即可估算出程序中所有的错误。缺点程序中固有的缺陷是未知的，每个错误被检测的难易程度也同样是未知的。人工置入的缺陷是否和程序中存在缺陷检测的难易程度一致也是未知的。撒播模型18Hyman缺陷预测（相同缺陷）假设软件总的排错时间是X个月，即经过X个月的排错时间，假设程序中将不再存在错误。让两个人共同对程序进行排错，假设经过足够长(X的一半或更少)的排错时间后，第一个人发现了n个错误，第二个人发现了m个错误，其中属于两个人共同发现的错误有m1个，则公式为：撒播模型19Akiyama模型谓词模型Halstead模型Lipow模型Gaffnev模型ComptonandWithrow模型静态模型20Akiyama模型N=4.86+0.018*L其中：N是缺陷数；L是可执行的源语句数目。基本的估计是1KLOC有23个缺陷。这是早期的研究成果。该模型可能对某个人或某类专门的程序是有效的，模型的提出明显是一种实践上的统计结果。该模型太简单了，实际价值不大。静态模型21谓词模型N=C+J其中：C是谓词数目，J是子程序数目。程序的许多错误来自于程序中包含的谓词。但将每个谓词和子程序都假定一个错误也显然是不合适的，但也没有其他更好的办法来准确地描述它们之间的关系。总之，该模型也有一定的参考价值。静态模型22Halstead模型N=V/3000其中：V=x*lny，x=x1+x2，y=y1+y2x1：程序中使用操作符的总次数；x2：程序中使用操作数的总次数；y1：程序中使用操作符的种类；y2：程序中使用操作数的种类；根据Halstead的理论，V是程序的体积，即程序占内存的比特数目，该模型认为，平均3000bit就有一个错误。该模型和Akiyama模型有些类似，也完全是大量程序的统计结果，但难以说清楚哪一个更好。静态模型23Lipow模型N=L*(A0+A1*InL+A2*ln2L)Fortran语言：A0=0.0047，A1=0.023，A2=0.000043。汇编语言：A0=0.0012，A1=0.0001，A2=0.000002。显然，这也是一个统计结果。不同的是，该模型区分了高级语言和低级语言。静态模型24Gaffnev模型N=4.2+0.0015L4／3解此方程可推断出一个模块的最佳尺寸是877LOC。静态模型25ComptonandWithrow模型N=0.069+0.00156L+0.00000047L2由该方程可推断出一个模块的最佳尺寸是83LOC静态模型26错误与时间曲线错误与覆盖率曲线覆盖率与时间曲线覆盖率预测模型27错误与时间错误数时间t1

改用新的测试方法28错误与覆盖率错误数覆盖率0.50.9529覆盖率与时间覆盖率时间t130软件测试的检测能力分析每种测试方法检测缺陷的能力不同。2.1.6软件测试效率分析31软件测试阶段测试能力非形式化的设计检查

25%～40%形式化的设计检查

45%～65%非形式化的代码检查20%～35%形式化的代码检查45%～70%单元测试15%～50%新功能测试

20%～35%回归测试

15%～30%集成测试

25%～40%系统测试

25%～55%低强度的β测试(<10客户)20%～40%高强度的β测试(>1000客户)60%～85%影响软件测试效率的因素人为因素：不同水平层次的测试人员在发现软件错误的数量和测试效率存在差异。2.1.6软件测试效率分析32

阶段测试者水平层次初级中级高级平均值标准差平均值标准差平均值标准差发现错误的个数13.881.894.071.69

23.042.073.831.64

33.901.834.181.995.001.53发现错误的效率11.360.972.221.66

21.000.850.960.74

32.142.482.532.482.361.61影响软件测试效率的因素软件类型：软件类型也是影响测试效率的一个重要因素。2.1.6软件测试效率分析33

阶段程

序P1P2P3P4平均值标准差平均值标准差平均值标准差平均值标准差发现错误的个数14.071.623.481.454.282.25

23.232.203.311.97

3.311.8434.191.73

5.221.753.411.66发现错误的效率11.601.391.190.832.091.42

20.980.670.710.71

1.051.0432.151.10

3.703.261.140.79影响软件测试效率的因素缺陷类型初始化错误：初始化代码中的错误；控制错误：控制转移的条件或转移地址错误；数据错误：包括程序中的常数、数据库中的数据错误等；计算错误：计算代码错误集成错误：各模块之间、软件与环境之间的错误容貌错误：人机界面、打印格式等错误。2.1.6软件测试效率分析34影响软件测试效率的因素2.1.6软件测试效率分析352.2.1缺陷管理的目标确保每个被发现的缺陷都能够被解决这里解决的意思不一定是被修正，也可能是其他处理方式(例如，在下一个版本中修正或不修正)。收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。2.2软件缺陷管理362.2.1缺陷管理的目标收集缺陷数据并在其上进行数据分析，作为组织的过程财富在对软件缺陷进行管理时，必须先对软件缺陷数据进行收集，然后才能了解这些缺陷，并且找出预防和修复它们的方法，以及预防引入新的缺陷。2.2软件缺陷管理372.2.2缺陷报告38一个完整的缺陷报告需要包含以下的信息:ID唯一的识别缺陷的序号标题对缺陷的概括性描述，方便快速浏览、管理等前提在进行实际执行的操作之前所具备的条件环境缺陷发现时所处的测试环境，包括操作系统、浏览器等操作步骤导致缺陷产生的操作顺序的描述期望结果按照客户需求或设计目标事先定义的操作步骤导出的结果。期望结果应与用户需求、设计规格说明书等保持一致实际结果按照操作步骤而实际发生的结果。实际结果和期望结果是不一致的，它们之间存在差异频率同样的操作步骤导致实际结果发生的概率严重程度指因缺陷引起的故障对软件产品使用或某个质量特性的影响程度。其判断完全是从客户的角度出发，由测试人员决定。一般分为4个级别，包括：致命、严重、一般、微小优先级缺陷被修复的紧急程度或先后次序，主要取决于缺陷的严重程度、产品对业务的实际影响，但要考虑开发过程的需求(对测试进展的影响)、技术限制等因素，由项目管理组(产品经理、测试/开发组长)决定。一般分为4个级别，包括：立即解决、高优先级、正常排队、低优先级类型属于哪方面的缺陷，如功能、用户界面、性能、接口、文档、硬件等缺陷提交人缺陷提交人的名字(会和邮件地址联系起来)，即发现缺陷的测试人员或其他人员2.2.2缺陷报告39缺陷指定解决人估计修复这个缺陷的开发人员，在缺陷状态下由开发组长指定相关的开发人员；自动和该开发人员的邮件地址联系起来。当缺陷被报出来时，系统会自动发出邮件来源缺陷产生的地方，如产品需求定义书、设计规格说明书、代码的具体组件或模块、数据库、在线帮助、用户手册等产生原因产生缺陷的根本原因，包括过程、方法、工具、算法错误、沟通问题等，以寻求流程改进、完善编程规范和加强培训等，有助于缺陷预防构建包跟踪用于每日构建软件包跟踪，是新发现的缺陷，还是回归缺陷，基准(baseline)是上一个软件包版本跟踪用于产品版本质量特性的跟踪，是新发现的缺陷，还是回归缺陷，基准是上一个版本提交时间缺陷报告提交的时间修正时间开发人员修正缺陷的时间验证时间测试人员验证缺陷并关闭这个缺陷的时间所属项目/模块缺陷所属哪个具体的项目或模块，要求精确定位至模块、组件级产品信息属于哪个产品、哪个版本等状态当前缺陷所处的状态，见2.2.32.2.3软件缺陷管理流程2.2软件缺陷管理402.2.3软件缺陷管理流程缺陷管理流程中的角色测试人员A1：进行测试的人员，并且是缺陷的发现者；项目经理A2：对整个项目负责，对产品质量负责的人员；开发人员A3：执行开发任务的人员，完成实际的设计和编码工作，以及对缺陷的修复工作；评审委员会A4：对缺陷进行最终确认，在项目成员对缺陷不能达成一致意见时，行使仲裁权力。2.2软件缺陷管理412.2.3软件缺陷管理流程缺陷管理流程中的缺陷状态初始化：缺陷的初始状态；待分配：缺陷等待分配给相关开发人员处理；待修正：缺陷等待开发人员修正；待验证：开发人员已完成修正，等待测试人员验证；待评审：开发人员拒绝修改缺陷，需要评审委员会评审；关闭：缺陷已被处理完成。2.2软件缺陷管理422.2.3软件缺陷管理流程缺陷管理流程描述测试小组发现新的缺陷，并记录缺陷，此时缺陷状态为“初始化”。测试小组向项目经理提交新发现的缺陷(包括缺陷的基本信息)，此时缺陷的状态为“待分配”。项目经理接收到缺陷报告后，根据缺陷的详细信息，确定处理方案，此时缺陷的状态为“待修正”。缺陷报告被分配给相应的开发人员，开发人员对缺陷进行修复，并填写缺陷的修改信息，然后等待测试人员对修复后的缺陷再一次进行验证，此时缺陷的状态为“待验证”。2.2软件缺陷管理43经测试人员验证后，发现缺陷未被修复，则重新交给原负责修复的开发人员，测试缺陷的状态为“待修正”。经测试人员验证后，认为缺陷被修复，则填写缺陷验证信息，缺陷修复完成，此时缺陷的状态为“关闭”。若测试人员验证缺陷未被修复，但是开发人员认为已修复完成拒绝再次修复，则将缺陷报告提交给评审委员会，等待评审委员会的评审，此时缺陷的状态为“待评审”。2.2软件缺陷管理44若评审委员会评审不通过，即软件缺陷未被修复，开发人员需继续修复，此时软件缺陷的状态为“待修正”。若评审委员会评审通过，即