您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 性能测试 > 正文

云测试的两种类型——云与性能测试

发表于:2018-03-23 作者:郑达夫 来源:51CTO

近年来,随着云计算技术的发展和各种诸如AWS、GCP、阿里云等云平台的日趋成熟,越来越多的的用户选择把系统搭建在云端,因此云测试的概念随即产生。

云测试看字面意思就是关于云计算、云平台的测试,而它大体又可以分成两种类型:测试云(Test Cloud)和用云测试(TaaS)。 测试云,顾名思义测试的目标是云,测试者通过设计测试去保证云平台本身和部署在云端的应用正确性。而用云测试是指利用搭建在云端的测试服务 -- TaaS (Test as a Service)来进行更高效的测试。云计算有着超大规模、虚拟化、高可靠性、高可伸缩性和按需服务等诸多优点,但平台的特殊性也给测试带来了新的挑战和机遇,其中性能测试受其影响颇深,本文旨在针对云测试的两种类型探讨云与性能测试。

云与性能测试

测试云

云环境最大的特点就是能够通过高伸缩性按需为用户分配资源,也正是因为这个特点,我们对于基于云平台的性能测试与普通系统性能测试的最大的区别就是要考虑测试云服务的伸缩功能,因为云服务的伸缩功能可能存在以下风险:

  • 云服务的auto scaling 不能执行
  • Auto scaling会造成服务崩溃
  • Scaling up时资源不足

因此我们设计的测试应该包含以下内容:

测试目标

  • 确认auto scaling能够根据所制定的策略执行
  • 确认auto scaling能得到相应的资源
  • 确认云服务的性能能够满足不同的压力变化

测试方法

给云端系统一直施加压力到性能边界值后继续加压,随后给系统减少压力,观察系统在边界值前后的性能表现。

测试技术

  • 利用load profile进行施压
  • 边界值分析
  • Process cycle test

测试步骤

  • 给系统施加压力,压力不会超过性能边界值
  • 维持压力一段时间,确保系统在压力下的错误率在可接受范围内
  • 给系统施加更多的压力,使系统超过性能边界值,我们期望系统会自动scale up
  • 系统scale up之后,我们期望response time会下降,但是不会触发scale down
  • 维持压力一段时间,确保系统在scale up后一段时间内的的错误率在可接受范围内
  • 降低系统的压力到性能scale up前的状态,确保系统可以自动scale down
  • 系统scale down之后,我们期望response time会有上升但不会重新引起scale up

期望结果

TaaS

在TaaS出现前,性能测试一般都是在本地的测试环境中通过几台电脑对被测环境加压进行的,在这种模式下,测试环境的搭建和维护不仅要耗费大量资源,而且测试环境由于并不能完全模拟真实生产环境以至于测试结果存在一定的局限性。而云计算出现后,一些基于云端性能测试服务(CLT - Cloud Load Test)相比于本地的性能测试展现出了很多优点:

  • CLT更简单,大多数情况下, 云端的资源更好管理,环境更容易搭建,用户只需设置简单的一些参数或者提供简单的测试脚本就能在云端执行测试。同时,很多CLT工具允许用户把不同性能测试工具的自动化脚本如Gatling,Jmeter,Selenium直接移植使用,为用户节省了二次开发时间。
  • CLT工具可以提供更多的load generator,压力测试中用户通过在云端启动load generator对被测系统进行施压,因为在云端可以调用资源体量巨大,因此用户可以完全模拟生产环境中可能面对的超大压力。
  • 测试成本低。CLT提供的测试服务是按照云端机器的运行时间进行收费。在没有测试需求时,用户并不用为机器的运行和维护买单,大大降低了用户实施性能测试的成本,为一些没有大型长期性能测试需求的企业节省了许多开支。
  • CLT提供的测试硬件资源大多分布在全球不同区域,在进行性能测试时,用户可以根据可能的实际情况选择不同区域的机器定制化的为被测系统加压,所得的测试结果由于更接近真实的网络情况而更加准确。

 相关文章