缺陷处理流程

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