第六讲测试与缺陷管理

如何表示缺陷的严重性和优先级


缺陷的严重性和优先级通常按照级别划分，各 个公司和不同项目的具体表示方式有所不同。 为了尽量准确的表示缺陷信息，通常将缺陷的 严重性和优先级分成4级。如果分级超过4级， 则造成分类和判断尺度的复杂程度，而少于4 级，精确性有时不能保证。
软件缺陷管理指南 -收集缺陷
单元测试的技术手段

单元测试主要通过编写测试代码实现； 单元测试代码一般需要一个支持框架来运行所 有的测试用例； JUnit ——是一个开发源代码的Java测试框架， 用于编写和运行可重复的测试。是用于单元测 试框架体系xUnit的一个实例（用于java语 言）。主要用于白盒测试，回归测试。
缺陷来源

Requirement由于需求的问题引起的缺陷 Architecture由于构架的问题引起的缺陷 Design由于设计的问题引起的缺陷 Code由于编码的问题引起的缺陷 Test由于测试的问题引起的缺陷 Integration由于集成的问题引起的缺陷
软件缺陷的严重性和优先级
单元测试概述



程序员在编写实现的任何部分之前就开始编写它们，并继续为功能的 每个新的方面编写更多的单元测试。 覆盖软件项目的一套严格的单元测试提供两个巨大的好处： 1.他们可以是文档化的。 2.它们加速了重构过程。 单元测试与静态类型类似，是文档的 可执行形式。因为单元测试理想 地覆盖了实现的所有方面，也因为它们用简单的方式调用了功能以确 定其是否正常运行，正在加入项目的或开始维护某些代码的程序员只 要通读单元测试，就能够容易地确定各种功能组件的用途。 单元测试加速了重构的过程。当一套单元测试可以在任何时间在代码 上运行以确定是否有功能损坏时，程序员可以比在其它任何情况下更 有信心重构代码。所引入的绝大多数错误可以被立即检测出来。
软件缺陷管理指南-解决优先级
立即解决（Resolve
Immediately） 缺陷必须被立即解决。 正常排队（Normal Queue）缺陷需 要正常排队等待修复或列入软件发 布清单。 不紧急（Not Urgent）缺陷可以在 方便时被纠正。
一般的缺陷管理过程

Tester发现Bug,登记到缺陷管理系统-> 开发team讨论分配bug-> 开发责任人完成修改,到缺陷管理系统登记处 理结果-> tester确认处理结果-> Bug被正确修复/Bug修复不成功，继续上述过 程
第六讲测试与缺陷管理
Baidu Nhomakorabea
目录
1.测试 1.1关于测试的几个事实 1.2单元测试 2.缺陷管理
关于测试的事实1


普通程序员认为已经彻底测试过的软件其实只执行了 55 % -60%的逻辑路径。采用覆盖分析器等自动工具， 可以将比例提高到85%-90%，几乎不可能测试软件中 100%的逻辑路径； 思考（通过不同的测试方法来思考上述事实） 需求驱动测试 结构驱动测试 统计驱动测试（随机驱动测试） 风险驱动测试
缺陷的严重性和优先级的关系



缺陷的严重性和优先级是含义不同但相互联系密切 的两个概念。它们都从不同的侧面描述了软件缺陷 对软件质量和最终用户的影响程度和处理方式。 一般地，严重性程度高的软件缺陷具有较高的优先 级。严重性高说明缺陷对软件造成的质量危害性大， 需要优先处理，而严重性低的缺陷可能只是软件不 太尽善尽美，可以稍后处理。 但是，严重性和优先级并不总是一一对应。有时候 严重性高的软件缺陷，优先级不一定高，甚至不需 要处理，而一些严重性低的缺陷却需要及时处理， 具有较高的优先级。

软件缺陷管理指南-缺陷严重程度分析



