基于测试流程上的缺陷管理系统.ppt

三、基于测试流程上的缺陷管理系统,缺陷的定义 软件没有达到产品说明书表明的功能 软件出现了产品说明书中不一致的表现 软件功能超出产品说明书的范围 软件没有达到用户期望的目标(虽然产品说明书中没有要求) 测试员或用户认为软件的易用性差 不是所有缺陷都会修改 市场的压力使得产品最终发行有时间限制 测试员错误理解或者不正确操作引出的缺陷(FAQ) 错误的修改影响的模块较多，带来的风险较大（遗留） 修改性价比太低(FAQ，遗留） 缺陷报告中提出的问题很难重现,Founder R&D,3.1 缺陷报告管理系统,是测试流程在工具上的固化 通过权限控制来实现流程监控 记录了缺陷识别到关闭过程中的所有数 记录了版本变更的信息 是开发和测试之间沟通的信息平台 实时的数据和信息的更新 度量和统计分析，为改进产品提供依据,Founder R&D,Founder R&D,采用Lotus Notes作为bug管理平台 完全电子化的信息传递 统一管理和备份,具备数据统计和查询功能 能够进行个性化二次开发,方正测试缺陷跟踪与管理系统,3.1.1 系统测试缺陷处理流程,Founder R&D,Bug报告准则 如何重现错误-使用最少步骤重现 现象描述没有歧义 尽量简单-一个bug一个报告 可以提出对错误的解决建议 开发人员拒绝修改的bug 程序员无法重现或者现象难以捕捉 没有明确的报告以说明重现bug的步骤 程序员无法读懂的bug报告 用户很少使用或者不符合用户使用习惯的操作出错 由不受信任的测试人员提出,缺陷报告,Founder R&D,3.1.2 集成测试缺陷处理流程,Founder R&D,4.1 缺陷分析的关注点：,1、对软件问题的功能域分布进行分析，找出系统的薄弱环节 要详细采集每个功能模块或系统构件的bug数据，并按功能、错误类型、严重程度等分类 比较实际发现的软件bug是否与预期的问题分布相吻合 二八定理：80%的软件问题总是发生在大约20%的功能模块（系统构件）中。,Founder R&D,缺陷分析的关注点,2、对bug的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集bug的数据 要求软件各开发阶段的缺陷密度小于本单位过去的平均值 而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如75%）。（同行评审）,Founder R&D,Founder R&D,缺陷分析的关注点,3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。 可参考PSP中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。,缺陷分析的关注点,4、应动态采集每个测试周期中发现的bug数，并有效地控制缺陷的修复率。 5、应密切观察bug的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况,Founder R&D,缺陷分析的关注点,6、应该采集bug不同方式的修复数据，以便检验软件产品是否满足交付规则 分析修改代码、改变设计、封掉功能遗留以及下一版本解决的bug数约占缺陷总数的比例。 在有严密和有效的质量保证体系条件的监控下，常常会引起有较高比例的延期解决的缺陷数，这是因为许多细微的或枝节性的问题被测试出来，经过评价证明不会造成大的质量影响，但可为产品进一步升级提供有价值的参考。,Founder R&D,4.2 测试人员的绩效评价,评价标准： 1、bug数量： 同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。 2、bug严重程度： Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 3、bug价值： Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判 以上三个因素的加权平均才能更有效的评价测试人员的绩效！,Founder R&D,4.3 缺陷统计分析工具介绍,Founder R&D,测试结果分析和评价,缺陷密度: 基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defectsKLOC。可按照以下步骤来计算一个程序的缺陷密度： 累计开发过程中每个阶段发现的缺陷总数(D)。 统计程序中新开发的和修改的代码行数(N)。 计算每千行的缺陷数Dd=1000*D/N。 例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是： Dd1000*145/296000=0.49 defectsKLOC。 在计算缺陷密度时，最重要的是要使用正确的规模测量。,Founder R&D,测试结果的分析和评价,输出测试综合报告： 测试过程的总结 测试数据分析（按照严重程度等方式分类统计的分析，包括测试密度等） 产品主要问题和总体评价 遗留的问题总结 最终的测试结论,Founder R&D,测试结果分析和评价,为了了解和控制缺陷带来的费用，很有必要测量缺陷排除的效果测量： 一种测量方法是计算每小时排除缺陷的个数； 一种是计算缺陷排除效益，即测量通过某一排除方法所发现的缺陷的百分比。,缺陷排除效益是45%,100个缺陷,开始测试,测试,发现45个缺陷,missing 55 defects,Founder R&D,测试结果分析和评价,测试覆盖率测量 语句覆盖率 测试经历语句数/总语句数 分支覆盖率 测试经历支路数/总支路数 简单路径覆盖率 测试经历简单路径数/总简单路径数 功能覆盖率 界面数 菜单数 输入/输出的数据元数 构件、模块 ,Founder R&D,4.5软件测试经验分享,所有的测试都应追溯到需求。因最严重的错误是导致程序无发满足需求的错误； 软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）; 软件开发人员应避免检查自已的程序，利用同行评审的方式对代码进行审查；(自己检查容易依照原有的程序设计思路进行，往往查不出问题) 在设计测试用例时，必须明确预期的输出结果，否则对实际的输出结果很难有检验的标准，测试失去意义。测试用例应由输入数据和与之对应的期望输出结果这两部分组成，在输入数据中，应当包括合理的输入条件和不合理的输入条件； 在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。,Founder R&D,软件测试经验分享,统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势。 测试后程序中残存的错误数目与该程序中已发现的错误数目（即检错率）很可能成正比；(编码规范、需求理解、技术能力、内部耦合性是引起这些现象的原因) 程序中的大部分错误往往是在一小部分模块中发现的，遵循普遍适用的“二八定理”（即80%的错误往往是由20%的模块所造成的），例如，IBM公司的OS/370操作系统中，47% 的错误仅与该系统中的4%的程序模块有关； 要严格执行测试计划，排除测试的随意性，这样才能消除各种无序操作所造成的副作用；测试设计决定了测试的有效性和效率，测试工具只能提高测试效率 应当对每一个测试结果做全面的检查，这样才有可能找到真正的出错原因，为今后的调试工作奠定基础。,Founder R&D,结束语,产品越复杂，测试花费的时间就越长，费用就越大，测试发现缺陷的效率也就越低。 缺陷会掩盖或加重其它缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其它缺陷，使得这些被掩