Pure Software vs Appliance测试工具 测试工具
因为工作的原因,我会经常去关注一些实用性强的性能测试工具。软件测试有很多的领域和方面,可能性能测试这个方面最离不开工具,基本上没有办法纯手工来做软件测试,因为你不大可能请一百个人同时点击按钮来模拟100个并发连接。所以软件测试工具在这个时候就显得比较重要,甚至软件测试的范围和深度也很大程度上也依赖于软件测试工具的能力，这也是为什么Mercury，Quest还有Spirent这种纯粹做软件测试工具的厂商可以成为年收入几亿美刀公司的原因之一吧。不过近年有很多纯做软件测试工具的厂商被一些巨头如IBM,HP收购，这可能和IT行业的另一场大讨论有关，那就是专注和大而全的问题，anyway，这些都没有否定他们的价值。
性能测试工具的出现有很长时间了，而且已经有很多的领先者，比如Mercury LoadRunner, Rational Performance Tester, Segue SilkPerformer, 还有Empirix， Compuware，Quest的产品，后面的因为没有机会试用，所以不熟悉。以上这些工具都是纯软件的性能测试工具的代表。各家的产品设计理念都不相同，基本上每家都提出了一些概念和卖点。但其实它们的主要架构都是类似的，大致可以分为以下几个方面：
1． Virtual User Generator。性能测试很多是要模拟多个用户或者client的行为，所以一个自然的起点是你要知道一个用户的behavior，这个模块的输出一般是一个client的脚本，可以独立执行完成一次操作。各家用的语言不同，大致有C，Java，Pascal等几种。Of coz都说自己的好，可能用的人还是觉得自己熟悉的好。这个话题也很有意思，当别论。还有一个问题是如何生成这样的脚本，基本上有两种办法，一是自己写，根据手册，甚至有些可以用标准的C和Java语言。二是录制，就是捕捉真正的client的一次操作过程，然后通过协议的反向解析，得到步骤，就是上面说的脚本。很多时候可能是先录制，再在上面改改。
2． Load Generator。 一个用户的行为已经有了，现在的问题是要模拟出成百上千的用户。这个可以借助多进程或者多线程的方法，单个机器的能力有限，所以很多都支持distribution的方法，可以把很多机器组织起来作为一个group来产生load。
3． Conductor/Controller。性能测试有时候像指挥一群人长跑，所以需要组织和协调，比如是所有人听到枪声就开始跑呢还是一批批的跑，好点的工具都支持压力曲线。如果跑的过程中队形乱了，你也可以大喊一声stop，让所有人都停下来，退回原点。Conductor做的事情还有很多，比如可以设定monitor和实时的数据显示。
4． Analysis/report generator。软件测试跑完了之后自然是要有结果的，一般都会提供一份自动生成的report，这些就是分析模块做的事情。好的工具应该可以提供详细的不同层次的数据分析，也有一些智能化的分析会给出可能的bottleneck。
潮流总是一阵一阵的，今年皮草明年复古。IT这个行业也是一样，最近几年的一个潮流是Appliance，简单的说就是以前卖软件，现在把软件装在硬件里面连硬件一起卖。比如一些网关安全产品，像http，email方面已经有很多了，还有Google也推出了search appliance。记得以前联想出过汉卡，还有什么杀毒卡，后面都被纯软件取代了。现在又开始有一些硬件取代纯软件的例子。由此可见很多东西都不是绝对的，要看环境了，有点适者生存的味道。关于纯软和appliance各自的优劣，我觉得是一个big topic，还有很多问题没有想太清楚，另找机会来讨论吧。
还是回来看性能测试工具领域，现在也有这样的趋势。其实上面说的性能测试，受个人眼光之狭隘，更偏向于应用系统的性能测试。因为在网络基础设施，比如交换 机，路由器和无线设备的测试方面，性能测试设备的使用由来已久，而且占主导地位。成熟的领域总是有一些厂商奠定了自己的领先地位，比如Spirent，IXIA和Agilent等等。现在的一个趋势是这些传统的网络性能测试厂商开始向应用性能测试领域挺进，唯一的解释是application load testing领域是一个很大的市场。是的，Yankee的预测是这个领域的revenue在08年将超过600M USD，所以对他们而言，跑到第七层是一个必然的方向。他们的宣传口号已经变成了“提供完整和先进的2－7层性能测试解决方案”。现在这方面已经有了一些比较成熟的产品，比如Spirent的Avalanche＋Reflector，IXIA的硬件搭载它们的IxLoad模块。上面提到的性能测试工具的四个主要模块他们都有。很多的性能测试用纯软件和appliance都可以完成，那么他们就没有分别了吗？目前来看还是有不少差别的，比如以下几个方面。
1．就client类型的支持方面，目前来看software的产品还是占优势。我想这是因为纯软件的产品一直都是关注application，在这方面有长期的积累。对标准的协议如HTTP(S),SMTP,FTP的支持两边都差不多，这些也是比较容易做到的。但是对一些应用平台的支持相对要复杂一些，比如很多software产品都支持各种数据库的性能测试，以及中间件，如BEA Tuxedo，还有ERP系统，如SAP，Oracle，除此之外，有些还甚至支持IBM Legacy系统。Appliance产品对这方面的支持目前还很少，多半集中在标准协议方面。不过这其实也不是致命伤，因为这些测试工具都是按协议来卖，可以搭配的，这也是因为买测试工具的客户也不是什么client都需要。比如有的公司主要是要测试自己的web应用系统的性能，那么他的选择实在很多。有些要测在Tuxedo上面开发的应用，可能software的产品目前是唯一的选择。
2． 扩展性。性能测试，特别是大的系统对测试工具本身的性能也是有要求的。这个很好理解，如果一个系统1秒能处理1万个请求，但是测试工具只能发起5千个，那就说不过去了。很多情况下，靠一台主机来模拟client可能还不够，这就涉及扩展性的问题，关于这个问题，两边给出了不同的solution。Software这边的答案是前面提到的distribution的方法。Appliance这边的方法还是appliance式的，很多产品提供扩展槽，你可以再插一套主机系统进去，有点像通信设备里面单板机的概念，每个板子上都有自己的CPU和Memory和network port。
3． 升级的问题。相对而言，软件的升级比较简单。Appliance这边硬件自身的升级除了扩展之外应该不是很方便，但是里面搭载的软件是可以更新的。
4． Appliance的产品提供了网络状况的测试和模拟功能，比如当前测试环境的网络状况，可以模拟出带宽小，丢包率高的情况。Software这边可能要借助3rd party的方法。这些可能对某些测试有意义，对有些而言，可能就不care了。
5． 可能因为自己产品的原因，注意到appliance有个不错的好处，那就是他们比较适合测试gateway之类的产品。这类产品测试的过程中需要关注upstream和downstream的状况，而传统的software solution基本上都是C/S结构，你得到的最主要数据是client的响应状况。我想这可能是因为这些appliance一开始就是用来测试router和switch之类的东西，所以自然前后都要看。他们把这个特点带到了application测试上面来。比如IXIA利用一台测试设备的两个端口模拟出test client和server，发给gateway然后再收回来，这样就有前后的分析数据了。Spirent把这两块分开成Avalanche和Reflector来完成。没有试用过，不过相信在report里面，两边的数据是可以sync在一起的。
软件测试工具的竞争其实是蛮残酷的，因为这些产品的客户都是十分挑剔的，而且，怎么讲，写一首皆大欢喜的歌很难。软件测试工具基本上都想一套方法一套工具适应大量的场合和客户群，但是这本身就是很难的事情，就像他们要去测的应用系统一样。这也是为什么近年很多软件公司开始做segmentation，分出enterprise，SMB和consumer。
作为产品的软件测试人员，对自己的产品使用场景很了解，需要找到尽可能适合自己产品的软件测试工具，但是很少有完全满足要求的软件测试工具。所以如果对某个客户而言，他们提供的软件测试工具有某些方面不适合造成的硬伤，那只能说遗憾。
最后有个问题，这些纯软件测试工具厂商难道就这样看着appliance蚕食他们的市场吗？我想不会，他们可能也会推出自己的testing appliance，也可能继续加强自己的优势，因为appliance有天然的优势也有天然的劣势。当然还有一种可能就是并购，到时候可能同一家就会提供软硬两套方案，说你自己选吧，然后广告改成“提供业界领先的基于软件和高性能测试设备的应用系统性能测试全面解决方案”。
文章来源于领测软件测试网 https://www.ltesting.net/