软件缺陷测试和测试评估备课讲稿

《软件缺陷测试和测试评估备课讲稿》由会员分享，可在线阅读，更多相关《软件缺陷测试和测试评估备课讲稿（76页珍藏版）》请在金锄头文库上搜索。

1、软件测试与测试技术讲座由安博测试空间技术中心,第16讲：软件缺陷测试和测试评估,在程序中存在的软件缺陷如文档缺陷、代码缺陷、测试缺陷、过程缺陷，软件缺陷导致系统或部件不能实现其功能，引起系统的失效。对软件缺陷测试和测试评估是不可缺少的、相当重要的。在本讲中您能了解如下主要知识点： 软件缺陷的概述； 软件缺陷的生命周期； 软件缺陷的跟踪管理； 软件测试的评估。,161 软件缺陷的概述,1611 软件缺陷的定义 缺陷（bug）是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句，缺陷可能出现在设计中，甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能，引起系统的

2、失效。缺陷定义为： 软件没有达到产品说明书表明的功能； 程序中存在语法错误； 程序中存在拼写错误； 程序中存在不正确的程序语句； 软件出现了产品说明书中不一致的表现； 软件功能超出产品说明书的范围； 软件没有达到用户期望的目标； 测试员或用户认为软件的易用性差。,按照定义，将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。 文档缺陷 文档缺陷是指对文档的静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷； 代码缺陷 代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷； 测试缺陷 测试缺陷是指由测试执行活动发现的被测对象（被测对象一般是指可运行的代码

3、、系统，不包括静态测试发现的问题）的缺陷，测试活动主要包括内部测试、连接测试、系统集成测试、用户验收测试，测试活动中发现的缺陷为测试缺陷； 过程缺陷 过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员。,软件缺陷的类型 软件缺陷的类型分为：功能类、性能类、系统/模块接口类、用户界面类、数据处理类、流程类、提示信息类 软件包类、建议类、常识类、文档。软件缺陷类型请参见清华大学出版社软件测试与测试技术( 2008.11 )第1版第16章表16-1。,1614 BUG 状态 缺陷状态是指缺陷通过一个跟踪

4、修复过程的进展情况。BUG 状态分为： 激活或打开（Active or Open）：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。 已提交：测试员发现 BUG 后提交到 BUG 管理系统中的状态（初始状态）。 已修改(Fixed or Resolved)：已被程序员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证提交到 BUG 管理系统中的状态。 不修改（保留）：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改（由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷），其 BUG 的状态为不修改。

5、 延迟：根据目前项目进程或计划等情况，暂时延期的状态，缺陷可以在下一个版本中解决。 待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。 已验证：已经解决的并经过测试员复测的 BUG 的状态。 关闭：完全解决了，只供以后备查的状态 重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复，重新打开以前关闭的 bug 状态 (在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 ) 。,1615 BUG 的等级划分与优先级 1BUG 的等级划分 BUG 的等级划分为4级： 严重：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系统崩溃等错误。修改优先级为最

6、高，该级别需要程序员立即修改。 较高：统的主要功能部分丧失、数据不能保存，导致严重的问题或致命的错误。修改优先级为较高，该级别需要程序员尽快修改。 一般：系统的部分功能没有完全实现，但不影响用户的正常使用，如提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先级为中，该级别需要程序员修改。 轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字、操作者不方便。修改优先级为低，该级别需要程序员修改或不修改。,2BUG 的优先级 BUG 的优先级一般与 BUG 等级挂钩分为4级： 1级（严重）：立即解决。缺陷导致系统几乎不能使用或测试不能继续，需立即修复。 2级（较高）：缺

7、陷严重，影响测试，需要优先考虑。 3级（一般）：正常排队缺陷需要正常排队等待修复。 4级（轻微）：缺陷可以在开发人员有时间的时候被纠正。,1616 软件缺陷的缺陷标识种类和属性 1缺陷标识 缺陷标识是指是标记某个缺陷的唯一的表示，可以使用数字序号表示，如表16-2所示。 缺陷标识是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。,2 软件缺陷的种类 软件缺陷的种类有如下15点内容： （1）功能不正常； （2）软件在使用上不方便； （3）软件的结构未做良好规划； （4）功能不充分； （5）与软件操作者的互动不良； （6）使用性能不佳； （7）未

8、做好错误处理； （8）边界错误； （9）计算错误； （10）使用一段时间所产生的错误； （11）控制流程的错误； （12）在大数据量压力之下所产生的错误； （13）在不同硬件环境下产生的错误； （14）版本控制不良所产生的错误； （15）软件文档的错误。,3 软件缺陷的属性 软件缺陷的属性主要有如下10点内容： （1）缺陷标识； （2）缺陷描述与缺陷注释； （3）缺陷类型； （4）缺陷严重程度； （5）缺陷产生可能性； （6）缺陷的优先级； （7）缺陷状态； （8）软件缺陷的起源； （9）软件缺陷的来源； （10）缺陷根源。,1617 缺陷的起源来源和根源 1缺陷的起源 缺陷起源是指缺陷引起的

