对软件开发和测试人员来说，最危险的事情之一莫过于被“虚假的安全感”哄骗。举个例子，应用程序的功能和性能水平在预生产阶段往往已经达到预期，但在真实用户环境下就可能崩溃频出、故障不断。
　　所以我们讲，是骡子是马，拉出来溜溜。传统压力测试，在真实生产环境中，压力小还好，一旦真实负载一起来，问题就多了。
　　同样的，如果你的团队有任何一种性能测试策略，那么很有可能你正在进行负载测试。然而，在你的负载测试中，你可能无法真正的模拟用户在真实世界的行为。
　　用户体验成就产品，也杀死产品。
　　忽视负载测试的真实性，投入生产中会造成大量的性能问题，但用户不会等。如果你不执行精确的真实的负载测试，必然会面临损失收入，影响品牌和降低员工生产力的风险。
　　解决方案：基于云的负载测试。
　　对负载和性能程序来说，云提供了两个主要的优势来帮助测试团队更好的模拟真实行为：即时基础设施和地理位置。基于云的负载测试降低了总拥有成本，增加了灵活性，并让测试人员理解第三方组件的影响。
　　什么才是好的云压力性能测试工具？
　　所以如果你在考虑采用基于云的负载测试解决方案，你得要选择一个基于云的负载测试工具，并确保它具备以下条件：
　　1.集成了云平台
　　一定要考虑到工具与云的集成程度。如果你选择了没有集成一个或多个云平台的解决方案，你需要手动处理好几个步骤，如学习你采用的每个平台是怎样工作（包括它的局限性和约束）和创建的，还要维护和访问你想要使用的机器。
　　基于云的负载测试解决方案应该提供与云的集成，以简化和加速使用云基础设施所需的步骤。你选择的工具还要满足快速配置，对安全性的简化，对可扩展性的改进，还要有一个统一的接口，良好的的测试体验和及时的结果报告。
　　2.进行实际测试的能力
　　虽然基于云的负载测试，在许多情况下，比在实验室中更真实，但仅仅迁移到云是不足以确保最真实的测试的。要真正给你的基于云的测试添加一个真实的层，你必须考虑到真实用户体验的带宽限制。
　　基于云的负载测试工具应该：
　　虚拟网络：你需要在有限的带宽，延迟和丢包环境下来验证虚拟用户下载应用程序的速度。对移动用户来说，在各种网络条件下进行测试是特别重要的，因为不同于台式机和笔记本电脑用户，他们受到有限的带宽，延迟和数据包丢失影响的比率更大。
　　并行化的要求：现代浏览器检索静态资源时有并行处理HTTP请求的能力。这些并行请求需要与服务器更多的连接，并且可以延长响应时间。如果基于云的负载测试工具，不能处理并行请求，那也就不能产生最真实的性能测试。
　　3.统一的实验室测试和云测试
　　基于云的负载测试是有优势的。然而，它不应该取代实验室测试。相反，两者应该串联使用，以测试内/外部防火墙，并验证任何用户的应用性能，无论设备、位置、网络或带宽的限制。
　　要找一个允许在实验室测试和云测试中复用脚本的单一的解决方案。这种类型的工具将节省你的时间和精力，同时能帮你找出在云负载测试中出现，但在内部测试中不会出现的性能问题。最终，一个统一的解决方案将降低授权和培训成本，并允许测试工程师在这两种类型的负载测试中使用他们现有的技能。
　　4.分析、监测、报告
　　创建和运行基于云的负载测试只是方案的一部分。测试运行后，需要了解你的应用程序在负载下的表现。要确保应用程序满足预定的性能要求，分析工具是必需的。
　　采用基于云的负载测试工具，你应该能够轻松地分析收集到的数据，并创建描述测试应用程序性能的可操作的报告。在明确问题根源上，确保你的工具还包括一个全面的监测系统，来了解在负载测试中你的应用在基础设施上发生了什么是至关重要的。
　　5.支持网络技术
　　这个要求很明确。无论你是使用 Adobe Flex ，微软的 Silverlight ，实时消息协议（ RTMP ）， Ajax Push 技术， WebSockets ，等等。你需要一个有内置支持你采用技术的工具。没有这个支持，有效测试你的应用程序的性能几乎是不可能的。
　　云为团队提供了提高负载测试规模和真实性的机会，同时节省时间并降低了整体成本。为了满足用户在应用性能方面的期望，基于云的负载测试是必须的！记住，简单地迁移到云是不够的，成功测试的主要驱动力，还是在于你所使用的工具以及怎样合理地使用云技术。