如何描述测试中BUG.docxVIP

测试过程中如何描述BUG1、术语解释 　测试程序：提供给测试组测试的程序; 　测试计划：对测试程序(构件、应用程序、系统等)及其目标进行简要说明; 　测试/html/98/category-catid-98.htmlbug：不符合测试/html/62/category-catid-162.html需求的错误，也就是/html/98/category-catid-98.html缺陷; 在这一点上，大家一定先熟悉业务，再属性应用系统的功能，只有在这两者兼备的基础上，才能开展相关模块的具体测试，才有鉴别测试过程中出现问题时的甄别能力，这点很重要。我们必须在第一时间确认出现的问题是自身的操作或测试前相关人员权限配置不足引发，还是由于代码逻辑不严谨或界面描述不正确等原因造成的系统问题。　错误跟踪系统：是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报告和错误趋势，如/html/15/category-catid-115.htmlRational /html/20/category-catid-120.htmlClearQuest就是一个错误跟踪系统 。目前我们的项目组暂时没有应用专业的BUG管理系统，也是导致我们BUG管理凌乱的一个原因，但我们还是可以通过其它一些辅助工具来实现对错误的跟踪，关键在于我们的组织和我们的人员对待工作的严谨态度。2、为什么要提交bug 　由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用： 　1)减少由于缺陷报告不明确而被/html/4/category-catid-4.html开发组驳回的情况，目前我们的人员在这方面普遍经验欠缺; 　2)加快缺陷的处理速度; 　3)提高测试的可信度; 　4)加强测试组与开发组在整个项目过程中的团队合作，这点很重要，近两周的工作观察，发现我们队伍中蒙头苦干的情况比较突出，沟通的方式方法上都有问题，如： 沟通及时性不够，语言表达过于生硬，问题表达不清晰等。测试人员其实在项目组有润滑剂的作用，因为干的活是得罪人的，所以以什么样的描述让开发人员清晰的接收问题，以什么样的方式方法和开发人员沟通，保持轻松愉快的气氛，都是需要我们不断总结提高。3、如何才能提交好的测试bug 　在有些组织里，/html/78/category-catid-478.html程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间;会影响程序员和/html/73/category-catid-273.html测试人员之间的团队凝聚力;最糟糕的是失去改进产品/html/5/category-catid-5.html质量的机会。 这个问题目前在我们的项目上表现的比较突出，有很大的原因是因为我们不是专业的测试人员和团队，组织不够严密，但人员的自我要求不高，钻研学习的干劲不足，交代任务执行力不强也是一方面。　有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，/html/74/category-catid-374.html测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过程、测试数据或不正确的/html/94/category-catid-94.html测试用例时，测试人员可能错误解释测试测试结果和报告错误。 　为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤： 　1) 结构：无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试;/软件测试 　2)再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率;例如，每3次出现一次，每3次出现2次等; 　3) 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。 　4)总结：简要描述客户或用户的质量体验和观察到的一些特征。 　5)压缩：精简任何不必要的信息，特别是冗余的测试步骤。 　6)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。 　7)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。 　8)评审：至少有一个同行，最好是一个有经验的/html/73/category-catid-