1.标题：提交缺陷时，尽量保证Bug标题能够简明扼要地阐述问题本质，使查看人员能快速了解Bug内容。
2.发现Bug之后，可以先去抓包、监控日志、检查数据库，尝试分析定位Bug的产生原因（当然也要合理安排测试进度，避免死磕一个问题）。如果能够定位到前后端问题归属或产生原因，截图相关证据作为附件，截图时圈定或标注关键信息。若是程序异常报错、系统崩溃类问题，尽量提供系统日志（txt文本或截图）。若是某些特殊场景下的数据，尽量提供测试数据、测试数据的链接地址、数据库截图等。目标是便于研发快速地复现问题、排查原因。
3.描述信息：用简洁的语言，清晰地描述BUG所发产生的测试环境、操作步骤、页面、按钮、实际结果、预期结果、建议等（已公认/显而易见的信息可以省略），目标是让产品或研发看得懂，快速GET到关键点。
4.操作步骤：简明清晰分步骤地描述如何复现Bug，步骤用序号编排。如在特定情况下发生的问题，或已得到证实的关键复现条件或步骤，需明确说明。
5.尽量避免将多个BUG提到同一个CASE内，以便后续进行处理跟踪和缺陷分类。
6.在精简空话的同时，应仔细检查报告是否存在会产生误解的描述。尽量避免使用模糊的（例如，好像，似乎）、二义的、主观的词语或网络语言来描述BUG，尽量使用能够清晰表述事实的、不会产生争执的词语。
7.不要使用带有强烈感情色彩的词语或符号，如“要求”、“必须”、“低级错误”等，可以使用一些诸如“建议…”、“希望…”、“请…”等比较委婉的词语。
8.不能确认一个现象是不是bug时，可以先向其他人或开发人员进行确认，然后再去提交；尽量避免提交设计如此、操作错误、重复的、已知的Bug。
9.UI类Bug，一定要上传截图，并且增加相应的红框标识。
10.提交BUG时，尽可能地将能够明确的字段属性均选择上，而不是使用默认值或空值，诸如：所属模块、缺陷等级（优先级）、缺陷状态、解决方案、缺陷类型、缺陷归属等；后续在关闭时再做一次补充或调整，以便于质量度量统计。
11.当发现一个BUG时，请发散思考：同一软件中的相似功能或其他的区域，是否有相同/类似的问题？