Visual Studio 2012 反馈工具： 提交 bug 的更好方式
[原文发表地址] The Visual Studio 2012 Feedback Tool: A better way to submit bugs
[原文发表时间] 2012-06-20 10:00
在过去十年里，Microsoft Visual Studio一直成功地运行着，此成功的很大程度是通过与我们一路走来的客户的伙伴关系来实现的。我们相信通过更好的对话，你们可以构建出更好的产品，我们的反馈渠道旨在帮助我们倾听并回应当你们在日常的基础上使用我们的产品时你们告诉我们的东西。
有着超过 5000 万行的代码，Visual Studio可能需要一些时间来充分纳入更多的改变。这看起来好像我们没有倾听，但事实是，我们花费大量时间阅读、 响应和巩固客户的反馈。并且，我们正在不断地寻找新的方法来提供产品的更频繁的更新。
一般来说，如果我们早些时候得到的反馈越有价值的话，我们就更有可能执行任何后续的更改。 虽然我们始终在征求并感谢反馈意见，但是在早期的发布时间范围内，这就变得特别重要。我们积极追求来自我们的客户关于用户体验、 性能和功能增强事情上的反馈。通常此反馈是通过这些渠道到达我们的，例如UserVioce， Microsoft Connect、论坛、 Visual Studio博客和调查。
至于您遇到的具体问题，我们请求您通过UserVioce提交想法和使用 Microsoft Connect提交bug。现在，我们想与大家分享一些我们取得了的改进，它是有关提交 bug体验，以及 bug 质量的。但在我们深入挖掘这些改进之前，让我们先看看当您在 Microsoft Connect web 站点上提交一个 bug 时，会发生什么事情。
一只bug的生活 — — 当您提交一个bug时，发生了什么？
当您在 Microsoft Connect web 站点上提交一个bug时，该 bug 就去世界各地旅行 （字面上的意思）。一旦提交了，在上海的最初客户支持团队会基于您的描述和您上传的附件来尝试重现该问题。一旦他们重现了此问题，他们会看看是否其他人已经提交了一个针对该问题的 bug。如果是这样的，他们将您的bug关闭,标记为" Duplicate "，并在其中添加一个到原始 bug的链接。如果该 Bug属于 Visual Studio之外的其他团队，例如 Windows 或Office，团队会给予一些回应，给予适当的渠道来与其他团队联系，并将bug关闭,标记 为" External "。
一旦确认了该 bug 是 Visual Studio 产品问题，客户支持团队会将该 bug 分配到相应的产品团队，那儿我们的工程师开始进行更深入的调查。该团队会基于问题的关键性和受影响的用户数量，以及引入bug的风险来排定优先级。如果问题或请求的更改被视为产品的下一版本中足够高的优先级，那它就被分配给开发人员来修复此bug。正如您可能会预料的，在产品周期（Beta）中，较早提交的bug 和请求的更改更有可能由产品团队接受，而在后期（RC版或更高版本）提交的变更请求就不会比早期的容易接受。随着时间的推移，我们的更新模式日趋成熟，事情可能会进一步向前发展，但目前，这是它的工作原理。
提高重现率
正如我们前面提到的，实际上，我们的工程师做的第一件事是尝试重现您的问题。考虑到客户机器的配置和产品交互的可能性，此过程颇具挑战性。一般情况下，我们能够重现其中75%左右的bug。对于性能或与崩溃相关的问题，重现率降到了 50%。重现一个挂机、 系统崩溃和性能问题是非常困难的，它通常是由表面之下的因素驱动的。很多时候，我们的工程师不能使用给定的说明和信息重现该问题，所以他们会让您提供关于这一问题的更多详细信息。该信息可能会非常具体，比如，询问您的计算机配置，或更多地参与。例如当您在您的机器上重现此问题时，就会安装性能诊断工具来收集数据。在更复杂的情况下，我们最终会给您提供指示来如何捕获此类文件，然后将您的文件上传到一个临时的工作区 （这儿是Connect上的一个bug例子： 555117）。假设我们可以得到我们所需要的数据，性能和崩溃的重现率仍然只是在 50%左右。此过程是对于您和我们的工程师来说都是繁琐的。
为了解决重现问题的复杂性，我们已经发布了Visual Studio 11 反馈工具，它让您更轻松地快速提交一个可重现的 bug。该工具可以帮助您快速捕获追踪、 屏幕截图、 系统信息、 Visual Studio 的版本和我们的工程师需要隔离和定位问题的其他有关的数据。我们在 Visual Studio 11 beta 版中发布了一个此工具的早期版本，结果令人非常鼓舞。到目前为止，通过Visual Studio 2012 反馈工具所提交的 bug的重现率为95%左右，包括那些很难重现的性能和崩溃bug。同时提交Bug的体验也变得更简单了，当您使用 Visual Studio 时，它会自动捕获信息，而不是手动输入。
在这篇文章的最后，你会找到一个链接，它是有关如何使用该工具的分步指导。但首先，让我们看看两个功能：自动数据收集和Repro recorder，它们能够让您记录更多可操作的bug。
自动数据收集
当您提交了一个 bug 时，该工具会自动收集有关您的计算机配置、 操作系统、 Visual Studio 的版本和环境的信息。让我们快速看看一些我们收集不同的文件类型的数据，以及我们如何受益于此类信息。
有很多来自 Visual Studio扩展的好处，但有些时候，扩展、 软件包或控件可能会破坏Visual Studio的安装。例如，当我们推出 Visual Studio 2010动力工具 （一个扩展软件包）时，我们发现，在某些条件下，解决方案导航器扩展可能导致Visual Studio崩溃。为了解决类似的情况，Visual Studio 11 反馈工具自动收集一个称为SQMExtensionsLogs的日志文件。如果我们的工程师怀疑您的问题可能与已知的扩展、 软件包或控件有关，他们可以查看此日志文件，并更可靠地决定下一步。
反馈工具捕获了有关激活的Visual Studio 实例信息，包括版本和 SKU，以及有关您的解决方案的大小和形状的粗略统计报表信息。这份报告包括有关您的解决方案的结构信息，例如在您的解决方案中有多少个工程，使用的工程的种类和每个工程中的项目数，但不包括任何有关您的代码的细节。该工具还收集操作系统的详细信息，例如操作系统版本、 语言环境、Visual Studio是否正在远程桌面下运行,甚至是否启用 Aero。此类信息存储在一个 VSInfo.xml 文件中。对于工程师尝试重现该问题来说，此信息是非常有用的。它比手动键入该问题的描述有用得多。它也比请求客户上传示例代码或解决方案文件更为有效（这里是从 MS Connect上手动上传示例体验的示例：650587).
在测试Visual Studio 代码库时，我们尝试使用各种硬件配置来模仿我们的客户体验。但考虑到所有可能的组合，它不可能为所有配置来测试我们的代码。在 Visual Studio 2010中，例如，我们已找出某些特定硬件的性能问题，而且我们发布了一个硬件配置的列表，其中列举了通常会遇到的问题，以及如何排除故障。为了理解这种关联，我们不得不通过电子邮件，或在MS Connect和论坛上不停地交流来从客户那儿收集大量的信息。Visual Studio 11 反馈工具自动收集此机器配置，并将其放置在 DxDiagOutput.txt 文件中。我们的工程师将使用此信息来事半功倍地查找相关性和解决这些问题。
Repro recorder
虽然我们有时可以从书面的重现步骤中来重现一个可重复问题，但当包括了问题的说明记录和诊断信息时，我们几乎总是可以重现问题。取决于您遇到的问题类型，某些记录比其他的更有价值。例如，我们需要了解您遇到的性能问题与我们需要了解你在 Visual Studio 中遇到崩溃是完全不同的。为了使此过程更简单，我们已推行一项称为Repro recorder的功能。
如果您在产品中遇到性能缓慢，使用 Windows Events追踪对于我们的工程师解决问题是很有帮助的。这种追踪文件帮助我们的工程师确定问题是否基于 CPU、 磁盘或网络密集，是否这一问题来自完全不同的程序 （有关更多的信息，可以阅读有关如何做性能分析）。在Visual Studio 2010中，我们要求我们的客户安装性能诊断工具来收集这类追踪文件，接着阅读" How To "文件，然后将其上传到工作区。现在我们有一个此工具的更轻版本，叫做 Microsoft Visual Studio Trace recorder，它与 VS11 反馈工具集成在一起。因为此工具优化了追踪收集，因此只要出现了问题，你就可以运行它，并可持续约 2 个小时。因此，即使没有持续地发生性能问题，您也可以轻松地捕获追踪信息。取决于您遇到的问题的类型，我们的工程师使用不同的工具来分析您的追踪文件。例如，如果您的问题与编辑的响应能力有关（如Intellisense弹出来得很慢，或当你键入时，迟迟不显示字符），因此，我们使用我们的RaceTrack工具，它使我们能够只专注于键入特定的事件的期间 （如果你想了解如何使用此工具来改进编辑响应的更多信息，请参见Eric Knox的博客).
如果您在 Visual Studio 中遇到一个崩溃，您将看到一个Watson对话框。Windows Error Reporting服务会收集 Visual Studio 的内存转储，并询问您是否要向 Microsoft 发送报告。此报告对我们识别并修复最频繁的崩溃问题是非常有益的，但只有您向我们发送错误报告，我们才知道有关的问题。这种报告收集在中央Watson服务器中，我们的工程师不断地查看它来找出最多的问题，并修复其中大部分。除了发送Watson报告之外，您可以使用反馈工具报告一个Connect bug。Visual Studio 2012 反馈工具允许您轻松地捕获有关的资料，并与VS 调试器一起来捕获转储文件，并与 Windows Problem Step Recorder一起捕获您的步骤。Connect bug将会为你提供一个地方来分析了解这一问题，但Watson捕捉到问题之后，就没有后续行动。
如果 Visual Studio 挂起了 （例如，编辑器冻结了一段时间），您通常无法获得Watson对话框。挂起在本质上类似于崩溃，但却难以检测，因为IDE 通常来自冻结。随着崩溃，内存转储会告诉我们是什么挂起了应用程序。因为出现挂起时，Visual Studio 进程仍然是可用的，因此与崩溃相比，通常更容易收集有关挂起的信息。而且，是的，即使您有一个挂起的 VS 实例，您可以仍然启动 Visual Studio 2012（11） 反馈工具。（如果你有兴趣了解如何调查挂起和崩溃，请参见这篇博客文章).
对于一个与性能、 挂起或崩溃无关的问题，您仍然可以利用Repro recorder功能来捕获屏幕截图。正如古语所云，一张图片胜过千言万语。
摘要
VS11 反馈工具是一个丰富的诊断机制，它让我们更准确地查明您可能会遇到的任何问题，让您可以快速地通过Connect向我们发送问题的详细信息。您的bug在Connect上对您将是可访问的，就像Microsoft Connect web站点上手动提交的bug一样。该工具将帮助您快速地捕获追踪、 屏幕截图、 或其他可以用于快速重现您遇到的问题的数据片段。您还可以添加其他的文件，如示例代码、 项目、 屏幕截图等。我们的工程师可以使用其他的数据来识别恶意代码路径、与系统设置或计算机的配置有关的问题，或简单地获取更清晰的再现步骤。
请下载Visual Studio11 反馈工具并尝试一下，帮助我们做出更好的 Visual Studio产品吧 ！有关如何使用该工具的详细信息，请参阅如何使用 Visual Studio 2012 反馈工具.