说到这里，是不是觉得性能测试服务化搞得很大，有必要么？我自己搞个开源工具，或者自己写个小程序也能做压测，linux系统监控工具我也用的很熟啊。我的回答是有必要也没必要。我们得回过头来看看性能测试服务化的作用和价值：

　　<！--[if ！supportLists]-->1.   <！--[endif]-->平台化本身有投入成本，但是当用户规模很大，这个投入值得，关键要看ROI；试想一下让阿里几百号测试人员都去用LoadRunner去压测，得多少许可费啊；

　　<！--[if ！supportLists]-->2.   <！--[endif]-->标准化的流程、方法和性能数据库有利于提高效率和可回归的性能测试分析；

　　<！--[if ！supportLists]-->3.   <！--[endif]-->平台积累记下来的测试资产可以重用，进一步提升测试效率；

　　这些价值对于一个大型互联网公司是非常可观的，所以对于大型互联网/软件公司，基于自身庞大的技术团队，他们需要消费大量测试工具，这个投入非常有效。但是如果只是一个中小型公司，我不建议做这样大的投入，还不如把一套成熟的开源工具体系用好。

　　那么性能测试服务化，他的用户对象是不是局限在企业内部？如果是这样，性能测试服务变成了一个内部私有云。像性能测试这样的专业技术服务能不能推而广之，做成共有云为所有互联网用户提供服务？其实已经有很多公司在做这样的尝试，比如Compuware公司的Gomez性能测试解决方案，LoadImpact公司的在线云压测解决方案，webpagetest提供的在线页面性能测试方案。个人感觉，这样的尝试目前还是停留在性能测试玩具层面，看上去很酷，但是到底能带来多少价值，真的非常有限。这里面其实有一些问题，性能测试本身的测试方法有很多分类，有些性能测试对于环境的依赖度非常高，特别是网络的依赖。如果要在公网上搞一次压力测试，那不亚于对被测系统搞一次DDos攻击，但是考虑到网络防火墙和防DDos方案，核心应用系统还不一定能够受到压力。如果我们希望通过性能测试测出系统的容量或者定位系统的性能瓶颈，我们首先要搞定施压端和被测端的网络环境，通过分布在世界各地的施压机来向目标系统施压，变数太多：网络延迟、各级网络设备的带宽限制、网络防火墙等等。所以如果我们关心的不是终端用户体验（EUE）而是系统的服务能力，我们需要尽可能减少这些依赖因素，通过在同一个局域网中部署被测系统和施压系统来更高效将压力传递给被测系统。

　　因此性能测试服务化共有云更加可行的一条道路是和Iaas和PaaS相结合，作为IaaS和PaaS的增值服务来保证运行在云环境中的应用性能。这样通过在IaaS和PaaS环境中部属专门的施压集群可以为部署在云环境中的应用提供高效的性能测试服务。而IaaS和PaaS是面向外部的公有云，性能测试服务也可以通过这样的途径来实现公有云服务。

　　总结一下，性能测试服务化的道路可以分为三个步骤：标准化、企业版和云计算版。标准化通过将传统性能测试工具的核心功能web化，从而支持多用户、多任务和集中式性能数据管理，以此降低工具持有成本和提高测试执行效率；企业版在标准化的基础之上提供机机器、流程、监控接入接口将性能测试整合到企业研发流程之中，进一步提高性能测试效率；云计算版在企业版的基础之上提供动态机器管理、云监控服务使得机器资源利用率进一步提升，并且为外部云计算用户提供性能测试增值服务。