缺陷报告模板
缺陷报告模板每个公司都不尽相同，例如有Word格式（方便直接粘贴多张截图）、Excel格式、公司内部系统（自主研发）、Bug管理工具等等。一般情况下根据公司的要求编写即可。但新人一般对一些工具中的字段无法全部了解，很多时候会出现漏填重要数据。所以进入团队后首先掌握Bug模板。
Bug标题格式
标题需要客观准确的描述，之前有专家提出的一个好的模式是：条件-失败。语句精炼但描述完整。看案例：
当点击引导页中的继续浏览时，应用闪退。
【商品详情页】当购物车中的商品数量超过100000时，加入购物车失败。（错误代码：3206）
每条缺陷报告只描述一个问题
即使是同一个页面、同一功能出现的问题也需要单独分开汇报 ，这样做的目的是可以正确统计Bug数量，减少或避免开发人员遗漏，对于优先级别不同的Bug汇报在一起影响修复效率。
操作步骤详细但不冗余
有个好的方法是参考出现Bug的Case，如果步骤均相同，可以直接复制粘贴 ，且测试数据也要记录上。 如果步骤不同，也需要自己编写详细步骤。目的是Bug修复人员与原开发人员不一定是同一人，可能他并不十分了解该模块的业务逻辑；二是为了产品人员统计剩余Bug修复优先级，准确详细的步骤让其一目了然 。
利用好关键字
使用过缺陷管理工具的测试人员都了解，经常做的一件事就是检索Bug，特别针对Bug数量较庞大时，有时需要查询类似的Bug，或是统计时想针对某一同类问题（如系统SQL错误、错误代码等）总结，可以通过搜索来归类出。这就需要在编写Bug时斟酌好团队人员一般都会用怎样的关键字搜索。统一规范后使日后检索更轻松点。
Bug相关附件及时上传
说到了上边提到的问题-开发人员无法复现。测试人员发现Bug后，要及时截图或查询到服务器上的错误日志，一定要上传到附件。这样一来有利于开发人员复现，二来也可以提高其修复效率 。
链接相关的Bug
这一步也比较重要。对于开发人员，链接相关Bug可以快速找出其问题原因。对于测试人员，当不同成员测试同一模块时，通过检索可以确认是否已经汇报过，总结时也可以快速归类 。
Bug复现环境配置说明
也是上边提过的，开发人员在自己机器上无法复现，测试人员第一反应是查看他的机器环境，这种情况经常发生。由于开发人员使用同一台电脑开发和测试，使得某些具有环境依赖性的功能无法尽快找出，所以编写Bug报告时务必写清楚Bug出现的环境配置。
增强缺陷报告的可读性
首先缺陷报告是为了让开发看到并且修复Bug的，所以首要满足的就是针对开发的可读性。描述要尽可能的客观、准确。不要有错别字或语句不通，操作步骤要以数字编号的方式整齐排列 。上传的附件名称要与描述中的一致 。（截图需要标注出错误的地方且截图要完整，如地址栏等信息）另外，如果是汇报英文Bug，要注意语法语义的准确性，描述要专业。
