如何教您的用户/客户发送更好的错误描述

我经常不得不与正在报告应用程序错误的客户或用户打交道。大多数情况下，它们的内容是无用的

• 错误！！！
• x不起作用

没有更多的信息。

为了解决问题，我必须要求它们的每个细节，这通常比解决问题本身要耗费更多时间。其他人以不理想的格式发送信息，例如（数据记录的快照，而不是错误的）屏幕截图，尽管它们可以发送链接（我们可以访问系统），等等。

您如何告诉用户/客户更详细地描述问题，从而使双方的整个过程都更加容易？

编辑

这个问题更多的是关于社交技巧，而不是如何以编程方式收集日志和错误信息。我知道以下事实：这应该是好的软件设计的一部分。

奖励您的用户良好的错误报告，对他们的错误报告进行惩罚（至少要惩罚一点）。

用户需要了解，良好的错误报告对于您快速解决问题至关重要，因此对他也有好处，因为他会更快地获得解决方案。

因此，第一个答复可能是“好吧，我已经阅读了您的报告，但我不知道从哪里开始。您能告诉我：这是否发生过一次？这是重复出现的现象吗？您可以尝试X并告诉我什么吗？看起来像吗？” 等等。

人们常常会收到这样的反馈，告诉他们该做什么，并（直接或间接地）告诉他们他们一开始就没有做的事情。也许不是马上，但他们提交的报告越多，他们（通常是无意识地）就越会预测您要问他们的问题并直接提供答案。

是的，这是一个循序渐进的过程，直到明天早上才能解决所有的通信问题，但这仍然是一个开始。

我已经看过几个开源项目所做的一件事是为错误报告编写一个标准的“表单”，其中包含一些常用信息的部分。

如果您拥有客户可以访问的错误报告站点或应用程序，请查看是否可以将其空白版本作为错误描述字段的默认文本。否则，将其放置在他们可以找到它的位置（或指向它们的位置），例如在您的站点或产品的安装目录中。

对于您的情况，可能是这样的：

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

（此处的“您”是指客户）

这个想法是通过提供最有用的信息种类列表来鼓励他们提供有用的信息。

通常，我每次都会要求他们提供错误的屏幕截图，最终他们会开始将包含错误请求的屏幕截图发送给我，因为他们知道我会提出要求。

我仍然有时需要打电话给他们以获取更多信息，但是很多时候我仅通过查看屏幕快照就可以看到问题。

但是我同意@Mahmoud的评论，即最好的方法是使应用程序向您发送错误，而不是依赖用户。

悲观的看法：你不能。与40年前一样，情况是更多的用户，更多的系统，更多的应用程序。

（请注意，悲观主义者只是经验丰富的乐观主义者。）

让他们容易做或不会做。

最好以最简单的方式使他们可以报告错误，从而为您提供所需的信息。这几乎肯定意味着要在软件中自动执行错误报告过程。

保留详细的日志文件并将其附加到错误报告是一个开始。

与客户的对话结束后，对他们说：“下次发生这种情况时，请准备好数据项A，B，C等。” 当然，仅当这些相同的客户反复回电时，此方法才有效。我在这种方法上取得了成功，在该方法中，用户了解了一些关键事项，这些重要事项将a）加快通话速度，b）更快地提高整体分辨率。

如果大多数都是一次性调用者，则最好更新“ ERROR！”。屏幕上显示“您在与我们的代表交谈之前必须收集数据项A，B，C ...”。这实际上取决于您对应用程序的控制程度，因此可能根本无法执行。这也不是肯定的方法，但希望它能使客户想到“ ERRORZ PLZ HLP !!!”。是不足够的。

在现代应用程序中，错误消息的问题在于几乎不可能包含所有可能相关的上下文。从处理器体系结构到一天中任何时候的任何事物都可能是相关的，这就是为什么错误报告和错误处理都比科学更具艺术性的原因。诸如此类apport-bug的系统非常有用，因为它们收集了相关信息并将其提交给您。不幸的是，在物质复制者，时间旅行和海森堡补偿器出现之前，无法确保从用户那里获得的信息足以调试甚至重现问题。

记录您需要的一切。我们有一个x mb的滚动日志文件。如果发生问题，用户将发送日志文件，通常足以解决问题。

另一种选择是使用远程桌面客户端自己查看问题所在。这些天就像让客户端下载exe一样容易。

您将不得不提出尖锐的问题，并且对它们的要求很高，才能为您提供所有答案。有时，他们对问题的抱怨会散布在周末的计划中，或者关于他们的其他重大问题或天气的抱怨。尝试让他们保持任务状态，问他们：“好吧，当您执行X但不执行Y时，会发生什么？” 注释他们的响应，以便您开始构建事件的序列图，以后可以回去进行调试。

您可以花一些时间，并在应用程序的右上角添加一个“报告错误”红色按钮。当用户按下按钮尝试进行屏幕截图时，收集会话的所有可用日志，（可能值得这样做）打开直接屏幕共享到用户屏幕，向他显示简单表格并自动将数据发送到您的服务器。

-尝试尽可能少地询问用户您的应用程序本身是否可以获取数据。屏幕分辨率，操作系统版本，用户名，登录名，上次操作和日志

-将票证分配给用户并为其提供链接，因此他知道他在www.yoursite.issues / 1234上具有错误号1234。

-向用户询问他试图实现的目标。

我认为所有这些甚至全部可以帮助您接收足够的数据，并向用户显示他可以帮助您使软件变得更好。

最简单的方法是使用可以“理解”客户实际需求的工具。有很多工具，但最好的是Usersnap。 在这里看到这个故事。