3. 数据和sample的产生

  这个和工具有一定的关系,但是我还是想把它单独列出来,因为这是一个不一样的挑战,这个和系统的需求和应用有关。关于这一部分,做过性能测试的应该都比较清楚,问题和方法也比较类似,只是这里有个规模的问题。

  4. 监控

  前面也提到这个问题,或者换个角度是如何知道有没有出问题,哪里出了问题。前面提到的一个业界广为使用的监控平台也可以使用,但是可能还不够,因为那些默认的都是从系统的层面来看有没有问题。而后跑的都是应用,有意义的也是应用,所以也需要从应用的角度来看问题。比如系统的资源应用到一定的程度后,应用(比如web service)看到的响应时间很长,或者有很多的time out error,甚至去不到正确的数据,这些如果只是监控机器有没有挂掉,资源使用率是不是正常是很难看出来的。

  引申来看,这个和前面两点也有关系,如果我们从应用层面,而不是纯粹的跑CPU和IO stress tool,能发现这方面的问题。

  从上面个人的体会你会发现,其实这些也不是全新的东西,只是老问题在新的环境下的展现,因为某些方面被放大而使得问题凸显。

  下面我想从另外两个角度来说说自己的一些看法,个人观点。

  对测试工具厂商而言,也是一种挑战。

  从上面的分析和我的体会,我觉得对于这样的系统,哪怕只是稳定性测试,需要的不只是一套工具,而是一种咨询+实施的整套服务,而传统意义上,测试工具厂商们提供的都是一个工具和简单的培训。比如提供Loadrunner,SilkPerformer等传统的应用层测试工具的厂商,还有 Spirent,IXIA,BreakingPoint等以硬件设备为主的厂商。他们的工具可以提供很多协议流量的模拟,但这只是一部分,如何部署,如何扩展,如何监控,都不是单纯靠这些工具能完成的。

  另一方面,他们也会面临开源测试工具的挑战。在云计算系统快速发展的过程中,相应的测试工具也在跟着发展,像JMeter和apache一起成长的故事一样。这样的测试工具如果伴随着云计算的平台一起成长,那么在很多方面会更加适合云计算的特性,不如分布式和可扩展,以及多个工具的松耦合。希望会有越来越多的这样的工具出现。

  对测试人员的挑战和机会

  挑战是需要更深入的了解系统的运作,否则根本无法进行测试。而且要测得比较深入的话,需要对相关的技术有一定深度的了解。以前也需要了解,但是在了解不多的情况下也可以进行测试,拿出看起来还可以的测试结果,但是对于云计算的系统,如果不深入的了解根本没法进行测试。

  因为很多时候需要的是一整套方案,一个project,包含资源的组织,测试项目的协调,而不是一个工具和一个设计文档。

  如果说到机会的话简单来说那是测试会变成一个更需要专业技能和更有value的工作。

  后我在想一个问题,在这样的需要一整套方案的情况下,会不会有专业的测试服务作为独立的business model产生?国外其实不少,很多测试大牛们同时也在开公司,提供咨询和测试服务。国内似乎目前还很少。