1、软件测试评估 本章教学要点?教学目标：?通过本章学习，能针一个系统的测试情况，进行基本的质量评估。?教学重点与难点：?基于测试覆盖的评估：怎样根据测试数据从各个方面对覆盖情况作一个评价?基于缺陷的评估：怎么利用已有的缺陷数据从统计和预测二方面入手，对系统质量作一个判断 难点：如何估计缺陷遗留情况 测试结束需要回答的问题？?产品质量如何？?产品是否可以发布、上线？?上线后可能存在哪些风险？?测试是否充分、完备？一个产品的测试结束后，最终需要回答的问题：产品质量+测试质量 目录 基于缺陷的评估 1 基于测试覆盖的评估 测试覆盖的评估 软件测试评估主要有两个的目的?量化测试过程，判断测试进行的状态和
2、进度，测试什么时候可以结束?为测试或质量分析报告生成所需的量化数据，如缺陷清除率、测试覆盖率等 测试覆盖项 测试覆盖率指标测试描述 测试结果 界面覆盖 多少界面经过测试符合界面规范要求程度 功能覆盖 多少功能经过测试满足需求程度 代码覆盖 多少代码经过测试覆盖程度如何 需求覆盖 多少需求经过测试符合度如何 故障覆盖 多少故障模式经过测试满足程度如何 测试覆盖的内容?测试覆盖率是衡量测试完成多少的一个量化标准?测试用例覆盖率A?需求测试覆盖率B?代码测试覆盖率C 需求 代码 用例 开发 测试 测试需求的覆盖往往转化为测试用例的覆盖 基于需求的测试覆盖评估?已执行的测试覆盖 方式1:需求所对应的执
3、行用例数/需求所对应的用例总数 方式2:执行用例数所对应的需求数/用例总数所对应需求数?成功的测试覆盖 方式1:需求所对应的执行成功用例数/需求所对应的用例总数 方式2:执行成功用例数所对应的需求数/用例总数所对应需求数 目标：确保测试用例100%执行全部通过 需求 用例 需求ID 基于代码的测试覆盖?基于代码的测试覆盖即是对被测试的程序语句、路径或条件的代码覆盖率分析?代码覆盖率分析一般由工具自动生成。对于一个大的系统来说，一般只需要达到语句覆盖即可。?已执行代码覆盖=测试用例运行时所经过语句/测试对象总语句数?对于多次运行的结果归并?对于增量开发的测试对象总语句不总是代码全集 用例 代码？
4、目标：代码语句100%全部执行 目录 基于缺陷的评估 1 基于测试覆盖的评估 缺陷分析?缺陷趋势：按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的；（时间-缺陷数）?缺陷分布：将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。（缺陷数-缺陷属性）?缺陷指标：与基线数据(baseline)相比，评估产品缺陷数据是否达标。?缺陷密度：单位代码量/需求里的缺陷数量。衡量指标：缺陷数/KLOC或缺陷数/功能点?缺陷去除率：事先发现缺陷数/事先发现缺陷数+事后发现/估计的缺陷数。对于发布前的统计，建议值为9
5、5%?遗留缺陷数：根据已知缺陷数来估计程序中潜在的、未知缺陷数量。简单计数+统计建模 缺陷趋势 缺陷数量05101520253035403-13-83-153-223-294-50501001502002503003503-13-83-153-223-294-54-12日期累计缺陷新缺陷累计数修复的缺陷累计数被关闭的缺陷累计数缺陷分布：ODC分析?ODC(Orthogonal Defect Classification)：由IBM提出，区别于传统的仅从严重等级、重要性等分类，它定义了八个正交的缺陷属性用于对缺陷的分类。正交性即指缺陷属之间不存在关联性和重叠，各自独立。?Activity：缺陷被
6、发现时实际的测试阶段。比如单元测试，功能测试，系统测试等等。?Trigger：暴露缺陷时存在的环境或者条件。?Impact：是指缺陷可能对用户造成的影响。?Target：将要在哪里改正错误，例如：design、code 等等。?Type：表示所进行的实际修正的种类，比如算法，接口，初始化等等。?Qualifier：所进行的修复应归于缺失，错误或者还是外来代码/信息。?Source：发现的缺陷来源，是出现在内部代码编写中，重用程序库中，从一个平台转移到另一个平台，或者是外包软件销售商。?Age：确定这个缺陷是新代码还是旧代码，或者是重写的代码。如果Interaction 的BUG很多，增强接口评
7、审 缺陷清除率的估算?D1：软件开发过程中发现的所有缺陷数；?D2：软件发布后发现的缺陷数；?D为发现的总缺陷数。因此，D=D1+D2。整体缺陷清除率=D1/D；缺陷源 已发生缺陷(1)交付后的缺陷(D2)缺陷清除率(%)需求报告 77 23 77 设计 106 19 85 编码 166 9 95 文档 48 12 80 错误修改 24 12 70 合计 500 75 85 经典的种子公式?假设：（所有缺陷被发现的概率是相同的）已测试出的种子Bug(s)已测试出的非种子Bug(n)所有的种子Bug(S)全部的非种子Bug(N)=则可以推出程序的总Bug数为：N=S*n/s 如果 n=N,说明所
8、有的Bug已找出来，说明测试充分。?存在问题：人为植入缺陷的代表性；缺陷本身的相互影响与关系；【示例】两个独立测试同一个程序，第一组发现25个错误，第二组发现30个错误，在两个小组小组发现的错误有15个是共同的，那么可以估计程序中错误的个数为：A25 B 30 C50 D 60 【解答】缺陷注入法。）第一组测试出25个缺陷，有15个缺陷与第二组是相同的。假设将第1组25个看作是注入缺陷给第二组去测试，意味着注入的25个总缺陷数有15个被发现。）第二组测试出30个缺陷；由于系统中的缺陷被测试出的概率相同的；可以用公子公式来估算总缺陷数，15/25=30/X 统计建模：CompertZ分析?假设：
9、测试对象同一性：只进行BUG修正、不合入新需求，测试对象不发生质的变化；测试执行轮数=2?输入：每天发现问题数，运用公式 Y=a*b(cT)?Y表示随时间T发现的软件缺陷总数?a是当T时可能发现软件缺陷总数，即软件中所含的潜在缺陷总数。a*b是当T0时发现的软件缺陷数?c表示发现缺陷的增长速度?采用“非线性回归最小二乘法”拟合曲线函数，确定a,b,c值。统计建模：CompertZ分析示例 该软件产品的总缺陷数估计共有448.685个（极限缺陷数=449）若要想将发现缺陷率达到95%，需要发现缺陷数至少达到419.93个。则有：419.93=448.685*0.078(0.874T)，解得T=2
10、8?拟合曲线图为Y=a*b(cT)=448.685*0.078(0.874T)其它：测试过程度量?基础数据：?代码规模、需求数?用例规模：设计用例数、执行用例数?测试周期、工作量?测试执行数据、缺陷原始数据 度量维度 度量指标 基线参考值 结果值 测试设计效率 设计用例数/人天 50 测试执行效率 执行用例数/人天 20 用例密度 用例数/KLOC 80 缺陷密度 缺陷数/KLOC 7 用例命中率 缺陷数/百用例数 11 缺陷成本 人时/缺陷数 7 从效率/质量/成本 对 测试过程质量 进行分析 基线值来源于若干历史版本经验数据 测试报告及其模板 国家标准GB/T 17544 1998对测试报
11、告有了具体要求，对测试纪录、测试结果如实汇总分析，报告出来。测试报告参考结构：?产品标识；?用于测试的计算机系统(测试环境)?使用的文档及其标识 (测试依据)?产品描述、用户文档、程序和数据的测试结果；(测试结果)?与要求不符的清单；?针对建议的要求不符的清单，产品未作符合性测试的说明；?测试结束日期。对于一个发布版本，最主要的是：给出Pass or Not 的结论 本章小结?基于测试覆盖的评估?测试用例覆盖率/需求覆盖率/代码覆盖率?各种覆盖率的计算及之间关系。?基于缺陷的评估?基于已有缺陷的简单统计：缺陷趋势/缺陷分布、缺陷密度、缺陷去除率?基于已有缺陷的统计建模：缺陷去除率、遗留缺陷率?经典种子公式、缺陷注入
