报告潜在错误
碰巧在对测试过程中发现的某些问题进行审查或调试时，我发现了另一个错误。例如，我发现传递给客户端存根的参数未在Web服务请求中转发。从Web服务文档中，我得出结论，这可能会导致集成缺陷（例如，它可能会更改请求的语义或导致强制参数的服务失败）。
我将其报告为错误并描述了潜在的影响，但是我没有时间实施全面的测试来引发这种失败。尽管如此，开发人员仍然要求我指定重现该错误以及实际效果和影响的步骤。
报告在检查过程中发现的错误而不进行测试是否公平？
报告API质量
我发现的一部分问题没有影响应用程序行为，但涉及API质量。例如，我发现子系统API具有多余的参数，该参数从未被组件使用，但是使用此API会使开发人员和测试人员感到困惑（“我应该在此处输入什么值？”）。
我应该在错误跟踪系统中报告此类问题吗？
#1 楼
我认为公平不是问题。更为重要：报告是否有用？对于Web服务的使用，报告的有用性部分取决于您的审查范围。给定您检查过的代码，您会感到担忧。但是也许其他代码（不在您的审查范围之内）可以防止您担心有问题的情况。
不幸的是，在这一点上，我们不知道问题是否是问题，我们赢得了直到有人进一步调查才知道。但是每个可以调查的人都在关注其他优先事项。这是错误报告的常见问题：谁负责调查？您希望开发人员做到这一点；他们希望您这样做。
您正在学习的是，此错误报告不足以激发其他人进行调查。在这一点上，我倾向于调用《责任剃刀》：如果我想做点什么，我有责任做到这一点。您将不得不进行自我调查，或者做更多的工作以说服他人进行调查。
您的调查可能不需要进行测试。也许通过一些特定的值遍历代码就足够了。这是否具有说服力，取决于您选择的值的合理性，以及各种人对Web服务将执行的操作的假设。但是，我将从这里开始。
如果您没有时间这样做，那就表明这对您来说很重要。因此，请编写报告，然后放手去做。
对于API，错误报告的有用性部分取决于API的受众。如果该API仅在内部使用，并且仅由一小部分人使用，那么我将由内部用户决定该API是否满足他们的需求，并根据需要进行更改。如果您的团队以外的人使用该API，也许您可以收集有关他们对API的使用的信息。如果它引起麻烦，那是一个错误。
评论
所有答案都是有帮助的，但是这个答案恰好将问题命名为“报告有用吗？”。并解释说有人需要找时间调查是否确实有问题。
– dzieciou
2012年11月15日在6:44
#2 楼
是的，无论您以何种方式检测到错误，都可以报告错误。您可能会发现开发人员需要步骤来重现该问题，在这种情况下，您可能必须先做更多的工作您可以期望该错误会被修复。
通过阅读代码发现的错误仍然是一个错误。 （除非它实际上不是错误，因为您误读了代码或不理解它-但这是一个不同的问题。）
考虑反对意见-如果您不报告错误怎么办你知道在那里吗？可能会导致什么后果？
#3 楼
我认为您应该问开发商和企业主，而不是我们。 :-)问他们如何处理这类边境案件。他们是否还希望对尚不清楚的事物进行错误报告以提醒他们，还是想先讨论一下并逐案决定是否提交错误？请记住，向他们提供有关错误或可能出错的信息是您的任务，但最终，由他们决定如何处理这些信息。一种很好的处理API质量的方法是问题是将需要改进的事情分为一个单独的类别，但暂时不会做。至少如果有人在某个时候回来并且对他们有所作为。如果什么都不做，那么拥有这样的列表实际上比仅决定错误/没有错误决定还要糟糕。
评论
谢谢，Edu。在您的实践中，您将此类新类别放在哪里进行改进？在错误追踪系统中？还是您有一些单独的系统来跟踪技术债务？我看到的一个选择可能是协作代码审阅的工具，可让您注释代码...
– dzieciou
2012年11月13日19:55
所有这些都可以正常工作。如果您可以每天不打扰所有人的方式输入错误跟踪系统，那么可能会很容易。
–教育
2012年11月13日在20:05
#4 楼
从您的解释中，我可以推断出两件事代码审查显示未处理/传递的参数
没有时间对其进行测试
我的问题
我会挑战为什么您没有时间对其进行测试。您可以检查诸如SOAP UI之类的Free工具，这些工具可以直接测试方法而无需编写任何代码。
其次，报告问题而不进行实际验证不是正确的做法。我强烈建议您在提交问题之前重现问题
您的信誉可以在单元测试，代码审查会议上为开发人员提供帮助。具有质量意识的开发人员一定会在代码审查会议期间考虑您的输入
评论
SOAP UI只是游戏的一部分（在测试驱动程序部分）。该系统很复杂，并且依赖于外部组件，因此仅为此测试设置环境是昂贵的。另外，由于该请求是由许多子系统转发的，因此我需要在最后一个请求中对其进行验证。但是您是对的，我可能会挑战自己如何为更快/更轻松地设置整个环境以进行测试。
– dzieciou
2012年11月13日19:46
#5 楼
公平吗？我想这取决于上下文-您问谁以及他们对公平的定义是什么。我认为在没有问题证据的情况下打开错误的一个重要考虑因素是，这可能会降低错误报告读者的信誉。
错误报告是测试人员的主要工作产品。它们是其他人（程序员，分析师，经理等）最常看到的有形工作，因此，当我们编写错误报告时，确保它们反映出我们希望别人看到的东西，这一点很重要。它们写得很好，并包含适当的元素以修复错误。如果我们撰写不良报告，我们将失去信誉。如果我们撰写大量好的报告，我们可能会赢得信誉。
如果您没有时间测试某些东西以证明（证据）它是一个错误（与问题，增强等相反），则可以随时对其进行记录并返回以后再说。如果在错误跟踪器中打开它，则可以找到一种将其分配给自己的方法，直到您有时间验证/查找问题的证据。
如果您对某个方面有疑问质量（这是bug吗？），但不确定您可以以更非正式的方式提出问题（假设在bug跟踪器中打开是正式的）-亲自，电子邮件，即时消息等。当您有证据表明它是一个错误时，通常建议您正式编写它。再者，这一切都取决于组织。
评论
当您报告“潜在错误”但实际上未执行测试时，修复该错误后会发生什么？那你会测试吗？或者只是阅读代码并称其足够好？我发现我会对此进行重新审查，因为它们相当琐碎且显而易见。我还想将系统测试（准备好测试环境时将执行的测试）集中在该区域。