如何才能提交好测试bug.doc

如何才能提交好的测试bug 测试环境 和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。 有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。 作为一个好的测试人员，必须遵循以下八个步骤： 1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的 测试 软件测试 2)再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率;例如，每3次出现一次，每3次出现2次等; 3) 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出 现这种问题，特别是那些存在严重影响的问题。 4) 总结：简要描述客户或用户的质量体验和观察到的一些特征。 5) 压缩：精简任何不必要的信息，特别是冗余的测试步骤。 6) 去除歧义： 使用清晰的语言， 尤其要避免使用那些有多个不同或相反含义的词汇。 7) 中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的 语句，引起过度的注意力或忽视。 8) ⑨操作过程 是指对于可重现的，执行这些操作步骤就可以出现该Bug；对于不可重现和重现概率为未知的bug，通过备份的数据库和操作过程就可以重现该bug。 ⑩附件 是粘贴必要的附件，如果是可重复性是“可重现”的bug，则可以参考步骤是否复杂，如果很复杂，则可以粘贴附件，从而使得开发人员直接可以明白是什么问题，提高开发人员的修改效率；如果步骤不多有能够重现，则可以不粘贴附件。如果可重复是“不可再现”的，这种情况必须粘贴附件，以备份出现问题后的情形；如果是未知的，也必须粘贴附件，因为开发人员不可能把时间耗费在等待bug的重现上。粘帖附件的组织一般为截屏的图片，但应当对图片做必要的加工补充，描述相关信息，便于开发人员快速的定位问题，如果是比较复杂的问题，需要截取多个图片并描述不同图片之间的关系。这点在我们今后的工作中要注意提高，不能简单粗糙复制粘帖图片，最好有单独的文件整理图片，以超链接的方式链接相关文件，既要保证BUG描述信息管理页面的清晰，也要保障信息的准确与完整性。 。下面讲一讲BUG的描述规则：  1.摘要主要用于指明Bug发生的地点、在什么条件下发生什么现象。  2.描述字段：  1）描述Bug发生的地点、所用账号类型、操作步骤、期望值、实际值， 如果Bug与浏览器相关，需尽量描述更多的环境参数，如操作系统等。  2）一个Bug不会包含多个问题，会尽量单一化，便于跟踪处理及统计  3）对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。  4）尽量减少重现的步骤以达到用最少的步骤来重现问题；  5）不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。  6）不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。  7）在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。  8）测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。  9）如有必要可以把产生结果的SQL语句放上去，不过需要开发人员在短时间内定位问题，否则测试人员不能保证数据的完整性。  10）如果是概率性的BUG,尽量重现BUG,找到BUG产生的条件，如果找不出BUG产生的原因必须写明BUG发生的概率大约是多少。  11）BUG如果在特定条件下产生的，必须写明BUG产生的条件和操作步聚。