使用桌面应用程序解决客户端盒子上的问题时，您需要哪些信息？
我们编写了一个 Windows 桌面应用程序，该应用程序安装在我们无法访问的数千台计算机上。当这些用户之一报告错误时，即使描述非常详尽，也有其他信息可能会有所帮助。
我们目前正在开发自动反馈代理，这意味着我们将能够访问非常详细的信息。但就像糖果店里的孩子一样，我们不知道从哪里开始。 在同一情况下，您会在反馈包中包含哪些信息？哪些信息有助于我们重现该错误？
到目前为止，我们得到的是：
- 我们的应用程序的版本号、
- 操作系统和操作系统版本号
- 代理信息
- .NET 版本和更新号
- 特定于我们的应用程序的信息（例如 数据版本）
- 访问和错误日志
请注意，这类似于此问题，但是我们对在程序崩溃时获取信息并不像在用户遇到错误时那样感兴趣。
编辑：澄清：不询问用户在出现错误时应提供哪些信息，而是询问我们应该以编程方式收集哪些信息？
We write a Windows desktop application that is installed on a few thousand computers that we have no access to. When one of these users reports a bug, even if the description is quite thorough, there is other information which may be helpful.
We are currently working on an automated feedback agent, which means we will have access to very detailed information. But like a kid in a candy store, we're not sure where to start. What information would you include in your feedback package in the same case? What is useful to help us reproduce there error?
What we've got so far is:
- The version number of our app,
- OS and OS version number
- Proxy information
- .NET version and update number
- Information specific to our app (eg.
data versions) - Access and error logs
Note that this is similar to this question, however we're not so much interested in getting info when the program crashes as we are as when the user experiences a bug.
Edit: Clarification: not asking for what information the user should give in the case of a bug, but rather what information should we gather programmaticaly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
即使您拥有所有这些信息，重现问题也可能很困难。当用户描述他们如何创建错误时，他们经常会误解关键步骤 - 当他们不了解应用程序的内部工作原理时，他们很难知道哪些区域是关键的。您可能想要实现一种跟踪用户操作的方法，例如根级事件处理或其他一些方法 - 如果您有撤消/重做功能，那么我确信这就足够了。然后，您可以在错误报告中包含操作链的最后 (x) 个步骤。
Even if you have all of that information, reproducing the issue can be difficult. When users describes how they created the bug they're often mistaken about key steps - it's hard for them to know what areas are critical when they don't know the inner workings of the application. You might want to implement a way of tracking user actions, such as root-level event handling or some other means - if you have undo/redo functionality then I'm sure this would suffice. You could then include the last (x) steps of the action chain in the error report.
编辑：我想我误解了你的问题。我以为您正在讨论从报告错误的客户那里获取哪些信息，而不是已经计划好我在这里描述的内容。无论如何，我会把它留下来供参考。
在类似的情况下，尽管用户较少，我们的应用程序还是有一个“打包日志以获取支持”按钮，该按钮将创建一个包含所有日志文件以及当前打开的项目文件（如果有）的 zip 文件。您描述的所有其他信息已经是日志文件之一的一部分。这样，客户可以方便地将 ZIP 文件发送给我们，这可以从主应用程序窗口完成，而无需打开项目文件或连接到网络接口，这是可能出现问题的两个要点。这比依赖用户“手动”提供反馈要容易得多。
除此之外，必须提供重现问题的确切步骤。其中大部分通常位于项目文件本身中（位于我们获得的 ZIP 文件中），仅缺少几个步骤。
除了您已经列出的内容之外，对此似乎很重要的事情：
Edit: I think I misread your question. I thought you're talking about what information to get from a customer reporting a bug, rather than already planning what I describe here. I'll leave it for reference anyway.
In a similar situation, despite fewer users, our app got a "Package logs for support" button which will create a zip file with all log files, and the currently opened project file, if any. All other information you described is already part of one of the log files. This way, a customer can conveniently send the ZIP file to us, which can be done from the main application window without opening a project file or connecting to a network interface, which are the two main points where something can go wrong. This makes it so much easier than to rely on the user providing feedback "by hand".
Other than that, the exact steps to reproduce the problem must be available. Most of that is typically in the project file itself (which is in the ZIP file we get), with only a few steps missing.
Things that seemed to be important for this, other than what you already listed:
除了应用程序的基本状态（版本、配置等）之外，要获取的最重要的信息是：
这些信息足以解决 99.9% 的问题。对于其余的，跟进并获取您认为有助于解决问题的任何详细信息（希望此时能够更好地理解）。
Aside from the basic state of the application (version, configuration, etc.), the most important information to get is:
That will be enough information to solve 99.9% of the issues. For the rest, follow up and get any detailed information you think will help solve the problem (which, hopefully, will be far better understood at this point).