测试过程中提交bug单可以说是最经常也较为过瘾的事，就拿它来讲，做好与否的差别很明显：

    最简单的：把看到的问题现象描述清楚就算完事，其他定位事情让开发自己来吧，这样省事又省心；

    负责一点的：把问题出现的条件、机率，便于重现的方法都列举出来，开发可以快速的定位和修复问题；

    更进一步的：结合自己对产品的熟悉情况，对问题可能的来龙去脉做补充说明，并把相关联的问题一一列出，有时还可以就自己对客户需求的理解度以及相关产品实现方式综合给出修复的建议，让项目经理和开发对问题影响度有个更清晰的把握，从而对修复方法有更深入的考虑，而对自己未尝不是一个业务和经验的总结和积累呢。

    上面几点主要是大方向，具体提交bug单的时候，有很多细节，话说有时候是细节决定成败，那么再从bug的一些参数措施上注意，需要有标准分类的地方一定要先给出具体参考标准，以做到一个部门、一个产品使用的标准是一致的，转51test的帖子：

1. 缺陷摘要（Summary）

　　简单明了，便于理解

　　长度一般不超过30个单词

　　尽可能讲明：什么情况，导致了什么问题

　　便于他人定位Bug，杜绝不重复报相同的Bug

　　2. 缺陷描述（Descrīption）

　　重现步骤（Actions）

　　详细描述重现该问题的关键步骤

　　省略无关的操作，力求做到：所有重现步骤是充分的和必要的

　　容易理解的常规步骤，可以一句话带过，比如以管理员身份登录，进入后台用户管理页面

　　和环境有关的问题，给出特定的条件，比如某某操作系统，某某浏览器

　　实际结果（Actual Result）

　　描述实际出现的错误结果

　　可借助截屏来表达

　　不是总能重现的Bug，给出发生频率或规律

　　期待结果（Expected Result）

　　可选，当Spec上没有对实现方式做详细要求时，用于测试人员表达自己的看法

　　3. 截屏/附件（Attachment）

　　针对文字难以表达的或UI方面的问题

　　图片格式使用JPG格式；Windows画图工具的默认BMP图片太大，不建议使用

　　在图片上用醒目的颜色，标出问题所在区域

　　也可考虑配上简短的文字

　　4. 其它

　　对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug (TD提供了简单的Find Similar Defects的功能)

　　Bug严重程度(Severity)必须准确

　　Bug优先级(Priority) 必须准确（具体请参考公司标准文档）

　　填写Module/Function字段，便于Dev Manager 分配给相应的开发人员

　　项目中共性的问题，纳入Common Module

　　多个相同的问题，如是一个Dev负责修改的，撰写一个缺陷报告就可以，但须指出 问题发生的多个位置

　　对于Reject的有争议的Bug，尽可能和Dev当面沟通

    以上可以看出，测试环节中一个小小的提交bug的动作，做好与否都有差别，当然做好需要时间、精力、能力，这既要求你对产品的业务非常熟悉，同时对关键的实现机制也有概念，这些都需要你在平常测试过程中不断积累和总结；再则有些问题你描述的不清楚，开发看到bug无法重现时要么直接打回，要么跑过来咨询你相关的一些问题，一来一回的时间成本就大了，而测试的工作被打断的代价很高，好多人抱怨白天测试的工作效率很低，老被别人打断，所以你也要学会发现这些问题然后在实际的工作中能否解决一些问题；另外，测试做的深入一步，专业一些，项目组是看得到，测试是一个服务部门，你对别人的帮助越大，你的价值就越容易被认可，再从一个项目团队来讲，修改问题的效率越来越高，在团队良性工作和沟通循环下，团队的效率也越来越高。——现在很多公司都强调不管是什么岗位的人，建议把自己的工作都做在往前走一步，对于一个软件开发团队尤其需要这样。

    当然，做好一件事情，而且是长期的这样做，是需要有一个心理认同度的，否则估计很快就坚持不下来了。因此还需要一个良好的工作心态做基础——敬业和乐业。

    敬业可谓是责任心，乐业就是趣味。凡做一件事，便忠于一件事，将全副精力集中到这事上头，一点不旁骛；凡职业都是有趣味的，只要你肯继续做下去，趣味自然会发生。”为什么呢？第一，因为凡一件职业，总有许多层累、曲折，倘能身入其中，看它变化、进展的状态，最为亲切有味。第二，因为每一职业之成就，离不了奋斗；一步一步奋斗前去，从刻苦中将快乐的分量加增。第三，职业性质，常常要和同业的人比较骈进，好像赛球一般，因竞胜而得快感。第四，专心做一职业时，把许多游思、妄想杜绝了，省却无限闲烦恼。孔子说：“知之者不如好之者，好之者不如乐之者。”