软件开发文档：BUG报告？提示与技巧.docx

怎样才能写出好的BUG报告？提示与技巧

　　为什么要写好的缺陷报告呢？
　　如果你的缺陷报告是高效的，那么被修复的几率就高很多。所以说是否修复你提交的BUG，取决于你报告的质量。怎样写出好的报告，毫无疑问是需要技巧的。我现在将告诉你怎样学会这项技巧。
　　Cem Kaner说过：“写问题报告（缺陷报告）的目的就是为了让问题得到解决”。如果测试员不能正确的描述缺陷的话，开发人员很有可能会以问题无法重现为由而拒绝修复，这样的话，很容易打击测试员的士气，有时候甚至伤到测试员的自尊。（我建议在测试过程中，不要带有任何自我的想法，比如说“我已经很正确的描述这个缺陷了呀”，我可以重现这个问题呀”，“为什么他们拒绝修复这个问题呢？”，“这不是我的问题”等等，等等……）
　　一个好的软件缺陷报告应该具备哪些特点呢？
　　任何人都会写缺陷报告，但不是每个人都可以写出一份高效的缺陷报告。你要学会区分一份缺陷报告是一般的还是高质量的。如何区分报告的好坏呢？很简单，在描述一个缺陷时，运用到以下的特征和技巧就可以了。
　　1）具有明确的缺陷编号
　　每一个缺陷报告都要赋予一个惟一编号，这样可以让你轻松的区分缺陷记录。如果你正在使用自动化的缺陷报告工具，那么在你每次提交缺陷的时候，系统会自动的产生一个惟一编号，记录下每个缺陷的编号和简述。
　　2）具有可重现性
　　如果你提交的问题不能重现的话，那么它们永远也别想得到修复。你要清楚的描述重现过程中的每一个步骤，不要假设或忽略任何一步。一步接一步的描述问题，问题才可能较容易的重现，问题才能被修复。
　　3）要具体明确
　　不要把问题描述的像篇散文一样，一定要明确并且重点突出。尽量用最简短的语句同时又是高效的方式来描述问题。就算有些问题表面上看来是类似的，也不要把它们都合并成一个问题，每个问题都要有自己的报告单。
　　如何描述一个问题呢？
　　参考下面这个简单的缺陷报告模板：
　　这是一个简单的缺陷报告模板，你可以根据你当前使用的缺陷报告工具来加以变化。如果你是手工记录缺陷报告的话，那么有些值就需要特别的指明，比如说这个需要手动分配的缺陷编号。
　　报告人：你的姓名和电邮地址
　　产品：发现问题的产品名称
　　版本：产品的版本（没有的话可以不填）
　　组件：产品的主要组成模块
　　平台：在哪个平台下发现的问题。平台有很多种，比如：PC， MAC， HP， Sun等等
　　操作系统：在什么操作系统下发现的问题。操作系统有Windows，Linux， Unix， SunOS， Mac OS. 如果可以的话，把操作系统的版本也写上，比如说Windows NT， Windows 2000， Windows XP等等。
　　优先级：问题应该在什么时候被修复？通常是将优先级设为从P1到P5，PI表示“该问题的优先级是最高的，必须马上修复”，而P5则表示“时间允许的话就修复，没时间的话就延迟修复或者不修复”。
　　严重性：描述这个问题的影响程度
　　严重性的类型有：
　　● 致命的：无法进行下一步测试工作
　　● 严重的：系统崩溃，数据丢失
　　● 主要的：主要功能无法实现
　　● 次要的：次要功能无法实现
　　● 轻微的：界面需要完善
　　● 系统增强/优化：新特征的需求或者一些已经存在的优化