在使用与微软Azure进行交互的工具并试图衡量性能时，基本上不可能得到任何类似于公平、一致的测试。在午餐时间执行的测试运行会得的一套计时与晚上每个人都离开办公室执行的测试所到的结果可能完全不同。结果取决于你周围的网络流量，它甚至可以每天都不太同。
Cerebrata团队最近正在测试，希望提高传输到微软Azure Blob存储和从微软Azure Blob存储传输的速度，并且我们正努力获取我们要依赖的任何数据。建议解决办法：在Azure的虚拟机中运行测试，装在同一个数据中心作为我们的Blob存储。无论如何拓展想象都不完美，因为所有控制资源都被撤销，但最好从我们的办公室运行测试。通过这种方式，我们的结果不同的主要原因 - 不一致连接 - 不太可能是一个问题了，这要归功于更少到目的地的hop，以及仅利用数据中心的高带宽连接的能力。
当然，决定在微软Azure虚拟机上运行测试是一个好主意，但如果你想运行不止一次运行它们又会发生什么呢？一天中多次远程到VM以启动测试很快会变得乏味，每次你忘了启动测试，就会浪费时间。另外，如果测试仍在开发中，而且每天增加更多测试，你必须找到获取虚拟机上所需文件的方法，你不能介意每次更新时都要运行虚拟机。当这一切都已经完成时，你的结果在哪呢？在虚拟机上？那又是另一回事了！
我们知道，在一两个月里我们会每天多次运行这些测试，所以想尽可能地自动完成这个过程。但是如果已经完成了几个星期的工作，也就没有必要进行这些测试了，所以我们没有兴趣构建服务器、部署所需的Azure虚拟机或类似事件。事实上，所有的自动化都只是在VM本身，这就是我们如何实现它的。
设置VM
性能的限制因素总是带宽，除此之外并没有什么特别VM要求。在Azure中，你运行的虚拟机大小对分配给你的物理网卡（ NIC）的宽带量有影响 - 当然，你选择的VM 越大，就给你分配更多的带宽。然而，如果在同一个物理机器上的其他虚拟机不忙于使用网卡，你可能会得到一些额外吞吐量。这点需要注意，尤其是对于像我们这样的测试。
我们处于相当独特的地位，因为我们选择了指定性能的不同选项来运行为由编译时条件编译符号触发的条件化代码。这意味着，我们的VM需要能够在测试运行期间建立C＃代码，对于这一点，我们需要安装Windows SDK。使用NUnit运行测试，所以会安装这个，并且VM已准备运行测试了。在这一点上没有什么是自动化的，但我们很快会得出结果。
收集测试结果
开始时，每个测试的输出都会写入到控制台，并通过管道输送到命令行上的文本文件（如果需要的话）。这是不会在自动化时进行，这也正好将结果留在虚拟机上，这将意味着在某些时候手动获取它们。第一步是使每个测试结果写入到文件，以及将输出写入到控制台，所以
每次测试我们仅得到一个结果文件。这仍然将文本文件留在VM上，所以我们决定将这些文件上传到Blob存储，包括确定它们的测试名称和日期。使用免费的Azure资源管理器工具，现在我们可以访问所有结果文件了，即使虚拟机被关闭或摧毁，这基本上就像这些文件在本地计算机上一样。
已经取得进展，但看完上百个（可能是上千个）全是计时的文本文件并不现实。很快变得非常繁琐，所以需要做一些处理。对于这一点，我们编写应用程序，它可以解析每个文本文件，并且先合并结果相同的测试，然后算出定时的平均值。这就能给了我们每个测试配置的平均值并传输文件大小，它采用升序排列以易于阅读的格式呈现选项的最高性能设置。这些汇总文件也会被上传到Blob存储，并且只要结果-分析应用程序运行，就会更新这些文件。
我们希望经常看到的最后一部分资料是特定配置选项或设置选项的计时分布。这是通过在此分析个人结果文件取得的，而这次是将计时数据导入Excel ，这将是我们定制图表的基础。同样， Excel文件被上传到Blob存储以便更具弹性和易于访问。
这个在每组测试运行结束时运行的结果-分析应用程序，会给我们个人结果文件以便深入查看性能运行、排好序的所有运行的总结，和用于制图的带有数据的电子表格 - 所有这些在Blob存储中都很容易实现。
自动化
这可能是整个过程中最无趣的部分，因为我们保持事情简单化，只使用了包括Windows计划程序的批处理文件。如前所述，虚拟机会建立测试和库，所以会呈现源代码。该批处理文件将循环通过不同的配置选项，使用指定编译符号构建每一个选项，然后运行测试。完成这个循环后，会构建并运行结果处理程序以产生我们的汇总结果文件和Excel电子表格。
获取代码更改
初始设置获取我们的基准测试运行是相当快的，而且鉴于该测试需要几个小时才能完成，我们的数据愈多越好，我们向尽快开始运行，并一直添加不同的配置。我们仍然需要解决的问题是在每个测试运行之前如何使用最新的源文件更新VM 。远程进入VM以检查先前的测试运行已完成，和从本地机器手工检索源文件，会使自动化的其余部分变得几乎无用。
幸运的是，这些性能测试的源代码存储在GitHub中，明显VM已经接入互联网，所以我们可以很容易地摧毁变化。要自动执行此，会创建另一个批处理文件创建，并且它将使用Git shell来摧毁最新变化和运行先前创建的批处理文件来使测试继续下去。只要没有修改第二个管理拉的批处理文件，我们就还没有登录到虚拟机，而测试始终使用最新签入的变化运行。
切换Windows计划程序来启动这个新批处理文件很容易（而不是启动旧文件），我们有关于如何安排和管理测试周期方面的选项。我们可以添加一个检查，以确保前面的测试运行完成后才在此启动计划程序，我们可以选择只按计划运行，或者我们可以选择在先前运行完成之后就尽快再次运行整个过程。
等等，这种环境并不代表我们的用户群
自动化已完全设置好、运行良好，并且准备好结果。块大小越大和并行块上传数量越大能见到最快时间很快变得很明显，但是这对于有巨大带宽的虚拟机来说不足为奇。这显然并不代表我们客户的一般使用情况，因为他们大多是从当地网络传输文件，而这是不能和我们的Azure虚拟机相比的。
我们希望Azure管理工作室能够快速传输文件，而不仅仅是为用户提供精彩的连接。我们需要在有限带宽的环境中运行我们的测试，来看看我们的调查结果是否一样。为了实现这一点，我们使用Windows的网络仿真器工具包 - 一个软件仿真器，可以对带宽、分组丢失、错误、等待时间等等进行设定。它不是最漂亮的应用程序，但它是非常有用的。将它留在VM上运行，我们可以在指定带宽和网络环境下运行测试，以更好地模拟客户的真实环境。
总结
这是让一些自动化测试在Azure中运行的快速简便方法，它能工作的很好，主要是因为只会需要它一两个月。鉴于我们只是运行几台虚拟机一两个月，费用不是一个真正的问题，所以我们觉得没有必要在非活动期间关闭虚拟机。我们可以在测试完成后通过使用批处理文件关闭虚拟机来很容易实现这点，然后使用我们构建服务器运行PowerShell脚本来重新启动它，为下一轮测试做准备。
工作已经在进行了，现在，我们也可以利用新的微软Azure自动化功能，该功能目前在预览中。
同样，因为这是长期测试或分布在多个虚拟机上的测试，我们必定会涉及到本地构建服务器并写入基础设施以按需创建虚拟机、远程运行测试和以图形方式显示测试结果。随着微软Azure虚拟机上新的可选VM代理和其他Puppet和Chef的扩展，还有很大可能在Azure中创建广泛的自动化测试基础设施，特别是如果你投资你知道的东西时，你就要使用它一段时间了。