9、故障或事件第一次被检测到的阶段，给软件带来缺陷的原因有很多，需求、构架、设计、编码、测试、用户这里列举几点： 需求：参与人员的过度自信，在需求阶段产生的错误； 构架：人员之间的沟通交流不够，交流上有误解或者根本不进行交流，在系统构架设计阶段产生的错误； 设计 ：工期短，任务重，时间压力大，在程序设计阶段产生的错误； 编码： 在编码阶段程序设计本身有错误产生的错误； 测试：在测试阶段发现的缺陷； 用户：在用户使用阶段发现的错误。,2缺陷的来源 缺陷的来源是指缺陷所在的地方如需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等。 需求说明书：需求说明书的错误或不清楚引起的问题； 设计文档：

10、设计文档描述不准确。和需求说明书不一致的问题； 系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷； 数据流（库）：由于数据字典、数据库中的错误引起的缺陷； 程序代码：纯粹在编码中的问题所引起的缺陷。,3 缺陷的根源 缺陷的根源是指造成软件错误的根本因素如测试策略、过程工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境等。 测试策略：错误的测试范围，误解测试目标，超越测试能力等； 过程工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等； 团队/人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等

11、； 缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等； 硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等； 软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等； 工作环境：组织机构调整，预算改变，工作环境恶劣。,162软件缺陷的生命周期,1621 软件缺陷的生命周期 软件缺陷的生命周期是指一个软件缺陷被发现、报告到这个缺陷被修改、验证直至最后关闭的完整过程。软件缺陷的生命周期分为简单的软件缺陷生命周期和复杂的软件缺陷生命周期。 1 简单的软件缺陷生命周期 简单的软件缺陷生命周期 发现打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员

12、； 打开修复：开发人员再现、修改缺陷，然后提交测试人员去验证； 修复关闭：测试人员验证修改过的软件，关闭已不存在的缺陷。 发现打开修复关闭。 这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。,2 复杂的软件缺陷生命周期 复杂的软件缺陷生命周期 打开一个软件缺陷： 对软件缺陷进行bug审查，是程序员代码问题还是设计问题？ 是立即修改还是可以延期修改？ 审查决定软件缺陷是否应该修改； 审查可能认定软件缺陷应该在将来的同一时间考虑修改，但是在该版本软件中不修改。 一个软件缺陷看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到打开状态；如果能够重现，就进

13、行修正，修正后关闭，进行回归测试。 缺陷生命周期过程是测试员、程序员、管理者一起参与、协同测试工作的过程。缺陷状态不仅表示出缺陷被修改、终结的进程，同时还标明了测试员、程序员、管理者的职责。,1622 软件缺陷生命状态的定义 每一个软件缺陷都有6个生命状态：打开（Open）、缺陷修改（Working）、缺陷验证（Verify）、缺陷删除（Cancel）、缺陷关闭（Close）、缺陷延期（Defer）。它们的基本定义是： Open态-缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始； Working态-缺陷修改状态，程序员接收缺陷，正在修改中； Verify态-缺陷验证状态，程序员修改完毕，等

14、待测试员验证； Close态-缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭； Cancel态-缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态 （不做物理删除）； Defer态-缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷置为延期状态； 上述打开态、缺陷修改态、缺陷验证态，称为缺陷的活动态； 缺陷关闭态、缺陷删除态、缺陷延期态，称为缺陷的终结态。 软件缺陷的生命周期示意图如图16-1所示。,图16-1中： 典型的缺陷生命历程 典型的缺陷生命历程有三种过程： 打开态缺陷修改态缺陷验证态打开态/缺陷关闭态/缺陷删除态； 打开态缺陷关闭态/缺陷删除态； 打开态缺陷延期态。,2缺陷生命

15、状态的控制与转换 （1）当测试员报告一个缺陷，程序员接受打开（Open）态的缺陷，缺陷生命周期开始，为打开态； 打开态缺陷修改态缺陷验证态打开态/缺陷关闭态/缺陷删除态； 程序员接受打开态的缺陷，修改中可将其置为缺陷修改态、修改完毕可置为缺陷验证态； 测试员验证缺陷验证态的缺陷，确认修改结果正确，可将打开态置为缺陷关闭态；确认不是缺陷，可将打开态置为缺陷删除态；认修改结果不正确，可以将缺陷验证态置为打开态，要求程序员重新修改；打开态缺陷关闭态/缺陷删除态。 （2） 当测试员发现自己误报或重报了缺陷，可直接将打开态置为缺陷删除态； 当测试员发现一个缺陷由于其它缺陷的修改而随之消失，可直接将打开态

16、缺陷置为缺陷关闭态；打开态缺陷延期态。 （3）管理者确认缺陷需延期修改或追踪，可将打开态缺陷置为缺陷延期态； 此外，终结态必要时可以重新打开： 在适当的时候，管理者可将缺陷延期态改为打开态，要求程序员修改； 在复查缺陷处理结果时，发现缺陷关闭态或缺陷删除态的处理有误，测试员可以将缺陷关闭或缺陷删除态重新置为打开态，要求程序员重新修改； 一般在测试初期，活动态的缺陷数会急剧上升，随着程序员、测试员的处理逐渐转为终结态。当所有软件缺陷的状态都转变为终结态，且在一段时间内没有被打开，也没有新的缺陷发生，即意味着测试可以结束或告一段落。,16.3 软件缺陷的跟踪管理,1631 软件缺陷测试报告 软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。如果，测试中发现缺陷，需要报告。 1报告软件缺陷的原则 （1）尽快报告软件缺陷 （2）有效地描述软件缺陷 有效的软件缺陷描述要求如下： 简单与短小； 明确指明错误类型； 单一； 使用IT业界惯用的表达术语和表达方法。 （3）