导读
本为转自,本人之前博客园上的原创。先从云化说起,再谈谈云化形态下,除了常规的功能测试,云化的测试,还需要有几个必须要 get 到的硬核指标,最后在分别详解这些关键点硬核指标是什么,和如何测试呢。这是个值得深思的问题,希望所有测试人都 get 到这些,且比贴子说提到的做得更多,提炼出更多 check point。

先回顾一下云化的掘起之大势

前两年 oracle 裁掉整个中国研发中心,正闹得沸沸扬扬,一关键原因是,oracle 受云计算等新兴技术冲击,自身业务成长乏力甚至下滑,所以更关注成本控制,从而进行战略性人事调整,为云计算腾出更多资源;今天,阿里云已超越微软 Azure,成为仅次于亚马逊 AWS 的世界第二大云计算公司,10 年前在百度和腾讯都不看好的情况下,马云认为云计算是未来,每年投入 1 亿,不知道猴年马月咸鱼翻身的情况下,马云就这样投了王坚的阿里云 10 年,最后真的把马化腾说要 1000 年才做成的事给办了!但是当时全中国没有一家公司愿意投入云计算这种 “虚无缥缈” 的事业中,最艰难的时候,80% 的工程师因各种原因离开了阿里云,十年前的王坚博士,在很多人眼中就是一个不折不扣的 “骗子”。

早期云厂商,主要提供的云资源偏重于 iaas 层,当前随着云计算的深入发展,从 iaas,到 paas ,serverleess 加容器技术,已经成为云厂商标配产品,云化是一个不可逆转的趋势,已被大众所接受,当然受一些非技术因素的限制或是一些历史包袱的限制,混和云,多云和公有云一道将长期存在。越来越多的公司把服务放在云端,小公司可能只是仅仅把服务搬到云端(也就是把先前的本部署,搬到云端),实际上这是不真正的云计算,当然容灾备份能力有质的提升,saas 厂商,或是大厂商,会在云厂商的 pass 平台上,构建一个胶水层, 整合 PAAS 和 SAAS 形成自己的云管理平台,透明实现弹性计算,横向扩展和可视化运维监控等非功能性的管理需求。

云化测试这些非功能性必测的硬核关键点必须 get 到

这些非功能性硬核关键点和云计算的特性有着必然的关系,同时也和服务的可靠性,服务的计量和治理有着密切的关系。简单来说你要保证你的云服务的可靠性,可用性,可管理性,必须具有一些云化后的非功能性指标,因为你业务功能再好用,不可靠,对用户来说是没有保障的,如下 8 个硬核点就是云化的非功能指标,后续一节再分别讲述,这些硬核点的的定义以及如何来测试这些点,特别是第 1,第 2,第 3,这三个缺一不可,否则你的软件只是搬到云端,并不具备任何云计算的特性,也就是假云。

第 1 弹性,也叫自动伸缩;

第 2,服务无状态;

第 3 ,多租户支持;

第 4,故障转移/隔离;

第 5 ,服务限流保护;

第 6 ,应用安全;

第 7 ,调用链追踪,

第 8 ,可视化服务治理(可观测,可自动健康检查,服务优雅关闭等)

用一个示例来说明 8 个硬核点以及测试方法或手段

下图是一个在 aws,建一个 VPC 且通过 VPN 和本地服务组成一个混合云的网络架构图,

创建 4 个子网,分别用于部署:租户注册 Web 程序、数据库、进销存 Web 程序、进销存 App 程序;,为了实现高可用性,每种类型的子网按照可用区各创建 a、b 两个。

租户注册成功后,调用 CloudFormation 接口,自动部署的云进销存业务系统。(实际是物理隔离)

再回到前述 8 个硬核指标

第 1 弹性,也叫自动伸缩

说起弹性,先从常说的云服务器,ecs 说起,它就是 Elastic Compute Service 的缩写 ,是一种处理能力可弹性伸缩的计算服务器,这是从 IAAS(更偏硬件资源:CPU,内存,磁盘,网络)层来实现弹性,这解决了硬件或是底层资源的弹性;实际从提供云服务的软件层现来看,还要有软件自身的弹性也就是 saas 或是 paas 层的弹性,例如,需要根据时间或是其他的策略 (基于流量,或是硬件资源的特定基线) 横向扩展,如高峰期,挂号服务需要 10 个节点才能保证支撑高峰期的并发量,非高峰期,再减少挂号服务节点,腾出计算资源做其他事情。在云上,实现集群节点的扩展是很简单的事,配置好扩展策略即可。测试的时候, 必须把弹性作为一个 check point ,如何验证,从前面其定义就能明白,这里就不再重复了。现在问题来了,动态扩的服务,如何让集群感知,且可用呢,请看如下第 2 项

