C# 解决客户问题时,您需要哪些信息;使用桌面应用的s盒?

C# 解决客户问题时,您需要哪些信息;使用桌面应用的s盒?,c#,desktop-application,bug-reporting,C#,Desktop Application,Bug Reporting,我们编写了一个Windows桌面应用程序,安装在几千台我们无法访问的计算机上。当其中一个用户报告一个bug时,即使描述非常详尽,也有其他信息可能会有所帮助 我们目前正在开发一个自动反馈代理,这意味着我们可以访问非常详细的信息。但就像一个在糖果店的孩子,我们不知道从哪里开始在相同情况下,您的反馈包中会包含哪些信息?哪些信息有助于我们重现错误 到目前为止,我们得到的是: 我们应用程序的版本号 操作系统和操作系统版本号 代理信息 .NET版本和更新编号 特定于我们的应用程序的信息(例如。 数据版本)

我们编写了一个Windows桌面应用程序,安装在几千台我们无法访问的计算机上。当其中一个用户报告一个bug时,即使描述非常详尽,也有其他信息可能会有所帮助

我们目前正在开发一个自动反馈代理,这意味着我们可以访问非常详细的信息。但就像一个在糖果店的孩子,我们不知道从哪里开始在相同情况下,您的反馈包中会包含哪些信息?哪些信息有助于我们重现错误

到目前为止,我们得到的是:

  • 我们应用程序的版本号
  • 操作系统和操作系统版本号
  • 代理信息
  • .NET版本和更新编号
  • 特定于我们的应用程序的信息(例如。 数据版本)
  • 访问和错误日志
请注意,这与类似,但我们对程序崩溃时获取信息的兴趣不如用户遇到错误时获取信息的兴趣大


编辑:澄清:不是问用户在出现错误时应该提供什么信息,而是问我们应该收集什么信息。我想你说的是从报告bug的客户那里得到什么信息,而不是我在这里描述的内容。不管怎样,我还是把它留作参考

在类似的情况下,尽管用户较少,但我们的应用程序得到了一个“PackageLogsforSupport”按钮,该按钮将创建一个包含所有日志文件和当前打开的项目文件(如果有)的zip文件。您描述的所有其他信息已经是其中一个日志文件的一部分。通过这种方式,客户可以方便地将ZIP文件发送给我们,这可以从主应用程序窗口完成,而无需打开项目文件或连接到网络接口,这是可能出现问题的两个主要方面。这比依靠用户“手工”提供反馈要容易得多

除此之外,必须提供重现问题的确切步骤。其中大部分通常在项目文件本身中(在我们得到的ZIP文件中),只缺少几个步骤

除您已经列出的内容外,似乎对此很重要的内容:

  • 用户/帐户信息。这可能有助于解决权限问题。您可能希望包括时区、区域设置、Windows主题等内容
  • 应用程序配置,包括安装位置
  • 如前所述,用户正在处理的当前文件,因为这可能是问题的原因
  • 用户设置,即应用程序为每个用户存储的数据。看到这些奇怪的东西。MRU列表也可能有帮助

除了应用程序的基本状态(版本、配置等),最重要的信息是:

  • 重现错误或bug所需的步骤,包括可能时使用的输入
  • 预期产出
  • 实际产量
  • 联系信息,以防您需要跟进(如果您的软件是匿名使用的)

这些信息足以解决99.9%的问题。对于其余部分,跟进并获取您认为有助于解决问题的任何详细信息(希望在此时能更好地理解这些信息)。

即使您拥有所有这些信息,重现问题也可能很困难。当用户描述他们是如何创建bug时,他们经常会在关键步骤上出错——当他们不知道应用程序的内部工作时,他们很难知道哪些方面是关键的。您可能希望实现一种跟踪用户操作的方法,例如根级别的事件处理或其他一些方法-如果您具有撤消/重做功能,那么我相信这就足够了。然后,您可以在错误报告中包含操作链的最后(x)个步骤。

但是,如果我们可以自动获取一些详细信息,而用户不必承担任何费用,为什么不在他们提出请求时将其捆绑起来,避免我们的操作上下双向(不幸但必须如此)与最终用户的通信链很长?@Robert:当然,自动化程度越高越好。然而,在代码中设置它可能会产生巨大的成本。您必须记录输入到系统中的每一条信息,这实际上会复制您的底层数据集。除非系统不稳定(在这种情况下有更大的问题需要处理),否则仅在需要时询问相关信息就足够了。+1用于使用内置的撤消功能。好主意。如果可以的话,使用撤销功能似乎是一个很好的跟踪选择。迄今为止最好的主意。相关: