《测试管理》PPT课件.ppt

1、第16章 测试管理,罗 东 俊 ZSUJONE126.COM,1,主要内容,16.1测试管理基础 16.2测试执行周期的开始和结束 16.3隔离测试环境和开发环境 16.4测试用例的有效管理 16.5缺陷追踪管理 16.6测试的评测,2,16.1测试管理基础,16.1.1 软件测试管理的内容 16.1.2 软件测试管理工具,3,16.1.1 软件测试管理的内容,软件测试管理的目的是确保软件测试技术在项目的生命周期内得到顺利实施，并产生预期的效果。 按照管理的对象不同，软件测试管理大致可分为： 软件测试团队组织管理 软件测试计划管理 软件缺陷(错误)跟踪管理 软件测试件管理,4,软件测试团队组织

2、管理,就是指测试团队应该如何组建。 通常，一个好的测试团队首先要有好的带头人，这个带头人必须具有极为丰富的开发经验，对开发过程中常见的缺陷或错误了然于胸，此外，他还应具有亲和力和人格魅力。 其次，测试团队还应有具备一技之长的成员，例如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本。 另外，测试团队还应有兼职成员，例如验收测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。 测试团队里往往包括几个开发经验欠缺的新成员，这部分人员可以安排去从事交付验收或黑盒测试之类的工作。,5,软件测试计划管理,就是指安排好测试流程 。 这部分内容具体涵盖软件测试

3、策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。 测试策划工作主要是指具体测试活动实施之前做好策划工作，如起草测试大纲以及测试计划； 软件测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际，剪裁出所要实施的测试技术； 测试进度管理工作主要是排出各项测试的时间进度及人员安排，如有变动时应如何做相应调整； 测试成本管理工作主要指管理测试活动中会涉及到的资源需求。,6,软件缺陷(错误)跟踪管理,就是确保发现的缺陷(错误)已经被开发团队纠正或处理过并且没有引入新的缺陷(错误)。 具体来讲，当测试团队通过各种途径发现了文档或代码中的缺陷或错误以后，并不是交一份测试报告就草草了事，而是在递

4、交报告以后继续督促开发团队及时关闭已知缺陷或错误。当然，如有必要应对这些缺陷、错误做严重程度排序，以便开发团队能视轻重缓急安排处理顺序。当开发团队关闭了测试报告中的缺陷(错误)以后，测试团队还需验证开发团队在关闭过程中有没有引入新的错误。通常，这个过程称为回归测试。回归测试如发现问题，继续报告开发团队，按上述流程循环，直至回归测试最终通过。,7,软件测试件管理,是指努力建设好测试团队的软件测试件库并对测试团队成员进行技能培训以帮助他们能使用好这个软件测试件库。 测试件(Testware)是指测试工作形成的产品，包括测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及

5、一些经过少量修改就能推广至通用的测试脚本程序。,8,16.1.2 软件测试管理工具,采用高水平的软件测试管理工具则能保证以一个较小规模的测试队伍完成复杂的大量的测试工作，以此来做到对成本和时间效率的有效管理。 除此之外，通过该软件，用户也可以及时地掌握软件的测试和完成情况，并对整个过程进行监督和管理，这对用户控制成本和做相应的安排也是有好处的。 目前，市场上主流的企业级测试管理工具主要有Mercury TestDirector和IBM RationalTest Manager,9,TestDirector的主要功能,用户权限管理 TestDirector设置有六个用户组，分别为TDAdmin、

