测试过程中如何准确进行bug描述
1、术语解释
测试程序：提供给测试组测试的程序；
测试计划：对测试程序（构件、应用程序、系统等）及其目标进行简要说明；
测试bug：不符合测试需求的错误，也是缺陷；
错误跟踪系统：是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报告和错误趋势，如Rational ClearQuest是一个错误跟踪系统
2、为什么要提交bug
在得到一个详尽的测试程序后，剩下的工作是执行测试计划了。但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也是bug。因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用：
1)减少由于缺陷报告不明确而被开发组驳回的情况；
2)加快缺陷的处理速度；
3)提高测试的可信度；
4)加强测试组与开发组在整个项目过程中的团队合作
3、如何才能提交好的测试bug
在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；糟糕的是失去改进产品质量的机会。
有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。
为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤：
1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试；
2)再现：尽量三次再现故障。如果问题是间断的，那么好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；
3) 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。
4)总结：简要描述客户或用户的质量体验和观察到的一些特征。
5)压缩：精简任何不必要的信息，特别是冗余的测试步骤。
6)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。
7)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。
8)评审：至少有一个同行，好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估报告之前先自己读一遍。
好的测试bug描述是告诉读者测试人员发现了什么，而不是测试人员做了什么。因此只需要根据上述八个步骤写下少的必需重现步骤。
4、如何提交bug
一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。
好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。
①标题
使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的描述比较轻微，例如：“联系人的email没有检查合法性”；重要的要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。
②项目
是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。
③所属模块
是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误；
④优先级
分为以下4级：1级：“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求；2级：“高度重视”，表示有时间要马上解决，否则系统偏离需求较大或预定功能不能正常实现；3级：“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等；4级：“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。
⑤重要性
分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示修改以后流程会更好。
⑥异常等级
有以下5级：系统崩溃－指该错误使得操作系统死机等致命性的错误；应用程序崩溃－指该错误使得测试程序崩溃，即无任何反应；应用程序异常－指错误使得应用程序结果不符合逻辑或是初的需求；轻微异常－指错误有，但是无伤大雅，例如错别字等；建议－指改进后更好，不改进也对程序无碍。
⑦可重复性
是针对问题是否通过执行“操作步骤”可以重新出现，如果是“可再现”；如果这个bug只出现了一次，再也不出现了，称这类问题为“不可再现”；其余的是“未知”，如每隔几天才出现一次；
⑧现象
是对标题的详细描述，因为标题不宜过长，所以现象也是对标题的具体化。
⑨操作过程
是指对于可重现的bug，执行这些操作步骤可以出现该bug；对于不可重现和重现概率为未知的bug，通过备份的数据库和操作过程可以重现该bug。
⑩附件
是粘贴必要的附件，如果是可重复性是“可重现”的bug，则可以参考步骤是否复杂，如果很复杂，则可以粘贴附件，从而使得开发人员直接可以明白是什么问题，提高开发人员的修改效率；如果步骤不多有能够重现，则可以不粘贴附件。如果可重复性是“不可再现”的，这种情况必须粘贴附件，以备份出现问题后的情形；如果是未知的，也必须粘贴附件，因为开发人员不可能把时间耗费在等待bug的重现上。
