软件缺陷管理跟踪

缺陷跟踪管理内容软件缺陷与Bug软件缺陷（Bug）的分类Bug产生的原因Bug的属性Bug的状态Bug的生命周期Bug管理的简单流程如何写好Bug报告Bug报告示例Bug跟踪的目的常见的软件Bug软件缺陷与Bug软件缺陷软件系统中的需求、体系结构、设计和应用上的错误。Bug软件做了没有期望它去做的事（或者相反，软件没有做到所期望它去做的事）。Bug是软件缺陷的实际证明。软件缺陷有可能成为bug，但并非所有的软件缺陷都产生bug。软件缺陷（bug）的分类GUI缺陷功能缺陷本地化缺陷可用性缺陷稳定性缺陷Bug产生的原因需求阶段•未能真正了解客户方需求，功能描述不正确•需求定义有二义性•需求中遗漏客户方功能需求概要设计阶段•架构设计不正确•业务流程设计错误详细设计阶段•功能模块间数据格式定义不一致•不符合开发规范编码阶段•代码缺陷Bug的属性标题(Title)严重等级（Severity）优先级（Priority）状态（Status）描述(Description)步骤（Steps）备注（Comments）Bug的严重性严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响。按严重性分为5级：•紧急Urgent(系统崩溃或挂起)•致命VeryHigh(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)•严重High(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)•一般Medium(用户使用不方便)•轻微Low(界面拼写错误)Bug严重级别－紧急导致操作系统死机、非法退出、崩溃（如WinNT/2000的蓝屏、Win98的系统致命错误等）死循环、数据库发生死锁功能错误数据库连接错误、数据通讯错误导致操作系统不响应程序退出没有释放资源导致其它应用程序出现异常（如无法启动、不响应、异常退出）卸载时不提示客户确认就删除了公用程序（DLL等）其它导致操作系统或其它应用程序异常的情况重大安全隐患情况（如机密性数据的泄密）Bug严重级别－很高程序错误、错误操作程序中断程序挂起程序异常退出系统无法正常安装、卸载或升级程序接口错误数据库表、业务规则、缺省值未加完整性等约束条件存在一般安全漏洞其它导致被测系统本身出现无法正常运行的错误Bug严重级别－高导致输出数据错误（数据出错、格式错误、无法打开等）操作界面错误（窗口内列名定义、含义不一致）打印内容、格式错误简单的输入控制未放到前台进行删除操作未给提示数据库表中有过多的空字段功能不完整；导致数据最终操作结果错误；文件或数据传输不完整或不正确；对数据格式不进行检测；提示语句易误导用户，造成数据丢失等重大问题；其它导致被测应用系统其它模块无法正常运行或出现错误结果的情况Bug严重级别－中等影响当前操作结果数据修改后没有保存提示系统出错提示不正确或没有捕获系统出错信息数据的重要操作（如删除、添加等）没有提示界面不规范、输入输出不规范长操作未给用户提示提示窗口文字采用行业术语可输入和可读区域没有明显区分标志辅助说明描述不清楚其它影响被测模块/功能正常执行的情况Bug严重级别－低页面布局不合理字体不一错别字语言不一致（如：中英文混合）页面提示不明确系统不友好（易用性）其它对被测模块功能实现没有影响的情况客户其他要求Bug的优先级优先级表示缺陷修复的先后顺序。按优先级分为五种：•紧急(Urgent)•很高(Veryhigh)•高(High)•中(Midium)•低(Low)Bug的状态状态权限含义new测试员一个新Bugopen项目经理确认为Bugfixed开发人员已解决的Bugclosed测试员验证Bug的确解决reopen测试员‘解决的Bug’没有真正解决rejected开发人员‘报告的Bug’不是BugBug的生命周期Bug管理的简单流程Bug管理的流程说明1、测试人员提交新的Bug。2、项目经理、开发经理或者测试经理，再或者测试人员自己分配给相应的开发人员，设置状态为Open。3、开发人员查询状态为Open和Reopen的Bug，不是Bug，则置状态为Reject，是Bug则解决并置状态为Fixed，不能解决的Bug，要留下文字说明及设置Bug状态。4、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。Bug管理的流程说明5、对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。6、一般输入到库中的Bug，原则性不能删除，及开发人员和测试人员没有删除的权限。一般管理员由此权限。7、对于测试人员和开发人员要加适当的使用权限，测试人员一般只有新增、查询、验证等权限，开发人员一般只有查询、解决等权限。如何写好Bug报告下面的几点有助于写好一份缺陷报告：1、重现发现的缺陷一定要重现，经验表明在写缺陷报告之前将一个错误重现三次；2、隔离重现Bug之后，就要将缺陷隔离，就是指出缺陷涉及的范围，以帮助开发人员进行缺陷的修复；3、归类严重性和优先级两个方面进行归类；GUI、功能、性能归类；bug来源归类；如何写好软件缺陷报告4、总结缺陷报告一开始，要对所有的缺陷做一个简要的说明，好的说明一方面吸引看报告的人，另一方面是一种很好的沟通方式；5、中立站在比较客观的角度来分析缺陷，对事不对人，提高软件的质量是一致目标；6、评审将缺陷报告交给其他测试人员进行小范围的评审，让他们给出一些好的建议，这样有助于报告质量的提高；Bug管理的目的确保需求—设计—执行—BUG的可追溯性。确保每个被发现的缺陷都能够被处理。为软件缺陷分析提供详尽的统计信息。为下一个项目提供足够的数据参考。常见的Bug常见缺陷1、形象类问题2、可用性问题3、稳定性问题4、其他问题形象类问题这类问题一般是表面上的，技术含量不高，但是给予用户的感觉往往是软件不够专业……1、不符合用户操作习惯。如，快捷键定义不科学；2、风格的统一性；3、界面中英文混杂，经常弹出莫名其妙的信息，甚至还拼错单词；4、提示、标题等不够专业，或各处描述不一致；5、界面元素的位置：非缺省分辨率和浏览器版本，导致在其他分辨率和浏览器版本下显示不正常；6、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分…形象类问题7、程序名/路径名不规则（比如为程序员的名字等）；8、没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件)；9、界面元素参差不齐，文字不能完全显示…10、功能重复11、没有反显功能12、窗体名称、图标、关闭按钮13、数据、字符、图形、表格显示不对齐不完整14、最大化最小化比例失调可用性问题错误和低效的用户界面使用户在接触界面上要花费更多时间，最终甚至会掩盖了产品有用的方面。下面是一些用户界面错误的例子：1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果；（输入类型、长度、边界值、多次重复）2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导（如：记录个数、参数设置对话框中的缺省值等）；3、同一信息在不同界面显示不一致可用性问题下面是一些低效的用户界面的例子：1、没有错误提示或信息提示表达不清、过于模糊；2、要求用户输入多余的、本来系统可以自己得到的数据（如：安装后用户要手动修改某些配置文件）；3、为了达到某个设置或对话框，用户必须做许多冗余操作（如对话框嵌套层次太多）；4、不能记忆用户的设置或操作习惯（如用户每次进入都需要重新操作一次初始环境）；5、主窗口调节后内容过多没有滚动条；内嵌窗口大小可以任意调节；6、处理不符合逻辑和习惯；7、抵赖性强，恢复性弱稳定性问题往往是在设计时考虑不周而造成的一些问题。1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低；2、主系统和子系统使用同样的临界资源而互相不知道（如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号）；3、不能重现的错误（如不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)导致错误等）；4、在同一台机器上能打开多个相同的应用程序又不支持多应用操作；5、长时间运行不稳定（花屏），屏幕自动刷新；6、逆向流程输入报错7、关闭母窗口字窗口报错其他问题1、文档匮乏：文档不标准；无新功能使用方法；无版本改动说明。2、运行时不检查内存、数据库或硬盘空间等；3、假设用户环境（硬件/网络环境、软件环境等、配置等）；4、安装困难，或根本无法安装等；5、提供的应用程序带有病毒；6、程序不经调试，或提供Debug版本给测试组或测试用户；7、用户现场开发和修改，没有修改记录和保存版本；8、密码支持粘贴拷贝9、用户改变，应用环境变量没有改变其他问题10、错误反复出现，改动得不彻底、或版本管理出现混乱；11、改动时不小心，导致错误越改越多；12、版本中部分内容和接口倒退；13、状态没有正确变更（有些选项永远是灰的，有些选项、菜单项在该灰时还不灰）；14、资源没有和代码分离，不同语言版本间不能平滑转换；15、模块（子系统）间接口不一致；…………谢谢！