6、QATester、ProjectManager、Developer、Viewer、Customer 集中式项目信息管理 后台采用集中式的数据库(Oracle、SQLServer、Access等) 分布式访问 定义测试工作流程 需求管理、规划测试、安排测试进度并运行测试、缺陷管理、图示和报告,10,开源软件测试管理工具,第一个工具为TestLink(http：/ 第二个工具为Bugzilla Test Runner(http：/,11,16.2测试执行周期的开始和结束,测试人员应该为测试执行周期的开始和结束定义入口标准和出口标准。 入口标准描述了测试小组何时可以开始测试一个特定的版本； 出口标准

7、描述了软件完成充分测试的时间。 由于测试资源是有限的，测试预算和测试人员的数目有限，测试时间有限，软件发布时间紧张，因此测试工作的范围一定要有限制。,12,系统测试执行入口标准,所有的单元测试和集成测试已经成功完成。 软件的生成(编译)过程没有任何错误。 软件版本通过了烟雾测试(最基本的测试，关键功能的测试)。 配套文档已经完成，文档的内容涉及软件版本的新功能和修改的内容。 缺陷已经修正并且准备重新测试。 源代码已经存储在版本控制系统中,13,测试出口标准,已经执行了用来确定系统满足指定的功能性和非功能性需求的测试过程。 在测试结果中记录的所有1级、2级和3级的软件问题都已经解决。 在测试结果

8、中记录的所有1级、2级的软件问题都已经解决。 在测试结果中记录的所有1级、2级的软件问题都已经解决，同时90的3级问题已经解决。 软件发布时可能存在已知的低优先级的缺陷(当然有若干未知缺陷)。 一些度量也可以作为出口标准的一部分 缺陷修改的质量 、缺陷趋势分析,14,16.3隔离测试环境和开发环境,当测试组执行测试、实施测试策略时，测试环境必须和开发环境分离开。 如果没有独立的测试环境，那么测试工作就会遇到下面的一些问题： 环境的变化 版本管理 操作环境的变化,15,16.4测试用例的有效管理,16,测试用例分析例子,17,16.5缺陷追踪管理,16.5.1软件缺陷的生命周期和处理流程 16.

9、5.2软件缺陷的严重性和优先级 16.5.3软件缺陷的报告、分离和再现 16.5.4软件缺陷的度量 16.5.5缺陷管理系统,18,16.5.1软件缺陷的生命周期和处理流程,简单的软件缺陷生命周期,19,复杂的软件缺陷生命周期例子,20,通用的软件缺陷生命周期,21,缺陷状态,22,软件缺陷分类,23,普通的缺陷处理流程,缺陷报告最初生成的状态为“新”； 赋予各个小组打开不同问题的能力（错误请求、变更请求、增强请求） 选择缺陷优先级 评估缺陷，为缺陷分配状态 若状态为“打开”，则把缺陷分配给负责的人，变为“开发”状态 开始改正缺陷了，变为“正在开发”状态 缺陷改正完了，改为“修改完毕”状态；或

10、者“工作正常”、“缺陷不能重现” 若创建了新版本，所有改正的缺陷改为“返测”状态 测试工程师返测这些改动，设置状态为“关闭-改正”、“返测失败”,24,普通的缺陷处理流程,25,16.5.2软件缺陷的严重性和优先级,严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。 优先级(Priority)是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。 处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节,26,严重性 vs. 优先级,一般来说，严重性程度高的软件缺陷具有较高的优先级

11、。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。 但是，严重性和优先级并不总是一一对应。因为修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。,27,例如,如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。 另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。 另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快

12、修正，因为这关系到软件和公司的市场形象。,28,严重性的常用划分方法,29,优先级的常用划分方法,30,例如,极少发生的数据毁坏缺陷应该划分为严重性1，优先级3； 导致用户电话求助的安装指示错别字应该划分为严重性3，优先级2； 只要一启动就崩溃的测试软件版本属于严重性1，优先级1； 如果认为某按钮向页面下方再移动一点，则属于严重性4，优先级4。 软件缺陷的优先级在项目期间也可能会发生变化。 原本标记为优先级2的软件缺陷随着时间即将用尽，以及软件发布日期临近，可能变为优先级4。,31,16.5.3软件缺陷的报告、分离和再现,报告软件缺陷要以明显、通用和再现的形式进行描述。 有效的软件缺陷描述要求

13、 ： 简单与短小：只解释事实和演示、描述软件缺陷必需的细节。 单一：每一个报告只针对一个软件缺陷 明显和通用：用使用者容易看懂的、展示通用性的简单易行步骤描述的软件缺陷 再现：软件缺陷报告必须报告记录按照预定步骤可以使软件达到缺陷再次出现的相同状况 使用IT业界惯用的表达术语和表达方法 补充完善软件缺陷报告,32,缺陷报告基本组成,优秀的错误描述主要由三个基本部分组成：摘要、重建步骤和隔离。 “摘要”又叫主题或标题，是关于错误的一两句话的描述，强调它对顾客或系统用户的影响。 “重建步骤”提供了如何重复这个失败的精确描述。 “隔离”是指测试人员收集的结果和信息，以确认错误确实是一个问题，并标识那

14、些影响到错误表现的要素。,33,一份优秀的缺陷报告,34,16.5.4软件缺陷的度量,对缺陷数据进行分析和度量，使我们在改正缺陷的同时，将缺陷管理过程推向更高的阶段量化管理阶段 软件开发只有引入了度量机制和定量化的管理，才能称为真正意义上的“工程”，这一准则清楚地体现在CMM中： CMM 4级（已管理级）引入了“定量软件过程” CMM 5级（优化级）则完全建立在定量管理的基础之上，并明确提出了“缺陷预防”。,35,软件缺陷度量的过程,软件缺陷度量的过程可以分为四大部分： 计划度量 执行度量 分析度量结果 评价度量,36,计划度量,严格地指定要度量什么，如何对数据进行合并产生满足信息需要的结果。

15、 如： 在回归测试中，从以前运转正常的功能中发现缺陷的比例（修正工作破坏以前运转正常功能的频率） 缺陷修正失败的频率 新缺陷的发现率走势,37,获取度量数据,缺陷文档中可能包括的属性有：缺陷ID、缺陷状态、测试人员ID、提交时间、缺陷所属项目ID、缺陷所属模块ID、开发人员ID、缺陷类型、严重级别、优先级、修改人ID、解决方案、修改时间、修改次数、确认结果等。,38,几个核心度量,缺陷持续时间 缺陷纠正到返测的时间 缺陷趋势分析 缺陷修改的质量 缺陷密度 测试人员工作效率,39,缺陷持续时间,缺陷持续时间是指从发现缺陷到改正缺陷的时间跨度，同时必须考虑缺陷修正工作的复杂度。 该度量用于验证缺陷

16、是否被及时地解决，利用缺陷持续时间的数据，测试组可以分析开发组对改错工作的反应是否影响了测试工作的进度 一个缺陷的持续时间越长，纠正缺陷的难度可能就越大，因为可能在错误代码的基础上又加入了新的代码,40,缺陷纠正到返测的时间,缺陷纠正到返测时间是指缺陷被修正并且在新版本中发布的时间到缺陷被返测的时间跨度。 该度量提供了一种衡量测试组的返测缺陷速度的方法。,41,缺陷趋势分析,缺陷趋势分析是指在测试生命周期内，随着测试工作的进行，发现缺陷的数量的变化趋势。 缺陷趋势分析有助于确定所发现的缺陷的变化趋势，对于软件产品发布而言，缺陷趋势分析图是辅助决策的重要依据。,42,缺陷发生率,43,缺陷趋势图

17、,44,缺陷修改的质量,缺陷修改的质量是指修改后剩余的缺陷数量，即重现率。 该度量测量的是缺陷修正工作给以前工作正常的功能带来的新缺陷，或者破坏以前工作正常的功能的百分比。 例如，修复了100个缺陷，后来发现其中20个修复引入了新的缺陷，则缺陷纠正率为D=(100 - 20)/100100=80。,45,缺陷密度,缺陷密度(Defect Density)是指一段时间里发现的缺陷数与软件大小的比例。 软件的大小可以采用功能点度量，也可以用源代码行数衡量。用数学公式表示为：DD=defects/KLOC或DD=defects/KFP KLOC表示每千行源代码，KFP表示每千个功能点。 产品的缺陷密

18、度直接影响着客户的满意程度。,46,各模块中每千行代码的缺陷密度,47,缺陷密度度量的缺点,缺陷密度这种度量方法是极不完善的，度量本身是不充分的。 这里边存在的主要问题是：所有的缺陷并不都是均等构造的。 各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程度有很大差别， 因此，有必要对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，,48,缺陷在各优先级上的分布,49,缺陷严重程度分布,50,缺陷产生原因分布图,它是缺陷分析中最为重要的一张图表，因为它可以直接反映出各软件工程活动的质量，为软件过程的改进提供直接的参考数据。 一般来说

19、，缺陷产生的根本原因划分的越细致，分析的结果就越精确。 例如，当发现需求中出现的缺陷比较多的时候，在未来的项目中我们可以通过需求评审、需求变更控制来减少该种缺陷的数量，以达到软件质量保证的目的。 同样如果我们发现软件设计过程中产生的问题比较多，那么就可以通过加强软件设计阶段中的审查活动来保证设计的质量。,51,几个综合指标,测试人员工作效率 缺陷探测效率 发布前的缺陷消除率,52,测试人员工作效率,测试人员工作效率：是指测试人员在一定时期内测试出不同类型缺陷的能力，它等于测试人员测试出的不同缺陷类型数量与对应权值的乘积之和，再除以本次测试的周期，从而衡量测试人员的熟练程度。,53,缺陷探测效率

20、,缺陷探测效率(Defect Detection Efficien，DDE)：是指软件生命周期的各个阶段由测试人员发现缺陷的效率。它可以这样计算：在各个生命周期阶段发现某个阶段产生的缺陷数与在该阶段中产生的缺陷总个数的比例。 如果DDE为100，则表明该阶段发现了所有在这个阶段中产生的缺陷，没有缺陷传播到下一个阶段。 如果DDE为30，则表明该阶段发现了30在这个阶段中产生的缺陷，将有70在这个阶段中产生的缺陷传播到下一个阶段。 DDE说明了过程的效率。,54,发布前的缺陷消除率,发布前的缺陷消除率(Pre Delivery Defect Removal Efficiency)：是指软件发布前

21、的各个阶段发现的缺陷总数占软件缺陷总数的比例。 如，发布前发现了300个缺陷，发布后使用半年又发现了100个缺陷，则发布前的缺陷消除率PDRE=300/(300+100)100=75。,55,16.5.5缺陷管理系统,国内外已出现了一批质量较好的缺陷管理工具，其中比较有代表性的有： 开源软件Bugzilla、jira Compuware公司的TrackRecord 、 Rational公司的ClearQuest、 北京航空航天大学的QAMonitor、 上海微创软件有限公司的BMS等。 这些工具各有特色，在功能的全面性上也各不相同，但都是基于“找出缺陷、修改缺陷、进行回归测试”这种面向流程处理的传统模式，实现了缺陷管理的基本流程，并在此基础上提供了一些查询和统计功能； 其共同的缺点是没有充分利用软件开发过程中产生的缺陷数据，不能以一种主动的、精确量化的方式对软件缺陷进行预防并提供软件项目管理者所需的有关产品和过程的度量信息。,56,16.6测试的评测,16.6.1覆盖评测 16.6.2质量评测,5