◆ 第四，报告不可重现的缺陷，有助于测试人员和开发人员对这类问题和系统表现进行跟踪。

 

　　◆ 后，测试人员在报告不可重现的缺陷时，应该在缺陷报告中明确提示该缺陷不可重现或者难以复现，避免在进度压力太大的情况下，开发人员将精力过多地放在这种类型的缺陷修复上。

 

　　4)清楚地报告而非解决缺陷


　　缺陷报告是测试过程中重要的输出之一，编写良好的缺陷报告也是提高软件质量的重要保障。清楚的缺陷报告对测试团队而言具有重要的意义：

　　◆ 可以减少被开发人员拒绝从而打回来的缺陷数量。

　　◆ 加快缺陷修复的速度。

 

　　◆ 增加测试人员测试能力的可信度。

　　◆ 加强开发人员和测试人员之间的团队合作。

　　◆ 更加高效地提高软件质量。

 

　　因此，测试人员在提交缺陷报告的时候，应该从不同的方面保证缺陷报告的质量，一个好的缺陷报告应该具有下列特征：

　　◆ 精简的：缺陷的描述应该是清晰而简要的。在缺陷报告中要剔除不必要的无关的信息。在缺陷报告中包含所有缺陷相关的信息，并且确实是相关的，多余的信息只会使得缺陷的描述含糊不清。

　　◆ 正确的：提交的问题确实是一个缺陷。假如提交的缺陷后证明是由于测试人员的理解错误或者配置错误引起的，可能使得测试人员在开发人员面前失去可信度，同时会对彼此之间的沟通带来一些影响。当然，不能因为害怕提交错误的缺陷，对可能出现的缺陷视而不见，这比提交错误的缺陷影响更恶劣。因此，在提交缺陷报告之前，测试人员应该针对以下方面仔细检查：

　　确保搭建了正确的测试环境。


　　确保测试的版本是正式的测试版本。

 

　　确保不是前面执行的测试用例配置的信息干扰了测试结果。

　　确保网络通信没有问题。

 

　　确保测试人员正确地理解了产品的工作原理。

　　◆ 中立的：对缺陷及其特征进行实事求是的描述，避免夸张、幽默、讽刺的态度，避免在测试缺陷报告中带有个人感情色彩，因为这种感情色彩可能会影响团队之间的合作和沟通。

　　◆ 准确的：准确而明白地描述问题，不仅对做了什么进行描述，而应该对发生或者发现了什么进行描述。

　　◆ 隔离：尽量寻找简短的步骤复现缺陷，即将缺陷进行隔离，例如：缺陷所属模块、缺陷的触发条件等。对问题进行隔离定位，很大程度上体现了测试人员对测试对象的了解程度，同时可以提高测试效率和项目整体的效率。

　　◆ 推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等。测试人员在缺陷方面的推广有助于节约开发人员修正缺陷的时间，提高缺陷解决的效率。

　　◆ 复现：确定系统是否可以复现这个问题，以及复现该缺陷的步骤。对于能够复现的问题，应该提供简单的步骤和输入。对于难以复现的问题，尽量提供一些告警信息、日志信息;或者问题发现时，可以和开发人员一起进行跟踪调试和定位。对于实在无法复现的问题，在缺陷报告中应明确说明，并且在后续测试中持续跟踪。


　　◆ 证据：如同写测试用例需要测试条件一样，在缺陷报告中，需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距，以及提供测试的依据。


　　◆ 评审：在提交缺陷报告之前，好有一个有经验的测试人员阅读一遍。

　　测试人员在提交缺陷报告的时候，不要试图在缺陷报告中解决问题。因为测试人员和开发人员的角色和职责是不一样的，调试和解决问题是开发人员的主要职责。


　　5)明确缺陷优先级和严重程度

　　正确处理和区分缺陷的严重程度和优先级是所有软件开发和测试相关人员的一件重要的事情。缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同方面描述了软件缺陷对软件质量、用户、开发过程的影响程度和处理方式。一般来说，严重程度高的缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件的瑕疵，可以稍后处理。但是优先级和严重程度并不总是一一对应的，也存在优先级低但严重程度高的缺陷，或者优先级高但严重程度低的软件缺陷。

　　修改软件缺陷并不是纯技术的问题，有时候需要考虑软件版本发布和质量风险等因素。下面是关于缺陷严重程度和优先级设置方面的一些建议：

　　◆ 如果某个严重的缺陷只在非常极端的条件下产生，则可以将缺陷的优先级设置得比较低。

　　◆ 如果修正一个软件缺陷需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且市场要求尽快发布软件版本，那么即使这个缺陷严重程度很高，也需要仔细考虑是否需要修改。

　　◆ 对于有些缺陷，可能它的严重程度很低，例如：界面单词拼写错误，但假如这是公司的名称或者商标，则这个缺陷的优先级很高，必须尽快进行修复，因为这个关系到软件系统和公司在市场上的形象。

　　6)报告缺陷之前得到开发人员的确认

　　测试人员在测试环境中发现缺陷的时候，假如条件允许，在提交缺陷报告之前，可以和相关开发人员进行确认。当然，对于非常容易判断的功能性缺陷或者其他非常明确的缺陷类型，测试人员可以直接提交缺陷报告。而对于稳定性、功能行为表现复杂或者难以复现的缺陷，可以要求开发人员在测试现场确认发现的缺陷，这样可以提高项目的整体效率，有利于团队之间的合作：

　　◆ 首先，开发人员可以现场查看一些软件的打印信息和异常表现，有利于开发人员后面的缺陷复现和定位解决。

 

　　◆ 其次，开发人员可以帮助测试人员确认发现的问题是不是缺陷，避免测试人员提交一些不是缺陷的缺陷报告(例如：由于测试人员理解错误、配置错误等而导致的一些系统异常)，同时避免开发人员在不是缺陷的缺陷报告上面浪费时间和精力，提高测试团队和开发团队的效率。

 

　　◆ 第三，有利于开发人员和测试人员的沟通，包括对软件系统的理解，从而在项目团队之间更好地合作。

　　7)缺陷分析和测试进度管理


　　缺陷分析是测试过程中重要的测试活动之一，通过缺陷分析，可以了解项目的测试进展和软件产品的质量。缺陷分析也可以用来评估当前软件的可靠性，并且预测软件产品的可靠性变化。同时，缺陷的分析和评估也可以确定测试的重点，判断测试是否达到了测试出口准则等。