过去，测试人员提交的Bug报告时而不时地会被程序员以“信息不足”或“Bug无法再现”为由给退回来，而现在，如果测试人员是使用VS 2010（更准确地说，是使用Microsoft Test Manager）提交Bug报告的话，那么程序员将很难找出借口拒绝承认某个Bug的存在，因为使用VS 2010生成的Bug报告所包含的Bug信息可以说要多详细就有多详细，那么这样一份详尽无遗的Bug报告在VS 2010中是怎样被生成的呢？这正是本文要详细说明的问题。
在VS 2010中，我一般会先使用Microsoft Test Manager (MTM)创建测试用例，然后再使用Microsoft Test Runner (MTR)来执行手工测试。具体如何创建一个手工测试用例，我们今天就不多讲了，如果大家想进一步了解，MSDN上有详细的说明。
假设我们此前已经创建好了一个测试用例，现在我们要用它来测试一个Web应用。首先，我们先要在MTM中启动MTR来执行一个手工测试（参考图1）。
随后，在执行手工测试的过程中，如果被测软件运行正常，我们要在MTR中将当前步骤标示为“通过”，即打一个绿色的勾（参考图2）。
而如果我们发现被测软件出现异常，我们应首先将当前步骤标示为“未通过”，即打一个红色的叉，同时，我们还可以在当前步骤的正下方输入一段文字来说明我们目击到的情况（参考图3）。
另外，我们此时还可以通过MTR中的“照相机”截取一张屏幕截图，这张截图会被自动附在我们随后提交的Bug报告上，这里MTR为我们提供了三个选项：一是让我们截取一个任意长宽的矩形图，二是截取一个完整的窗口图，三是截取一张全屏图，此处我们可以根据具体需要做出选择（参考图4）。
最后，也是最重要的，我们需要通过MTR创建并提交一个Bug报告。这里MTR也为我们提供了三个选项（参考图5），此处我们将选择第一个选项，即"Create bug"，另外两个选项的含义，我以后会找机会为大家做进一步的说明，或者大家也可以自己到MSDN上做进一步的了解。
最终，我们将得到象下面这样的一份Bug报告（参考图6），这份Bug报告中的一小部分信息是测试人员手工填写的，而它的绝大部分信息则是MTR自动收集的，象这样的一份Bug报告具体都包含哪些信息呢？我会在下一篇Blog中为大家进行详细的解释。
使用VS 2010生成的Bug报告的大致的“长相”，我想大家从上文书中应该已经多少有些了解了，现在让我们再来重温一下它的模样（参考图1）：
上面的这份Bug报告，上次我们已经提到，其中的一小部分信息是测试人员手工填写的，它的绝大部分信息是机器自动收集的。需要测试人员手填的信息，也就是报告的上半部分，我在这里就不多讲了，如果大家有兴趣，可以去MSDN做进一步的了解。今天我们主要来看看报告的下半部分，也就是机器帮助测试人员自动收集的各种信息。
首先，让我们来看看报告下半部分的第一个分页，即"Details"这个分页都收集了哪些信息。从图2中我们可以看到"Details"分页首先列出了测试人员在编写测试用例时输入的每一个操作步骤（图2中的红色区域），同时这里还标示出了在执行测试过程中每一步操作的结果（即"Passed"，"Failed"和"None"）；另外，"Details"分页还列出了每一步操作的视频链接（图2中的黄色区域），这些链接的文本显示了每一步操作录像的起始时刻，单击这些链接可以在打开媒体播放器的同时直接跳转到相应的步骤开始播放。这里需要注意的是，因为视频文件的块头一般都比较大，因此测试操作的视频录像不是默认被“拍摄”的，所以如果你希望录下测试操作的视频，在创建测试计划时还需要做一些专门的设置。
然后，再让我们来看看Bug报告下半部分的第二个分页，即"System Info"这个分页（参考图3）。这个分页收集的信息，大家一望便知，这张表不仅包含了CPU的频率、内存的大小、显示屏的分辨率等测试人员所用的测试机器的硬件配置的信息，还包括了象操作系统的类型和版本、浏览器的类型和版本这些软件配置的信息（有关浏览器的信息在这张表的最底部，因此没在图3中显示出来）。同时，"System Info"这个分页还为我们提供了程序员在修复Bug时通常比较关心的被测Build的版本信息（图3上部的红色区域）。这里值得一提的是，如果测试人员所测系统是部署在一台以上的机器上（包括一台以上的虚机上），譬如一台Web服务器和一台数据库服务器之上，那么"System Info"这个分页会为我们显示这两台机器的软硬件配置信息。
在VS 2010中，任何一份Bug报告被生成时都会自动关联导致其不幸被发现的某个或某些测试用例，这个或这些测试用例会被专门显示在"Test Cases"这个分页中（参考图4），如果我们点击这里列出的测试用例，可以直接打开该测试用例查看相关的信息。
"All Links"这个分页（参考图5）为我们提供了除测试用例之外的更多的相关信息，如有可直接转换成代码的操作“录音”（即以.uitest为后缀的文件），有基于XML的详尽的被测系统的配置信息，有基于文本文件格式以及HTML格式的操作“录音”，还有完整的操作录像（即后缀为.wmv的文件）。
最后一个分页是“Attachments”分页，这个分页是比较容易理解的，因此我没贴截图，其功能与电子邮件附件的功能类似，附件类型可以为图像、邮件、日志或其它格式的文件，我们前面截取的屏幕截图也会显示在这里。
由于视频文件的块头一般都比较大，所以测试操作的视频录像不是默认被“拍摄”的，如果我们希望录下测试操作的视频，还需要在创建测试计划时做一些专门的设置。这就意味着我们可以通过改动VS 2010为我们提供的一些设置参数来调整Bug报告的内容，也就是说，在测试过程中让机器为我们收集哪些信息、不收集哪些信息是我们可以选择的。
我们还是拿是否录制/收集操作视频来说吧，虽然在默认情况下，Microsoft Test Runner在执行手工测试的过程中不“拍摄”测试操作的录像，但如果我们确实想获得测试操作的视频信息，设置起来也是很简单的。我们只须在创建或修改"Test Settings"时，到"Data and Diagnostics"分页下把"Video Recorder"这个复选框勾选上就可以了（参考图1）。
图1 在"Test Settings"中设置是否录制操作视频
在这里，我们还会发现，其实Bug报告中由机器自动收集的每一类信息（或者按VS 2010中更正式的叫法——每一类诊断数据），我们都可以通过调整相应的设置以决定收集与否以及具体以何种方式收集，此处我们可以通过点击"Video Recorder"选项后面的"Configure"按钮来对"Video Recorder"这个"Diagnostic Data Adapter"（诊断数据适配器）做进一步的设置，如设定其每次拍摄的时长，或者选择是否保存能跑通的测试用例的操作录像（参考图2）。
我们刚才提到了“诊断数据适配器”，即"Diagnostic Data Adapter"这个概念，我们说，上面的"Video Recorder"是指一种诊断数据适配器，"System Information"也是指一种诊断数据适配器，那么究竟什么是诊断数据适配器呢？我在微软的网站上没有找到这个概念的准确定义，不过，按我的理解，它应该是一种类似医院里的体检仪器之类的东东，就像大夫是通过X光机、CT机、B超机、心电图仪、血压计、温度计等各种医疗诊断仪器来检查患者的身体状况一样，VS 2010是使用各种诊断数据适配器来测定、收集被测软件系统的各项“体检”指标的，以便在被测系统运行异常时为开发人员排除故障或者说清除“臭虫”提供客观、完备的诊断依据。
图3显示了VS 2010自带的所有诊断数据适配器，其中有我们已经熟悉的"Video Recorder"、"System Information"和"Actions"（我们以前曾多次提到的测试操作“录音”就是基于"Actions"诊断数据适配器收集的数据自动生成的），也有我们已经有所耳闻的"IntelliTrace"和"Test Impact"（前面我们曾提及的测试株连分析就是基于"Test Impact"诊断数据适配器采集的数据实现的），另外一些诊断数据适配器我们有可能是初次相识，如"Network Emulation"，"Event Log"和"ASP.NET Client Proxy for IntelliTrace and Test Impact"，以后有机会我会为大家详细地介绍下面每一中诊断数据适配器的作用和具体的设置。
最后，我想再说明一点，以上所有这些VS 2010自带的诊断数据适配器都是基于一个可扩展的数据适配器框架开发的，而这个框架的API是开放的，也就是说，如果我们觉得VS 2010自带的这八个诊断数据适配器不敷用，我们可以利用这个数据适配器框架量身定制出一个满足自己特殊要求的诊断数据适配器来。
31.JPG来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9914593/viewspace-667074/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9914593/viewspace-667074/
726
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