第 2,服务无状态;

接上一个问题,动态扩的服务,如何让集群感知,且可用呢?让集群感知有两个办法,一是服务在横扩的时候,向 ELB(负载均衡)动态注册 (如果扩展了节点,需要手动配置并重启负载均匀相关组件,这不叫弹性),或是通过服务发现注册组件来实现,这有很多成熟的技术,这里就不多说明,重点是,新横扩出来的服务,加到集群后,要让他能对外提供服务,这要求服务是无状态的 ( 比如会话 session ,或其他上下文,不依赖服务所在属主容器,如 tomcat ,jetty,weblogic ,iis 等),否则某个请求被路由到新扩的服务节点时,可能会为因为会话或上下文的问题,导致服务在业务上不可用。测试的时候, 必须把服务无状态作为一个 check point,如果服务实现方,是通过在负载均衡上通过 “ 黏住” 策略,来实现会话共享,的话,有一个大问题,当服务节点减少,或是某些服务节点挂掉时,之前这些服务节的服务的客户端后续的请求,转移到其他节点,session 就会丢失,通常做法是,把 session 或上文下外置在服务线程所在容器 (tomcat ,jetty,weblogic ,iis 等) 之外,如 memcache 中,redis 中。

如何验证这个无服务的检查点呢?假定是一个 Web 程序,通过关闭单一节点,再重启检查,是否为同一个 session。测试这个完全可以在非云环境来验证,用一个单单一节点来测试(非集群模式),比如先登录,进入到某页面,且准备做某个对 session 有依赖的操作,这时,停下正要操作的功能,先停掉这个节点,然后重启这个节点,,重启后再在之前登录的页面上,接着做这前的作操作,并没有提示要重登录,或是 session 过期,操作成功,可以验证;当然也可以用两个节点来验证 (集群模 式),每个节点上,放两个相面的页面,在上面,打印出 session id ,以及节点的名称,先请求这页面,记下打印的 session id 及节点名,关掉任意一个节点,再刷新这页面,看看打印的 session id 一样不,如一样,只是节点名变了,说明服务是无状态的。还有其他方法,这里只是抛砖引玉,提供一下思路。如纯后台 API ,只要检认证信息是否过期,或是是否是同一个认证信息。

第 3 ,多租户支持;

既然是云上的服务,必须要求不同的客户(租户/单位/组织)都能使用,且互不影响,实现多租户,通常有两种隔离方式,逻辑隔离和物理隔离;逻辑隔离指,大家其用一套系统,只是在数据库层在表中加一个字段,数据所属租户;物理隔离,这每个租户单独部一套系统。测试的时候, 必须把多租户支持作为一个 check point,测试方法,通过对隔离的阐述,自然就知道如验证,支不支持多租户,以及是以什么方式隔离。上面示例中,租户注册成功后,调用 CloudFormation 接口,自动部署的云进销存业务系统,这实际是物理隔离。

第 4,故障转移/隔离;

云服务,一定会有出故障的时候,为了保政故障产生的影响最小,必须有应对故障的策略,故障转移也分两个层面的,,一个是 IAAS 层的,一个是业务服务自身的故障转移。如整个系统宕机,或是有故障,利用镜像,自动重新实例化一个实例,只是网络属性未变,这是 IAAS 层面的,在 PAAS 看来,实际是和之前是无差别的,相当于,传统方式下,快速启用冗余或备用的服务器、系统、或者硬件接替它们工作;另一个是软件层面,业务服务系统,在服务不可用时,支持的重试逻辑,同时支持重试,就要求保持幂等性(简单说,对同一个数据做同一个操作,做一次和做 N 次,结果是一样的),或对出错的服务进行隔离,不隔离会引发雪蹦效应,或是采用服务降低的错施。一句话,测试的时候, 必须把故障转移/隔离作为一个 check point, IAAS 层的转移,只需向云厂商确认即可,基本上云厂商这层面都已实现,软件方面的故障处理,需要根据隔离策略来执行相应的测试,细节具体根据具体应用再详查,主要是不要漏过这个测试点。

