云计算平台选型测试方案1目录1.测试目标 (4)2.测试内容 (4)2.1.需测试产品功能 (5)2.2.重点关注测试项目 (5)3.测试计划及时间安排 (6)4.测试环境 (7)4.1.测试环境拓扑图 (7)4.2.IDC运行环境 (7)4.3.W INDOWS A ZURE运行环境 (8)4.4.阿里云运行环境 (8)4.5.软件环境 (8)4.6.测试工具 (8)5.测试用例 (9)5.1.应用的连通性测试 (9)5.1.1.主页连通性测试 (9)5.2.应用系统及软件性能测试 (10)5.2.1.应用软件标准性能测试无故障压力测试 (10)5.2.2.应用软件标准性能测试响应时间测试 (10)5.3.应用系统及软件最小硬件需求测试 (11)6.测试结果 (12)26.1.连通性测试 (12)6.1.1.故障时间及可用率 (12)6.1.2.平均响应时间 (13)6.2.性能测试 (16)6.2.1.压力测试故障数量和响应时间变化 (16)6.2.2.最小硬件需求测试 (19)7.企业级服务比较 (21)8.总结 (23)31.测试目标出于企业业务发展的需要，以及更高的IT服务水平的要求，XXX计划将公司的一些业务应用迁移至公有云平台，构建企业云架构。
这个平台必须具有：•更好的弹性•更高的可用性•更高的性价比•企业级的基础设施服务本文档根据XXX的以上要求，制订了一套可行的测试方案及测试计划，对各种基础设施平台进行了深入的测试。
并基于共同讨论，形成了具有实际业务参考意义的测试样例及科学的测试方案，为XXX日后云平台的建设提供客观的事实依据。
2.测试内容本文档为XXX云平台建设测试方案的相关信息。
作为IT人员前期技术调研一份参考文档以及测试过程中的基准指导。
本测试基于三个平台进行：•目前的IDC机房•微软Windows Azure云平台•阿里云平台本测试将XXX的XXX应用以相同架构分别部署于三个平台，通过对比三个平台环境的连通性、可用性、主机性能、网络性能，以及企业级的服务，达到测试的目的。
此外，本文还针对各个平台提供的一些企业级的服务做了比较，以便更好、更快速地帮助XXX在云平台上实现一些企业级的服务。
42.1.需测试产品功能•平台基础功能测试•平台高可用性测试•应用系统及软件兼容性测试•应用系统及软件连通性测试•应用系统及软件性能测试2.2.重点关注测试项目•高可用性应用系统使用两台前端网页服务器，在任何一台服务器意外宕机时，都不应该影响整个网站的访问，保证业务连续性。
企业级的应用所部署的平台的服务水平协议(SLA)中，可用率是最关键的指标，一个平台是否稳定，是否能提供24*7的在线服务是所有指标的重中之重。
•性能在部署的应用系统上进行压力测试，达到100-200的并发量，测试Web请求返回的错误数量和压力下的响应时间，以保证业务性能要求。
我们用一下公式大致将并发量换算成每日PV。
每日PV = 并发量* 60 * 60 * 24 * 1.2（系数）。
由此得出100-200的并发量所对应的日PV为1000万至2000万左右。
这相当于一个较大的在线活动网站的日均访问量。
53.测试计划及时间安排本次测试计划在XX日开始，至XX日结束。
同时从5个监测点测试三个平台可能会对测试工具造成比较大的压力，而对测试数据的准确性产生影响，因此我们选择分开测试三个平台。
为了减少互联网流量峰谷对测试的影响，我们对每个平台的连通性连续测试24小时，时间为0：00到24：00。
以下是测试时间：64.测试环境4.1.测试环境拓扑图4.2.I DC运行环境74.3.W indows Azure运行环境4.4.阿里云运行环境4.5.软件环境4.6.测试工具连通性测试：HTTP/HTTPS Connection Tester8HTTP/HTTPS Connection Tester是一款国外开发的小工具，他通过定时访问一个http/https的网址记录页面的响应时间。
我们将通过从不同监测点运行此程序24小时，以达到求平均值的目的。
压力测试工具WebLoadwebload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。
我们使用脚本，模拟客户登陆、查询、浏览、下单的过程，对系统进行全面的压力测试。
5.测试用例5.1.应用的连通性测试5.1.1.主页连通性测试95.2.应用系统及软件性能测试5.2.1.应用软件标准性能测试无故障压力测试5.2.2.应用软件标准性能测试响应时间测试105.3.应用系统及软件最小硬件需求测试116.测试结果6.1.连通性测试6.1.1.故障时间及可用率我们将24小时的故障时间及次数统计如下，用故障时间换算出可用率12可用率是企业级应用最关键的标志之一。
它标志了这个应用是否能够提供24*7的服务。
它也是一个托管平台服务水平协议（SLA）中最重要的一点。
许多平台都宣称自己有99.9%或99.95%的服务水平协议，但实际不尽然。
可用率最好的是Windows Azure平台。
在其上部署的应用在5个监测点的可用率都达到了100%，微软官方宣称Windows Azure的月SLA达到了99.95%，并且提供了财务保障；阿里云表现其次，但其官方宣称的年SLA也只有99.9%。
最差的是IDC，从移动监测点所监测到的系统不可用时间竟然超过了2个小时，接近10%。
从企业级的应用角度出发，这个数字是不可以接受的。
这也标志了云平台对比传统IDC 机房最大的优势。
6.1.2.平均响应时间1314从上图可以看出IDC的响应速度最快，Windows Azure和阿里云相似。
为什么在云端，响应时间会比较长呢？我们通过一个快照来看一下整个访问时间的构成。
IDC响应时间构成Windows Azure响应时间构成阿里云响应时间构成15从上述二图可以看出，IDC的响应时间中建立连接和下载花去了一半的时间，服务器计算则用了另一半的时间。
而在公有云平台，建立连接和下载所花去的时间非常少，大多时间都用于了服务器计算。
我们通过监测工具得出的数据显示，得到这个结果可能由于在与IDC和云平台上部署的版本不一致。
IDC平台上的CSS/JS是有缓存优化的，但云平台上的两个版本并没有优化过。
6.2.性能测试6.2.1.压力测试故障数量和响应时间变化我们在三个平台上对相同的应用(VIP Room)进行了压力测试，由于云平台上从100至200并没有产生任何的502错误，我们将并发数从100逐渐升至400，直至其产生502错误，根据每个记录点记录了两组数据。
如下所示：•502错误数量16将以上表格绘图如下，X轴代表并发数，Y轴代表502错误数量，错误数越小越好：从上述数据可以看出，在三个平台中，IDC的状况是最不稳定的。
从测试的一开始，并发量还比较低的时候就已经开始有不少的502错误，说明平台的稳定性以及承载能力不够高。
而云平台在并发量300多以后才出现502错误，就测试前提VIP Room并发量100到20017的需求，云平台的能力绰绰有余。
在测试的末端，阿里云的错误数量开始直线上升，Azure表现平缓一些。
•响应时间将以上表格绘图如下，X轴代表并发数，Y轴代表响应时间，响应时间越小越好：18从图中看出，在压力测试下云平台的响应时间会比IDC高一些，但较连通性响应时间测试与IDC的对比有所好转，可能是公有云服务器启用了缓存的原因。
总体来说，Windows Azure会比阿里云压力测试下的响应时间要好一些。
6.2.2.最小硬件需求测试接下来，我们希望降低服务器的配置，继续对相同的系统进行测试，以便得出能够达到应用要求的最小、最经济的主机配置。
因为物理机的硬件配置无法修改，所以我们无法修改IDC的机器配置。
阿里云的包年、包月云主机配置界面中，无法修改配置，虚拟机只能付费升级，而不能做降级。
我们只能选用Windows Azure进行测试，因为Windows Azure的虚拟机配置页面中提供了非常便捷的机器类型修改方式。
如图：我们依次减小虚拟服务器的大小，分别对大型、中型、小型进行测试，得到每个型号的虚拟机在并发压力下的502错误数，以找出无错误的最大并发数。
测试数据如下：19400 30 331 428 420在Windows Azure平台上我们测试的四种机型：小、中、大、特大，在并发数量从100-200的情况下都顶住了压力，保持了零错误数。
也就是说，在应用对并发要求100-200的情况下，选择中型甚至小型的服务器即可达到需求。
但考虑到响应时间可能会不如大型或超大型20机那么的快，用户还是需要根据自己的需求选择机型。
当然，如果希望得到更快的响应速度，在预算充裕的情况下，还是可以使用大型或超大型机器以提升用户体验。
7.企业级服务比较除连通性和性能指标外，XXX还希望托管平台提供一些企业级服务，以满足未来业务发展的需要。
以下，我们对XXX所需要的和今后可能需要的一些企业服务在三个平台的实现情况作了对比。
21从对比中我们可以看到，IDC机房只提供了服务器托管和网络接入的基础设施服务。
在企业级服务上，几乎没有任何的作为。
各云平台都提供了一些企业级的服务。
在针对企业级服务中Windows Azure脱颖而出。
它提供了几乎大多数企业级所需要的功能，并保证了良好的服务水平协议。
8.总结基于上述的测试数据以及功能的比较，我们认为微软的Windows Azure公有云平台能够更好的满足企业业务发展的需要，达到更高的IT服务水平。
使用Windows Azure作为XXX构建企业云架构的基础平台，帮助XXX打造可靠的、高可用的、具有弹性的企业级互联网应用。
23。