严重缺陷（Critical）不能执行正常工作功能或重要 功能。或者危及人身安全 较大缺陷（Major）严重地影响系统要求或基本功能的 实现，且没有办法更正。（重新安装或重新启动该软 件不属于更正办法） 较小缺陷（Minor）严重地影响系统要求或基本功能的 实现，但存在合理的更正办法。（重新安装或重新启 动该软件不属于更正办法） 轻微缺陷（Cosmetic）使操作者不方便或遇到麻烦， 但它不影响执行工作功能或重要功能。 其他缺陷（Other）其它错误
按照缺陷的类型进行归类，比如按功能，语法，赋值， 文档，环境等等进行分类 可以按照以下步骤收集记录关于缺陷的数据： ◆ 为测试和同行评审中发现的每一个缺陷做一个记录 ◆ 对每个缺陷要记录足够详细的信息，以便以后能更好 地了解这个缺陷 ◆ 分析这些数据以找出主要哪些缺陷类型引起大部分的 问题 ◆ 设计出发现和修复这些缺陷的方法（缺陷排除）
单元测试的主要考虑因素（3）

如果模块内包括外部输入输出，还应该考虑下 列因素： 1 文件属性是否正确； 2 OPEN/CLOSE语句是否正确； 3 格式说明与输入输出语句是否匹配； 4缓冲区大小与记录长度是否匹配； 5文件使用前是否已经打开； 6是否处理了文件尾； 7是否处理了输入/输出错误； 8输出信息中是否有文字性错误；
对程序员来说，最贴近的是单元测试。我们有效测试仅仅涉及单 元测试 单元测试是最细粒度的测试，是针对最基本的软件构成单位-功 能块的测试

1 2 3 4 5
单元测试任务包括： 模块接口测试； 模块局部数据结构测试； 模块边界条件测试； 模块中所有独立执行通路测试； 模块的各条错误处理通路测试。
单元测试的主要考虑因素（1）
单元测试的主要考虑因素（2）

6调用其他模块时所给实际参数的量纲是否与 被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属性和 次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数； 10 对全程变量的定义各模块是否一致； 11是否把某些约束作为参数传递。
JUnit安装
http://download.sourceforge.net
/junit/中下载JUnit包 按照安装指南安装
缺陷管理
软件工程的事实

错误消除是软件生命周期中最耗时的阶段； 需求，设计，编码，测试改错占到软件开发过 程时间的比例大概为：20：20：20：40
什么是软件缺陷

-免费且开放源代码、基于Web的精简版Bug管 理系统,由PHP编写，使用MySql数据库。
国内开源的BugFree管理工具(参见截图)

新建Bug 编辑Bug（更新Bug状态等） 查看Bug 解决Bug 激活Bug Bug列表 报表
国内开源的BugFree管理工具
注意，一般系统中一个Bug有7种解决状态：



By Design - 就是这么设计的，无效的Bug Duplicate - 这个问题别人已经发现了，重复的Bug External - 是个外部因素(比如浏览器、操作系统、其他 第3方软件)造成的问题 Fixed - 问题被修理掉了。Tester要尽可能找到这种Bug Not Repro - 无法复现你这个问题，无效的Bug Postponed - 是个问题，但是目前不必修理了，推迟到以 后再解 Won't Fix - 是个问题，但是不值得修理了，不管它吧
JUnit优点

A、可以使测试代码与产品代码分开。 B、针对某一个类的测试代码通过较少的改动便可以应 用于另一个类的测试。 C、易于集成到测试人员的构建过程中，JUnit和Ant 的结合可以实施增量开发。 D、JUnit是公开源代码的，可以进行二次开发。 E、可以方便地对JUnit进行扩展。
JUnit框架组成
缺陷严重程度



Critical不能执行正常工作功能或重要功能。或者危 及人身安全。 Major严重地影响系统要求或基本功能的实现，且没有 办法更正。（重新安装或重新启动该软件不属于更正 办法） Minor严重地影响系统要求或基本功能的实现，但存在 合理的更正办法。（重新安装或重新启动该软件不属 于更正办法） Cosmetic使操作者不方便或遇到麻烦，但它不影响执 行工作功能或重要功能。 Other其它错误。