第 5 ,服务限流保护;

既然是公有云,面向的是所有你的客户,某些情况下,访问量会爆增,或是受到恶意的访问攻击,这时服务的可靠性,隐定性也必须得到保障,通过对并发访问/请求进行限制或者一个时间窗口内的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务或者排队等待,从而使服务不会引过多的访问而崩溃,这就是限流。

测试方法,通过压测,或是增加到并发量,到系统支持的极限后,系统有没有因访问量太大而崩溃。测试的时候, 必须把服务限流保护作为一个 check point

 第 6 ,应用安全;

服务放云上,面向整个互连网,除了要应对恶意的攻击,还要防止服务器被劫持,还要保证数据安全,和授权内访问等等,安全是一个很专业的一个方向,测试的时候, 也必须把安全作为一个 check point, 测试人员在这方面,只能做一些常规的安全测试,如 SQL 注入,XSS 跨站攻击,敏感信息是否明文传输, API 的访问是否要通过验证,一些等存级别高的业务,还需要双向认证,甚至实名认证等,其他的则需要请专业的安全公司进行全面的安全测试,他们能扫描出系统存在的安全漏洞和不安全的因素,并给出好的整改建议。

第 7 ,调用链追踪,

这要看服务是否是一个分布式应用,分布式应用中,系统存在互相调用的情况,形成一个 调用链,通常一个请求,会引发 A 组件,调用 B,组件,B 组件调用 C ,C 调用 D,可能还有更长的调用链,实话说,调用链追踪,有点偏向于运维,在测试时,分布式环境下,不借助调用链追踪有些问题根本没法定位,比如说,某个请求出错了,实际是错调用链的哪个节点上,或是某个功能很慢,慢在哪,不借助于调用链追踪,你都没办法跟程序,就算让研发自己打断点,也要搞死人的,分布式加集群,同一个服务,每次调用时,调用链都可能不一样。上云的应用,通常是分布式用,作为测试人员,也有必要把调用链追踪作为一个 check point,才能在分布式场景下,提出定位更准,更专业的问题,而不只在 BUG 的表像上。开源调用链追踪有 zipkin,pinpoint,skywalking 等。调用链跟踪需要研发那边来集成,测试这边要 get 到这个点和会使用。下图是昨天用 zipkin 的一个截屏示例

第 8 ,可视化服务治理(可观测,可自动健康检查,服务优雅关闭等)

服务治理,也是偏运维的东东,他自身的定义,各位可以自行百度;在这里,我只简单场景上来说明,服务治理的大概意思,你的服务在云上,可靠性要有保障,主要在于预防,不能抓瞎,真正问题发生了,就炸锅了,需要通过可视化的方式,观测到服务的状态,健康状态,流量情况,响应速度,并发量,资源使用情况等,并根据于些,采用自动或半自动的方式启动弹性扩展,或是采取隔离,熔断等措施,以保障服务的可用性。在 devOps 大行其道的当下,测试人员向运维多靠一点不是坏事,会给测试提供更多灵感和带来更多测试手段。云上的服务。服务优雅关闭,顺带提一下,要关闭某个服务时,正在服务中运行相关业务线程会同进被关掉,也就意味着这些业务操作肯定要失败,与之相反服务优雅关闭,指在关闭前,他会拒绝新的进求进来,同时要完成当前的所有业务后,才关闭,有点像银行的窗口,不接受业务了,但要把当前正办理的业务处理完。测试人员以此作为一个 check point ,可用来验证云服务实现水平的高低,又能为服务的可靠性测试提代相关测试手段/方法,这个点也要 get 到。

总结来说,就是测试云上应用,除了业务功能自身的测试,还要测试上述提到的 8 个非业务功能硬核点,特别是前 3 点,是区分真云,假云最关键点;云化绝对是不可你逆转的趋势,测试人的相关观念也要以时具进,才能跟上发展的需要。当然个人水平有限,认知有限,论述后可能会存在偏颇之处,欢迎拍砖和补充。


↙↙↙阅读原文可查看相关链接,并与作者交流