11软件测试：软件测试评估教程

缺陷源 需求报告 设计 编码 文档 错误修改 合计
经典的种子公式
【示例】
假设：（所有缺陷被发现的概率是相同的）
已测试出的种子Bug(s) 已测试出的非种子Bug(n)
= 两个独立测试同一个程序，第一组发现25个错误，第二组发现 30个错误，在两个小组小组发现的错误 有15个是共同的，那么可以估计程序中错误的个数为： 所有的种子Bug(S) 全部的非种子Bug(N) A．25 B 30 C50 D 60
测试覆盖的内容

测试覆盖率是衡量测试完成多少的一个量化标准 测试用例覆盖率A 需求测试覆盖率B 代码测试覆盖率C
开发
代码
需求
测试
用例
测试需求的覆盖往往转化为测试用例的覆盖
基于需求的测试覆盖评估

已执行的测试覆盖
方式1:需求所对应的执行用例数/需求所对应的用例总数 方式2:执行用例数所对应的需求数/用例总数所对应需求数
软件测试评估
本章教学要点

教学目标：

通过本章学习，能针一个系统的测试情况，进行基本的质量评估。
Βιβλιοθήκη Baidu
教学重点与难点：
基于测试覆盖的评估：怎样根据测试数据从各个方面对覆盖情况作 一个评价 基于缺陷的评估：怎么利用已有的缺陷数据从统计和预测二方面入 手，对系统质量作一个判断 难点：如何估计缺陷遗留情况
则可以推出程序的总Bug数为：
【解答】缺陷注入法。
如果 n=N, Bug 已找出来，说明测试充分。 １）第一组测试出 25说明所有的 个缺陷，有15 个缺陷与第二组是相同的。假设将第 1组25个看作是注入缺陷 给第二组去测试，意味着注入的 25个总缺陷数有15个被发现。 存在问题：人为植入缺陷的代表性；缺陷本身的相互影响与关系； ２）第二组测试出30个缺陷；由于系统中的缺陷被测试出的概率相同的；
代码
？
用例
目标：代码语句100%全部执行
目录
1 ２
基于测试覆盖的评估
基于缺陷的评估
缺陷分析

缺陷趋势：按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的，
也可以是非累计的；（时间-缺陷数）

缺陷分布：将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺 缺陷指标：与基线数据(baseline)相比，评估产品缺陷数据是否达标。

陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。（缺陷数-缺陷属性）

缺陷密度：单位代码量/需求里的缺陷数量。衡量指标：缺陷数/KLOC或缺陷数/功 能点 缺陷去除率：事先发现缺陷数/ 事先发现缺陷数+ 事后发现/估计的缺陷数。对于发 布前的统计，建议值为95%


遗留缺陷数：根据已知缺陷数来估计程序中潜在的、未知缺陷数量。

成功的测试覆盖
方式1:需求所对应的执行成功用例数/需求所对应的用例总数 方式2:执行成功用例数所对应的需求数/用例总数所对应需求数
需求
需求ID
用例
目标：确保测试用例100%执行全部通过
基于代码的测试覆盖

基于代码的测试覆盖即是对被测试的程序语句、路径或条件的代码覆盖率分析 代码覆盖率分析一般由工具自动生成。对于一个大的系统来说，一般只需要达到语句 覆盖即可。 已执行代码覆盖=测试用例运行时所经过语句/测试对象总语句数 对于多次运行的结果归并 对于增量开发的测试对象总语句不总是代码全集
简单计数 + 统计建模
缺陷趋势
350 缺陷数量
40 300 35 30
250
新缺陷累计数 修复的缺陷累计数 被关闭的缺陷累计数
累计缺陷
25 200 20 15 5 0
150 100 10 50
31
38
33- 1 15 5
3- 3 22-2
31
38
-2 9
323 9
45
45
0
2
日期
412
缺陷分布：ODC分析
缺陷清除率的估算


D1：软件开发过程中发现的所有缺陷数； D2：软件发布后发现的缺陷数； D为发现的总缺陷数。因此，D=D1+D2。 整体缺陷清除率=D1/D；
已发生缺陷(Ｄ1) 77 106 166 48 24 500 交付后的缺陷(D2) 23 19 9 12 12 75 缺陷清除率(%) 77 85 95 80 70 85

ODC (Orthogonal Defect Classification)：由IBM提出，区别于传统的仅从严重等级、重要性等 分类，它定义了八个正交的缺陷属性用于对缺陷的分类 。正交性即指缺陷属之间不存在关联性 和重叠，各自独立。 Activity：缺陷被发现时实际的测试阶段。比如单元测试，功能测试，系统测试等等。 Trigger：暴露缺陷时存在的环境或者条件。 Impact：是指缺陷可能对用户造成的影响。 Target：将要在哪里改正错误，例如：design、code 等等。 Type：表示所进行的实际修正的种类，比如算法，接口，初始化等等。 Qualifier：所进行的修复应归于缺失，错误或者还是外来代码/信息。 Source：发现的缺陷来源，是出现在内部代码编写中，重用程序库中，从一个平台转移到 另一个平台，或者是外包软件销售商。 如果Interaction的BUG很多，增强接口评审 Age：确定这个缺陷是新代码还是旧代码，或者是重写的代码。
可以用公子公式来估算总缺陷数，15/25=30/X
N = S * n /s
统计建模：CompertZ分析


假设：测试对象同一性：只进行BUG修正、不合入新需求，测试对象不 发生质的变化；测试执行轮数>=2 输入：每天发现问题数，运用公式 Y=a*b^(c^T)

测试结束需要回答的问题？
一个产品的测试结束后，最终需要回答的问题：

产品质量如何？ 产品是否可以发布、上线？ 上线后可能存在哪些风险？ 测试是否充分、完备？
产品质量+测试质量
目录
1 ２
基于测试覆盖的评估
基于缺陷的评估
测试覆盖的评估
软件测试评估主要有两个的目的


量化测试过程，判断测试进行的状态和进度，测试什么时候可以结束 为测试或质量分析报告生成所需的量化数据，如缺陷清除率、测试覆盖率等 测试覆盖项 界面覆盖 功能覆盖 代码覆盖 需求覆盖 故障覆盖 测试覆盖率指标测试描述 多少界面经过测试符合界面规范要求程度 多少功能经过测试满足需求程度 多少代码经过测试覆盖程度如何 多少需求经过测试符合度如何 多少故障模式经过测试满足程度如何 测试结果