软件缺陷(software defect)是对软件产品预 期属性的偏离现象。它包括检测缺陷和残留 缺陷。每一个软件组织都知道必须妥善处理 软件中的缺陷。这是关系到软件组织生存、 发展的质量根本。 软件缺陷也就是通常所说 的Bug；
缺陷的主要属性




缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。 每个缺陷必须有一个唯一的标识 缺陷类型 (Type)：缺陷类型是根据缺陷的自然属性划分的缺陷 种类。 缺陷严重程度 (Severity)缺陷严重程度是指因缺陷引起的故障 对软件产品的影响程度。 缺陷优先级(Priority)缺陷的优先级指缺陷必须被修复的紧急程 度。 缺陷状态(Status)缺陷状态指缺陷通过一个跟踪修复过程的进展 情况。 缺陷起源(Origin)缺陷来源指缺陷引起的故障或事件第一次被检 测到的阶段。 缺陷来源(Source)缺陷来源指引起缺陷的起因。 缺陷根源(Root Cause)缺陷根源指发生错误的根本因素。
关于测试的事实2
即使测试覆盖有可能达到100%，这种测试也是 不够的。（无法保证软件完美无缺） 说明： 大约35%的错误是源于逻辑路径的缺失，40% 的错误源于执行特定的路径组合。

测试分类
按照在不同的软件生命期有不同的测试 1.单元测试 2.集成测试 3.系统测试 4.实地测试

单元测试




严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程 度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影 响。 在软件测试中，软件缺陷的严重性的判断应该从软件最终用户 的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺 陷对用户使用造成的恶劣后果的严重性。 优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些 缺陷需要优先修正，哪些缺陷可以稍后修正。 确定软件缺陷优先级，更多的是站在软件开发工程师的角度考 虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹 技术问题，而且开发人员更熟悉软件代码，能够比测试工程师 更清楚修正缺陷的难度和风险。

缺陷既指程序中存在的错误，例如语法错误、 拼写错误或者是一个正确的程序语句，缺陷也 指可能出现在设计中，甚至在需求、规格说明 或其他的文档中的种种错误。为了对缺陷进行 管理，首先应对缺陷进行分类，通过对缺陷进 行分类，可以迅速找出哪一类缺陷的问题最大， 然后集中精力预防和排除这一类缺陷。
软件缺陷管理指南 –分类记录缺陷
缺陷管理工具
工具最基本要求 能记录问题点、能及时传达给相关人员，并监督 他们都作了适当的处理，更高级的工具还涵盖 了与需求、测试方案、代码、自动测试工具等 环境的集成。 文档记录式的Bug管理：Excel，Word 最著名缺陷管理系统： 开源：BugZilla；IBM：ClearQuest
国内开源的BugFree管理工具
缺陷状态
Submitted已提交的缺陷 Open确认“提交的缺陷”，等待处理 Rejected拒绝“提交的缺陷”，不需要 修复或不是缺陷 Resolved缺陷被修复 Closed确认被修复的缺陷，将其关闭

缺陷起源

Requirement在需求阶段发现的缺陷 Architecture在构架阶段发现的缺陷 Design在设计阶段发现的缺陷 Code在编码阶段发现的缺陷 Test在测试阶段发现的缺陷

模块接口测试是单元测试的基础。只有在数据能正确 流入、流出模块的前提下，其他测试才有意义。测试 接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否相同； 2 输入的实际参数与形式参数的属性是否匹配； 3 输入的实际参数与形式参数的量纲是否一致； 4 调用其他模块时所给实际参数的个数是否与被调模 块的形参个数相同； 5 调用其他模块时所给实际参数的属性是否与被调模 块的形参属性匹配；

A、对测试目标进行测试的方法与过程集合，可称为测 试用例(TestCase)。 B、测试用例的集合，可容纳多个测试用例(TestCase)， 将其称作测试包(TestSuite)。 C、测试结果的描述与记录。(TestResult) 。 D、测试过程中的事件监听者(TestListener)。 E、每一个测试方法所发生的与预期不一致状况的描述， 称其测试失败元素(TestFailure) F、JUnit Framework中的出错异常 （AssertionFailedError）。