软件缺陷测试和测试评估

null软件测试与测试技术讲座 由安博测试空间技术中心http://www.btestingsky.com/提供软件测试与测试技术讲座 由安博测试空间技术中心http://www.btestingsky.com/提供第16讲：软件缺陷测试和测试评估第16讲：软件缺陷测试和测试评估 在程序中存在的软件缺陷如文档缺陷、代码缺陷、测试缺陷、过程缺陷，软件缺陷导致系统或部件不能实现其功能，引起系统的失效。对软件缺陷测试和测试评估是不可缺少的、相当重要的。在本讲中您能了解如下主要 知识点 高中化学知识点免费下载体育概论知识点下载名人传知识点免费下载线性代数知识点汇总下载高中化学知识点免费下载 ： ★ 软件缺陷的概述； ★ 软件缺陷的生命周期； ★ 软件缺陷的跟踪管理； ★ 软件测试的评估。 16．1 软件缺陷的概述16．1 软件缺陷的概述16．1．1 软件缺陷的定义 缺陷（bug）是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句，缺陷可能出现在设计中，甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能，引起系统的失效。缺陷定义为： ★ 软件没有达到产品说明书表明的功能； 程序中存在语法错误； 程序中存在拼写错误； ★ 程序中存在不正确的程序语句； 软件出现了产品说明书中不一致的表现； 软件功能超出产品说明书的范围； 软件没有达到用户期望的目标； 测试员或用户认为软件的易用性差。 按照定义，将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。 ★ 文档缺陷 文档缺陷是指对文档的静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷； ★ 代码缺陷 代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷； ★　测试缺陷 　测试缺陷是指由测试执行活动发现的被测对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 ）的缺陷，测试活动主要包括内部测试、连接测试、系统集成测试、用户验收测试，测试活动中发现的缺陷为测试缺陷； ★　过程缺陷 　过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员。 16．1．2软件缺陷的特征 软件缺陷的特征主要有如下7点内容： ★单一准确 每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 ★可以再现（要求软件缺陷具有精确的步骤） 提供缺陷的精确操作步骤，容易看懂再现这个缺陷。 ★完整统一 提供完整、前后统一的软件缺陷的步骤和信息如：图片信息，Log文件等。 ★短小简练 通过使用关键词，使软件缺陷的标题的描述简练，准确解释产生缺陷的现象。如 “主页”、“导航栏”、“分辨率”等关键词。 ★特定条件 软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视特定条件如特定的操作系统、浏览器或某种设置等。 ★补充完整 测试人员发现bug 要保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。 ★不做评价 在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。 软件缺陷的类型 软件缺陷的类型分为：功能类、性能类、系统/模块接口类、用户界面类、数据处理类、流程类、提示信息类 软件包类、建议类、常识类、文档。软件缺陷类型请参见清华大学出版社《软件测试与测试技术》( 2008.11 )第1版第16章表16-1。 16．1．4 BUG 状态 缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。   BUG 状态分为： ★ 激活或打开（Active or Open）：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。 ★ 已提交：测试员发现 BUG 后提交到 BUG 管理系统中的状态（初始状态）。 ★  已修改(Fixed or Resolved)：已被程序员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证提交到 BUG 管理系统中的状态。 ★  不修改（保留）：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改（由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷），其 BUG 的状态为不修改。 ★ 延迟：根据目前项目进程或 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 等情况，暂时延期的状态，缺陷可以在下一个版本中解决。 ★ 待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。 ★  已验证：已经解决的并经过测试员复测的 BUG 的状态。 ★  关闭：完全解决了，只供以后备查的状态     重新打开：测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复，重新打开以前关闭的 bug 状态   (在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 ) 。 16．1．5 BUG 的等级划分与优先级    1．BUG 的等级划分 BUG 的等级划分为4级： ★ 严重：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系统崩溃等错误。修改优先级为最高，该级别需要程序员立即修改。 ★ 较高：统的主要功能部分丧失、数据不能保存，导致严重的问题或致命的错误。修改优先级为较高，该级别需要程序员尽快修改。 ★ 一般：系统的部分功能没有完全实现，但不影响用户的正常使用，如提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先级为中，该级别需要程序员修改。 ★ 轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字、操作者不方便。修改优先级为低，该级别需要程序员修改或不修改。 2．BUG 的优先级 BUG 的优先级一般与 BUG 等级挂钩分为4级： 1级（严重）：立即解决。缺陷导致系统几乎不能使用或测试不能继续，需立即修复。 2级（较高）：缺陷严重，影响测试，需要优先考虑。 3级（一般）：正常排队缺陷需要正常排队等待修复。 4级（轻微）：缺陷可以在开发人员有时间的时候被纠正。 16．1．6 软件缺陷的缺陷标识种类和属性 1．缺陷标识 缺陷标识是指是标记某个缺陷的唯一的表示，可以使用数字序号表示，如表16-2所示。 缺陷标识是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。 2． 软件缺陷的种类 软件缺陷的种类有如下15点内容： （1）功能不正常； （2）软件在使用上不方便； （3）软件的结构未做良好规划； （4）功能不充分； （5）与软件操作者的互动不良； （6）使用性能不佳； （7）未做好错误处理； （8）边界错误； （9）计算错误； （10）使用一段时间所产生的错误； （11）控制流程的错误； （12）在大数据量压力之下所产生的错误； （13）在不同硬件环境下产生的错误； （14）版本控制不良所产生的错误； （15）软件文档的错误。 3． 软件缺陷的属性 软件缺陷的属性主要有如下10点内容： （1）缺陷标识； （2）缺陷描述与缺陷注释； （3）缺陷类型； （4）缺陷严重程度； （5）缺陷产生可能性； （6）缺陷的优先级； （7）缺陷状态； （8）软件缺陷的起源； （9）软件缺陷的来源； （10）缺陷根源。 16．1．7 缺陷的起源来源和根源 1．缺陷的起源 缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段，给软件带来缺陷的原因有很多，需求、构架、设计、编码、测试、用户这里列举几点： ★ 需求：参与人员的过度自信，在需求阶段产生的错误； ★ 构架：人员之间的沟通交流不够，交流上有误解或者根本不进行交流，在系统构架设计阶段产生的错误； ★ 设计 ：工期短，任务重，时间压力大，在程序设计阶段产生的错误； ★ 编码： 在编码阶段程序设计本身有错误产生的错误； ★ 测试：在测试阶段发现的缺陷； ★ 用户：在用户使用阶段发现的错误。 2．缺陷的来源 缺陷的来源是指缺陷所在的地方如需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等。 ★ 需求说明书：需求说明书的错误或不清楚引起的问题； ★ 设计文档：设计文档描述不准确。和需求说明书不一致的问题； ★ 系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷； ★ 数据流（库）：由于数据字典、数据库中的错误引起的缺陷； ★ 程序代码：纯粹在编码中的问题所引起的缺陷。 3． 缺陷的根源 缺陷的根源是指造成软件错误的根本因素如测试策略、过程工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境等。 ★ 测试策略：错误的测试范围，误解测试目标，超越测试能力等； ★ 过程工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等； ★  团队/人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等； ★  缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等； ★  硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等； ★  软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等； ★ 工作环境：组织机构调整，预算改变，工作环境恶劣。 16．2软件缺陷的生命周期16．2软件缺陷的生命周期16．2．1 软件缺陷的生命周期 软件缺陷的生命周期是指一个软件缺陷被发现、报告到这个缺陷被修改、验证直至最后关闭的完整过程。软件缺陷的生命周期分为简单的软件缺陷生命周期和复杂的软件缺陷生命周期。 1． 简单的软件缺陷生命周期 简单的软件缺陷生命周期 ★ 发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员； ★ 打开——修复：开发人员再现、修改缺陷，然后提交测试人员去验证； ★ 修复——关闭：测试人员验证修改过的软件，关闭已不存在的缺陷。 发现——〉打开——〉修复——〉关闭。 这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。 2． 复杂的软件缺陷生命周期 复杂的软件缺陷生命周期 打开一个软件缺陷： ★ 对软件缺陷进行bug审查，是程序员代码问题还是设计问题？ ★ 是立即修改还是可以延期修改？ ●审查决定软件缺陷是否应该修改； ●审查可能认定软件缺陷应该在将来的同一时间考虑修改，但是在该版本软件中不修改。 ★ 一个软件缺陷看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到打开状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。 缺陷生命周期过程是测试员、程序员、管理者一起参与、协同测试工作的过程。缺陷状态不仅表示出缺陷被修改、终结的进程，同时还标明了测试员、程序员、管理者的职责。 16．2．2 软件缺陷生命状态的定义 每一个软件缺陷都有6个生命状态：打开（Open）、缺陷修改（Working）、缺陷验证（Verify）、缺陷删除（Cancel）、缺陷关闭（Close）、缺陷延期（Defer）。它们的基本定义是： ★ Open态---缺陷初试状态，测试员报告一个缺陷，缺陷生命周期开始； ★ Working态---缺陷修改状态，程序员接收缺陷，正在修改中； ★ Verify态---缺陷验证状态，程序员修改完毕，等待测试员验证； ★ Close态---缺陷关闭状态，测试员确认缺陷被改正，将缺陷关闭； ★ Cancel态---缺陷删除状态，测试员确认不是缺陷，将缺陷置为删除状态 （不做物理删除）； ★ Defer态---缺陷延期状态，管理者确认缺陷需要延期修改或追踪，将缺陷置为延期状态； 上述打开态、缺陷修改态、缺陷验证态，称为缺陷的活动态； 缺陷关闭态、缺陷删除态、缺陷延期态，称为缺陷的终结态。 软件缺陷的生命周期示意图如图16-1所示。    图16-1中： 典型的缺陷生命历程 典型的缺陷生命历程有三种过程： ★ 打开态—〉缺陷修改态—〉缺陷验证态—〉打开态/缺陷关闭态/缺陷删除态； ★  打开态—〉缺陷关闭态/缺陷删除态； ★ 打开态—〉缺陷延期态。 2．缺陷生命状态的控制与转换 （1）当测试员报告一个缺陷，程序员接受打开（Open）态的缺陷，缺陷生命周期开始，为打开态； ★ 打开态—〉缺陷修改态—〉缺陷验证态—〉打开态/缺陷关闭态/缺陷删除态； ★ 程序员接受打开态的缺陷，修改中可将其置为缺陷修改态、修改完毕可置为缺陷验证态； ★ 测试员验证缺陷验证态的缺陷，确认修改结果正确，可将打开态置为缺陷关闭态；确认不是缺陷，可将打开态置为缺陷删除态；认修改结果不正确，可以将缺陷验证态置为打开态，要求程序员重新修改；打开态缺陷关闭态/缺陷删除态。 （2） 当测试员发现自己误报或重报了缺陷，可直接将打开态置为缺陷删除态；  当测试员发现一个缺陷由于其它缺陷的修改而随之消失，可直接将打开态缺陷置为缺陷关闭态；打开态—〉缺陷延期态 。 （3）管理者确认缺陷需延期修改或追踪，可将打开态缺陷置为缺陷延期态； 此外，终结态必要时可以重新打开：  ● 在适当的时候，管理者可将缺陷延期态改为打开态，要求程序员修改；  ● 在复查缺陷处理结果时，发现缺陷关闭态或缺陷删除态的处理有误，测试员可以将缺陷关闭或缺陷删除态重新置为打开态，要求程序员重新修改； 一般在测试初期，活动态的缺陷数会急剧上升，随着程序员、测试员的处理逐渐转为终结态。当所有软件缺陷的状态都转变为终结态，且在一段时间内没有被打开，也没有新的缺陷发生，即意味着测试可以结束或告一段落。 16.3 软件缺陷的跟踪管理16.3 软件缺陷的跟踪管理16．3．1 软件缺陷测试报告 软件中不可能没有缺陷，发现很多的缺陷对于测试工作来说，是件很正常的事。如果，测试中发现缺陷，需要报告。 1．报告软件缺陷的原则 （1）尽快报告软件缺陷 （2）有效地描述软件缺陷 有效的软件缺陷描述要求如下： ★ 简单与短小； ★ 明确指明错误类型； ★ 单一； ★ 使用IT业界惯用的表达术语和表达方法。 （3）在报告软件缺陷时不做任何评价 2．缺陷跟踪系统报告的信息 任何一个缺陷跟踪系统的核心都是“软件缺陷报告”， 缺陷跟踪系统报告的详细信息请参见清华大学出版社《软件测试与测试技术》( 2008.11 )第1版第16章表16-5所示。 3．跟踪软件缺陷手工报告记录 显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。文档如表16-6所示。 4． IEEE软件缺陷报告模板 ANS/IEEE829—1998 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 定义了一个称为软件缺陷报告的文档，用于报告“在测试期间发生的任何异常事件”。模板标准如表16-7所示。 16．3．2 缺陷类别 缺陷类别划分为5类：A 类、B 类、C类、D 类、E 类。 1．A 类 A类是由程序执行引起的死机、非法退出、死循环。 ★ 数据库发生死锁； ★ 数据库设计未达到范式的要求或需求规格说明的水平； ★ 数据功能实现错误； ★ 与数据库连接错误； ★ 数据通讯错误。 2．B 类 B类是由程序语法引起的错误。 ★ 因错误操作迫使程序中断。 ★ 数据库的表、业务规则、缺省值未加完整性。 3．C 类 C类是由操作界面引起的错误。 ★ 打印内容、格式错误； ★ 简单的输入限制未放在前台进行控制； ★ 删除操作未给出提示； ★ 数据库表中有过多的空字。 4．D类 D类是由界面不 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 引起的错误。 ★ 辅助说明描述不清楚； ★ 输入输出不规范； ★ 长操作未给用户提示； ★ 提示窗口文字未采用行业术语； ★ 可输入区域和只读区域没有明显的区分标志。 5．E类 E类是由遗漏部分功能引起的错误 ★ 实现功能与需求不相吻合。 16．3．3缺陷的分离和重现 软件缺陷的分离和再现是考验测试人员专业技能，测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。 1．缺陷的分离 缺陷分离的方法主要有： ★ 确保所有的测试步骤都被记录（记录每一个测试步骤、每一件工作）； ★ 注意时间和运行条件上的因素（查找时间依赖和竞争条件的问题(slow软盘、quick硬盘、时间发生次序)； ★ 注意软件的边界条件、内存容量和数据溢出的问题； ★ 注意事件发生次序导致的软件缺陷； ★ 考虑资源依赖性和内存、网络、硬件共享的相互作用； ★ 注意系统的压力条件； ★ 不能忽视硬件。与软件不同，硬件不按预定方式工作。 2．缺陷的重现 缺陷的重现要采取繁杂的步骤才能再现，或者根本无法再现。开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷的再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。 缺陷重现的方法同于缺陷分离的方法。 16．3．4软件缺陷跟踪系统 软件缺陷跟踪系统（Bug Tracking System）是用于记录、跟踪、并归类处理软件开发过程出现的 Bug 和硬件系统中存在的缺陷（defect）。集中管理软件测试过程中所发现缺陷的数据库程序，可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。目的是：保持进度、保证质量，提高整个机构的生产效率。 在测试工作中应用软件缺陷管理系统具有以下优点： ★ 保持高效率的测试过程； ★ 提高软件缺陷报告的质量； ★ 实施实时管理，安全控制； ★ 利于项目组成员间协同工作。 1．软件缺陷跟踪系统常用的功能要求 ★ 缺陷跟踪管理系统应采用B/S结构； ★ 采用标准技术，基于网络，多功能，快速，可靠，好用性好； ★ 无需在用户终端机器上装任何附加软件，可从网络上任何地方通过HTTP 或SMTP 联接； ★ 支持网页界面，内部网和外部网的用户均可使用； ★ 支持各种数据库系统，基于 SQL92 标准，使用开放型数据库设计，可升级； ★ 可设置性和多用途,不仅可用做 Bug 跟踪系统，而且可用做集成服务台热线流程管理； ★ 支持各种自定域数据类型，表格栏目可根据需要添加和删减； ★ 页面可做个性化调整，如添加公司标志等； ★ 可同时支持多个项目，设置访问权限，自我注册； ★ 可设置基于表格栏目域的多层次权限； ★ 自定义工作流程（对每个项目）； ★ 自动或手动分配任务负责人； ★ 可一次附加多个任何类型的文件； ★ 支持直接屏幕抓图（Screen capture）； ★ 具有自动自定义电子邮件通知功能； ★ 可通过电子邮件和文档版本管理软件 (CVS, Perforce) 集成； ★ 图表报告，高级搜索，自定义常用搜索； ★ 全面且易读的记录和修改历史； ★ 快速排序和导出（export)； ★ 支持目录服务(LDAP/Active Directory) 集成 ； ★ 具有自定义电子邮件提醒催单功能 (Reminder)； ★ 方便的基于网络的系统管理。 2. 软件缺陷跟踪系统的选用 软件缺陷跟踪系统（缺陷管理工具），现在网上可以查得到的缺陷管理软件有英文版的，也有中文版的，有要收费的，有免费提供的。国内外已出现了一批质量较好的缺陷管理工具，其中比较有代表性的有： ★ 开源软件Bugzilla、jira； ★ Compuware公司的TrackRecord ； ★ Rational公司的ClearQuest； ★ 北京航空航天大学的QAMonitor； ★ 上海微创软件有限公司的BMS等。 选用软件缺陷跟踪系统应该具备如下要求： ★ 安装简易、操作简易 ； ★ 支持开发、构建、测试、验收多重迭代； ★ 支持前台用户界面、后台缺陷数据库以及中间数据处理层； ★ 显示测试工作的成效和项目的进展情况； ★ 支持项目经理全程追踪督促 ； ★ 支持开发组长、测试组长多级指派； ★ 完整的追踪信息展现 ； ★ 支持发现软件错误的类型，错误的严重等级； ★ 支持发布版本的缺陷关联 ； ★ Mail实时通知缺陷任务 。16．4 软件测试的评估 16．4 软件测试的评估 软件测试的主要评测方法包括测试覆盖评估、质量评估、缺陷评估和性能测试评估。 16．4．1 测试覆盖评估 覆盖测试评估是对测试完全程度的评估，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。 覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖测试评估是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的评估，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。 1． 基于需求的测试覆盖评估 基于需求的测试覆盖在测试生命周期中要评估多次，每一个测试阶段结束时给出测试覆盖的度量。并在测试生命周期的各阶段（里程碑）提供测试覆盖的标识（如基于需求的、已计划的、已实施的、已执行的成功测试覆盖）。 基于需求的 基于需求的测试覆盖率通过以下公式计算： 测试覆盖率=T (p,i,x,s) / Rf T %   其中：T是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。RfT 是测试需求 (Requirement for Test) 的总数。 已计划的 在制定测试计划活动中，计划的测试覆盖通过以下公式计算： 计划的测试覆盖率=T p / Rf T % 其中：T p是用测试过程或测试用例表示的计划测试需求数。Rf T是测试需求的总数。 已实施的 在已实施的测试过程中，通过以下公式计算： 已执行的测试覆盖率=T i / Rf T % 其中：T i是用测试过程或测试用例表示的已执行的测试需求数。RfT是测试需求的总数。 已执行的成功测试 在已执行的成功测试活动中，确定成功的测试覆盖率通过以下公式计算： 成功的测试覆盖率=T s / Rf T % 其中：T s是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数。RfT是测试需求的总数。 2. 基于代码的测试覆盖评估 　基于代码的测试覆盖评估是根据测试已经执行的源代码的多少来表示的，这种测试覆盖策略类型对于安全至上的系统来说非常重要。测试覆盖评估已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。 基于代码的测试覆盖率通过以下公式计算： 基于代码的测试覆盖率=Ie / TIic% 其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic (Total number of Items in the code)是代码中的项目总数。 在软件测试评估工作中，基于代码的测试覆盖评估工作是有意义的，因为任何未经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级（例如单元和集成级）时最为有效，但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能说明代码是按照客户需求和设计的要求去做了。 软件测试的质量评估 质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。 软件测试的质量评估要重点注意如下10点内容： 1．软件测试质量评估准则 为了评估软件测试的质量,必须把不同特性的评价结果加以归纳，使用决策表或加权平均法,同时可以考虑其他因素,如在特定环境下对软件产品质量评估有影响的时间和成本。 软件测试的质量应根据质量特性的重要程度确定其权值，质量特性的重要程度可以根据软件类型的不同而有所不同。对于任务关键型的系统软件,其可靠性是最重要的；对于时间关键型的实时软件系统,其效率是最重要的；对于交互终端用户软件,其易用性是最重要的。 2. 软件质量评估过程 软件测试质量评估的一般过程： ★ 测量:把选定的度量应用到软件产品上去进行的活动 ★ 评级:根据等级定义确定某一测量值的等级 ★ 评估:将一组评出的等级加以归纳,得出软件产品质量报告.最后管理人员将归纳的质量与其他方面诸如时间和成本进行比较,根据管理准则作出决策,决定该产品是否通过验收或者是否发行。 软件测试质量评估目的 软件测试质量评估目的： ★ 确定产品是否通过验收； ★ 确定何时发布产品； ★ 与其他类似产品相比较,对产品进行选择； ★ 在使用该产品时评估其正面及负面的影响； ★ 确定何时优化或替换该产品。 4．软件测试质量评估的一般要求 ★ 质量度量的选择 ★ 对质量特性进行定义所采用的方式不提供对它们的直接测量,需要建立与软件产品的特性； ★ 相关的度量； ★ 度量可以因不同的环境和不同的开发阶段而异； ★ 根据用户观点采用的度量是关键的。 软件测试质量评估的等级 软件测试质量评估的等级要注意如下3 点内容： ★ 对可定量的特征可用质量度量来定量地测量,将测试结果与预先定义好的等级(如规定达到什么程度为优秀,达到什么程度为良好,达到什么程度为合格,什么情况下为差)比较,得到该软件特性的评价结果； ★ 质量与给定需求有关,不可能有通用的等级，每一次具体的评价都必须对等级进行定义； ★ 软应根据质量特性的重要程度确定其权值。 软件测试质量评估的内容 软件测试质量评估的内容主要有： ★ 功能性: 功能性是指与一组功能及其指定的性质有关的一组属性。 ★ 可靠性: 可靠性是指与在规定的一段时间和条件下,软件维持其性能水平的能力有关的一组属性。 ★ 易用性: 易用性是指与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性。 ★ 效率: 效率是指与在规定的条件下,软件的性能水平与所使用资源量之间关系有关的一组属性。 ★ 可维护性: 可维护性是指与进行指定的修改所需的努力有关的一组属性。 ★ 可移植性: 可移植性与软件可从某一环境转移到另一环境的能力有关的一组属性。 （1）功能性 功能性内容主要有： ★ 适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性； ★ 准确性:与能否得到正确或相符的结果或效果有关的软件属性； ★ 互用性:与同其他指定系统进行交互的能力有关的软件属性； ★ 依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性； ★ 安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。 （2）可靠性 可靠性内容主要有： ★ 成熟性:与由软件故障引起失效的频度有关的软件属性； ★ 容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性； ★ 易恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性。 （3） 易用性 易用性内容主要有： ★ 易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性； ★ 易学性:与用户为学习软件应用所花的努力有关的软件属性； ★ 易操作性:与用户为操作和运行控制所花努力有关的软件属性。 （4） 效率 效率内容主要有： ★ 时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性； ★ 资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。 （5） 可维护性 可维护性内容主要有： ★ 易分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性； ★ 易改变性:与进行修改,排除错误或适应环境变化所需努力有关的软件属性； ★ 稳定性:与修改所造成的未预料结果的风险有关的软件属性； ★ 易测试性:与确认已修改软件所需的努力有关的软件属性。 （6）可移植性 可移植性内容主要有： ★ 适应性:与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性； ★ 易安装性:与在指定环境下安装软件所需努力有关的软件属性； ★ 遵循性:使软件遵循与可移植性有关的标准或约定的软件属性； ★ 易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性。 软件测试质量评估的产品描述 产品描述主要注意： ★ 性质:产品描述是产品软件包文档的一部分,提供关于用户文档,程序, 数据(如适用)的信息； ★ 作用:帮助用户或潜在购买者作出产品是否适用的评价;作为测试的基础； ★ 内容要求 内容要求有如下8点： ● 一般要求：宜是充分可理解的,完整的并且易于浏览的应避免不一致,每个术语的前后意义应相同产品描述的说明应是可测试的并且是正确的。 ● 标识指示：产品描述应具有唯一的文档标识；产品标识应至少有产品名字和版本号或日期；产品描述应至少包含一个供方的名字和地址；产品描述应标识期望产品能完成的工作任务；产品描述应标识所引用的需求文档及其版本；应标识产品投入使用所要求的系统配置信息；产品描述应标识所引用其他产品接口或产品；应标识产品要交付的项目,包括文档和媒体；应说明产品安装是否由用户来完成；应说明是否提供对产品操作的支持；应说明是否提供维护及其具体内容。 ● 功能说明； ● 可靠性说明； ● 易用性说明； ● 效率说明； ● 可维护性说明； ● 可移植性说明。 软件测试质量评估的功能概述要求 ★ 应概述产品的用户可调用的功能及其数据和设施； ★ 边界值 应提供会致使产品的使用受限的特定边界值数据 ； ★ 安全 应包含有关防止对程序和数据非授权访问的手段； ★ 可靠性说明 应包含数据存储规程的信息；应描述保证产品的功能能力的附加性质；检验输入的合理性；防止由于用户的错误而产生的严重后果。 ★ 出错恢复 ★ 易用性说明 ★ 用户界面应命名用户界面的类型,如命令行,窗口,功能键要求的知识；应规定应用该产品所要求的专门知识和自然语言；适应用户的需要；应标识能被用户作适应性修改所需的工具和条件；防止侵权的行为；使用效率和用户满意度。 ★ 用户文档 用户文档应考虑如下要求： ● 完整性：产品描述和程序中的用户可用的功能都应被描述； ● 正确性：所有信息应是正确的,不能有歧义和错误的表达； ● 一致性：用户文档自身或相互间不应相互矛盾,术语一致； ● 易理解性； ● 易浏览性； ● 每个文档应有目录表,索引表,应提供打印方法。 软件测试质量评估的文档的检查测试 软件测试质量评估的文档应考虑如下要求： ★ 测试细则； ★ 细则概述； ★ 测试预要求； ★ 测试活动； ★ 测试记录； ★ 测试报告； ★ 跟踪测试。 软件测试质量评估的软件培训 ★测试者应有机会使用培训材料和培训大纲； ★用户文档； ★用户培训。 16.4.3 软件测试的缺陷评估 　缺陷评估是对测试过程中缺陷达到的比率或发现的比率，提供一个软件可靠性指标。 缺陷分析 　　对于缺陷分析，常用的主要缺陷参数有四个： ★ 状态：缺陷的当前状态； ★ 优先级：必须处理和解决缺陷的相对重要性； ★ 严重性：最终用户、组织或第三方的影响等； ★ 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。 　软件测试的缺陷评估可依据用以下4类形式的度量提供缺陷评测： ★ 缺陷发现率； ★ 缺陷潜伏期； ★ 缺陷分布（密度）； ★ 整体软件缺陷清除率 。 图16-2 缺陷发现率中： ★缺陷发现率将随着测试时间和修复进度而减少； ★缺陷发现率将随着测试时间而测试成本增加； ★可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。 图16-2描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。 缺陷潜伏期 Rational Unified Proces提供缺陷潜伏期（也称为阶段潜伏期，缺陷龄）评估，缺陷潜伏期报告是一种特殊类型的缺陷分布报告。缺陷潜伏期报告显示缺陷处于特定状态下的时间长短。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。表16-8显示了一个项目的缺陷潜伏期的度量。 表16-8中：总体设计发现缺陷，阶段潜伏期为1，在发布产品时阶段潜伏期为9。 4．缺陷分布 缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。 软件缺陷分布（密度）是一种以平均值估算法来计算出软件缺陷分布（密度）值。程序代码通常是以千行为单位的，软件缺陷分布（密度）是用下面公式计算的： 5． 整体软件缺陷清除率 整体软件缺陷清除率是用下面4个公式计算的： 为了估算软件缺陷清除率，首先需引入几个变量，F为描述软件规模用的功能点，D1为软件开发过程中发现的所有软件缺陷数，D2为软件分布后发现的软件缺陷数，D 为发现的总软件缺陷数。由此可得到 D=D1+D2 的关系。 对于一个软件项目，则可用如下的几个公式，从不同角度来估算软件的质量： ★质量（每个功能点的缺陷数）=D2/F ★ 软件缺陷注入率=D/F ★ 整体软件缺陷清除率=D1/D 公式中： F：为描述软件规模用的功能点 D1：为软件开发过程中发现的所有软件缺陷数 D2：为软件分布后发现的软件缺陷数 D： 为发现的总软件缺陷数。16．4．4性能测试评估16．4．4性能测试评估 评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。 主要的性能评测包括以下几点： ★ 动态监测 ： 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。 ★ 响应时间/吞吐量 ： 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。 ★ 百分比报告： 数据已收集值的百分位评测/计算。 ★ 比较报告 ： 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。 ★ 追踪和配置文件报告：测试用例和测试对象之间的消息和会话详细信息。 1．动态监测 动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试用例正在执行的进度来监测或评估性能测试执行情况。如图16-3所示。 2．响应时间和吞吐量 响应时间和吞吐量是评测并计算与时间和吞吐量相关的性能行为。这些报告通常用曲线图显示，如图16-4所示。 3．百分比报告 百分比报告通过显示已收集数据类型的各种百分比值，提供了另一种性能统计计算方法，如图16-5所示。 4．比较报告 比较不同性能测试的结果，以评估测试执行过程中所作的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势。 5．追踪和配置文件报告 当性能行为可以接受时，或性能监测表明存在可能的瓶颈时（如当测试用例保持给定状态的时间过长），追踪报告可能是最有价值的报告。追踪和配置文件报告显示低级信息。该信息包括主角与测试对象之间的消息、执行流、数据访问以及函数和系统调用。 第 16 讲 完 谢 谢！