1、,软件测试培训-缺陷管理,1,缺陷管理,软件测试的根本目的是什么?,在于检验它是否满足规定的需求 或是弄清预期结果与实际结果之间的差别,缺陷管理,软件测试中经常使用各种术语来描述软件出现的问题,如下一些通用的术语: 软件错误(Software Error) 软件缺陷(Software Defect) 软件故障(Software fault) 软件失效(Software failure)区分这些术语很重要，它关系到测试工程师对软件失效现象与机理的深刻理解.由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效的机理可能也有不同的表现形式,但总的来说,软件失效的机理可描述为
2、: 软件错误-软件缺陷-软件故障-软件失效,软件错误:在可以遇见的时期内,软件将有人来开发.在整个生存期的各个阶段,都贯穿 着人的直接或间接的干预.然而人难免犯错误,这必然给软件留下不良的痕迹.软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生.可见,软件错误是一种人为过程,相对于软件本身,是一种外部行为.软件缺陷:软件缺陷是存在于软件(文档,数据,程序)之中的那些不希望或不可接受的偏差.其结果是软件运行于某一特定条件时出现软件故障,这时称软件被激活.软件故障:软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态.比如:软件处于执行一个多余循还过程时,
3、我们可以软件出现故障.若此时没有适当的措施(容错)加以处理,便产生软件失效.软件故障是一种动态行为.软件失效:软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果.,缺陷管理,缺陷管理,综上所述,软件错误是一种人为错误.一个软件错误必定产生一个或多个软件缺陷.当一个软件缺陷被激活时,便产生一个软件故障;同一个软件缺陷在不同条件下被激活,可能产生不同的软件故障.软件故障如果没有及时容错措施加以处理,便不可避免地导致软件失效.,缺陷管理,缺陷管理-目的,缺陷管理目的: 缺陷管理目的是对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。主要实现以下目标： 及时了解并跟踪每个
4、被发现的缺陷； 确保每个被发现的缺陷都能被处理； 收集缺陷数据并根据缺陷趋势曲线识别测试过程阶段； 收集缺陷数据并在其上进行数据分析，作为组织过程的财富。,缺陷管理-人员职责,参与缺陷管理过程人员角色职责: 项目经理（PM） 负责指派缺陷给相关责任人. 项目测试负责人（TM）: 决定缺陷管理方式和工具，拟定决策评审计划； 管理所有缺陷关闭情况； 审核测试人员提交的缺陷； 对测试人员的工作质量进行跟踪与评价。 测试人员（TE） 负责报告系统缺陷记录，且协助项目人员进行缺陷定位； 负责验证缺陷修复情况，且填写缺陷记录中相应信息； 负责执行系统回归测试； 提交缺陷报告； 负责被测软件进行质量数据和分
5、析。 项目相关开发人员（DE） 修改测试发现的缺陷，并提交成果物做再测试； 负责接收各自的缺陷记录，并且修改； 负责提供缺陷记录跟踪中其它相应信息。 质量保证人员（SQA） 监控项目组缺陷管理规程执行情况。,缺陷管理-流程图,缺陷管理-过程介绍,缺陷登记: 缺陷审批: 是否缺陷： 缺陷分派： 修复缺陷： 缺陷回归测试：,缺陷管理-缺陷来源介绍,缺陷来源 描述 缩写 Cause-Requirement 由于需求的问题引起的缺陷 C-R Cause Design 由于设计的问题引起的缺陷 C-D Cause Code 由于编码的问题引起的缺陷 C-C Cause Test 由于测试的问题引起的缺陷
6、（测试用例设计问题等） C-T Cause Integration & Other 由于集成或其它问题引起的缺陷 C-I&O,缺陷管理-缺陷相关属性,缺陷管理-缺陷等级定义,缺陷管理-缺陷修复优先级,缺陷管理-缺陷状态,缺陷管理-缺陷状态转换图,缺陷管理-怎样专业的描述缺陷,软件缺陷的有效描述规则，主要是： 1. 单一准确 每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 2. 可以再现 提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。 3. 完整统一
7、提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。 4. 短小简练 通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。 5. 特定条件 许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。 6. 补充完善 从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，
8、并且得到应有的重视，继续监视其修复的全过程。 7. 不做评价 在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。,缺陷管理-工具介绍,Test Director Hp公司 TM BUGZILLIA JIRA,基于测试流程上的缺陷管理系统 缺陷的定义 软件没有达到产品说明书表明的功能 软件出现了产品说明书中不一致的表现 软件功能超出产品说明书的范围 软件没有达到用户期望的目标(虽然产品说明书中没有要求) 测试员或用户认为软件的易用性差 不是所有缺陷都会修改 市场的压力使得产品最终发行有时间限制 测试员
9、错误理解或者不正确操作引出的缺陷(FAQ) 错误的修改影响的模块较多，带来的风险较大（遗留） 修改性价比太低(FAQ，遗留） 缺陷报告中提出的问题很难重现,3.1 缺陷报告管理系统,是测试流程在工具上的固化 通过权限控制来实现流程监控 记录了缺陷识别到关闭过程中的所有数 记录了版本变更的信息 是开发和测试之间沟通的信息平台 实时的数据和信息的更新 度量和统计分析，为改进产品提供依据,测试缺陷跟踪与管理系统,采用Lotus Notes作为bug管理平台 完全电子化的信息传递 统一管理和备份,3.1.1 系统测试缺陷处理流程,缺陷报告,Bug报告准则 如何重现错误-使用最少步骤重现 现象描述没有歧
10、义 尽量简单-一个bug一个报告 可以提出对错误的解决建议开发人员拒绝修改的bug 程序员无法重现或者现象难以捕捉 没有明确的报告以说明重现bug的步骤 程序员无法读懂的bug报告 用户很少使用或者不符合用户使用习惯的操作出错 由不受信任的测试人员提出,3.1.2 集成测试缺陷处理流程,4.1 缺陷分析的关注点：,1.对软件问题的功能域分布进行分析，找出系统的薄弱环节 要详细采集每个功能模块或系统构件的bug数据，并按功能、错误类型、严重程度等分类 比较实际发现的软件bug是否与预期的问题分布相吻合 二八定理：80%的软件问题总是发生在大约20%的功能模块（系统构件）中。,缺陷分析的关注点,2
11、、对bug的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集bug的数据要求软件各开发阶段的缺陷密度小于本单位过去的平均值 而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如75%）。（同行评审）,缺陷分析的关注点,3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。可参考PSP中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。,缺陷分析的关注点,4、应动态采集每个测试周期中发现的bug数，并有效地控制缺陷的修复率。5、应密切观察bug的状态，并
12、及时跟踪其状态的变化，以检查测试和开发人员的工作情况,缺陷分析的关注点,6、应该采集bug不同方式的修复数据，以便检验软件产品是否满足交付规则 分析修改代码、改变设计、封掉功能遗留以及下一版本解决的bug数约占缺陷总数的比例。 在有严密和有效的质量保证体系条件的监控下，常常会引起有较高比例的延期解决的缺陷数，这是因为许多细微的或枝节性的问题被测试出来，经过评价证明不会造成大的质量影响，但可为产品进一步升级提供有价值的参考。,4.2 测试人员的绩效评价,评价标准： 1、bug数量： 同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。 2、b
13、ug严重程度： Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 3、bug价值： Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判以上三个因素的加权平均才能更有效的评价测试人员的绩效！,4.3 缺陷统计分析工具介绍,测试结果分析和评价,缺陷密度:基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defectsKLOC。可按照以下步骤来计算一个程序的缺陷密度： 累计开发过程中每个阶段发现的缺陷总数(D)。 统计程序中新开发的和修改的代码行数(N)。 计算每千行的缺陷
14、数Dd=1000*D/N。 例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是： Dd1000*145/296000=0.49 defectsKLOC。 在计算缺陷密度时，最重要的是要使用正确的规模测量。,测试结果的分析和评价,输出测试综合报告： 测试过程的总结 测试数据分析（按照严重程度等方式分类统计的分析，包括测试密度等） 产品主要问题和总体评价 遗留的问题总结 最终的测试结论,测试结果分析和评价,为了了解和控制缺陷带来的费用，很有必要测量缺陷排除的效果测量： 一种测量方法是计算每小时排除缺陷的个数； 一种是计算缺陷排除效益，即测量通过某一排除方法所发现的缺陷的百分比。,测试结
15、果分析和评价,测试覆盖率测量 语句覆盖率 测试经历语句数/总语句数 分支覆盖率 测试经历支路数/总支路数 简单路径覆盖率 测试经历简单路径数/总简单路径数 功能覆盖率 界面数 菜单数 输入/输出的数据元数 构件、模块 ,4.5软件测试经验分享,所有的测试都应追溯到需求。因最严重的错误是导致程序无发满足需求的错误；软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）;软件开发人员应避免检查自已的程序，利用同行评审的方式对代码进行审查；(自己检查容易依照原有的程序设计思路进行，往往查不出问题)在设计测试用例时，必须明确预期的输出结果，否则对实际的
16、输出结果很难有检验的标准，测试失去意义。测试用例应由输入数据和与之对应的期望输出结果这两部分组成，在输入数据中，应当包括合理的输入条件和不合理的输入条件；在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。,软件测试经验分享,统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势。测试后程序中残存的错误数目与该程序中已发现的错误数目（即检错率）很可能成正比；(编码规范、需求理解、技术能力、内部耦合性是引起这些现象的原因)程序中的大部分错误往往是在一小部分模块中发
17、现的，遵循普遍适用的“二八定理”（即80%的错误往往是由20%的模块所造成的），例如，IBM公司的OS/370操作系统中，47% 的错误仅与该系统中的4%的程序模块有关；要严格执行测试计划，排除测试的随意性，这样才能消除各种无序操作所造成的副作用；测试设计决定了测试的有效性和效率，测试工具只能提高测试效率应当对每一个测试结果做全面的检查，这样才有可能找到真正的出错原因，为今后的调试工作奠定基础。,结束语,产品越复杂，测试花费的时间就越长，费用就越大，测试发现缺陷的效率也就越低。 缺陷会掩盖或加重其它缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其它缺陷，使得这些被掩盖的缺陷难以发现，增加了它们逃过测试的可能性。 遵照规范化的方法，仔细复查和测试每个小程序模块，这比让任何测试组在你的程序中发现缺陷的效果要好。也就是说，尽早的将缺陷排除掉。测试不能避免缺陷的发生，只能是一种补救。你是唯一能做到生产出无缺陷程序的人，其他任何人都无法帮你做到这一点。,
