云计算的基本概念和常见测试点

云计算的定义

对云计算的定义有很多方式，其实每种定义都能反映云计算的一些特点，比较常见的定义如下：

美国国家标准与技术研究院（NIST）：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务、存储、应用软件、服务），这些资源能够快被快速提供，只需投入很少的管理工作，或与服务进行很少的交互。
刘鹏教授对云计算给出了长、短两种定义：
长定义是：云计算是一种商业计算模型。它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。
短定义是：云计算是通过网络按需提供可动态伸缩的廉价计算服务

云计算的特点

并行计算(Parallel Computing)、
分布式计算(Distributed Computing)
网格计算(Grid Computing)
虚拟化(Virtualization)
效用计算(Utility Computing)
将基础设施作为服务IaaS(Infrastructureas a Service)：消费者通过internet可以从完善的的计算机基础设施获取服务（硬件服务器租用）
将平台作为服务PaaS(Platform as a Service) ：软件的个性化定制开发
将软件作为服务SaaS(Software as a Service)：通过internet提供软件的模式

云化的基本概念

Cloud Native概念：核心改变是应用适合基础设施，而不是基础设施适合应用

应用上云

微服务架构：不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。一个微服务一般完成某个特定的功能，如下单管理、客户管理等，每个服务都有自己的数据库，微服务之间的数据传递可以通过服务暴露出的API来完成。
Docker: 构建在LXC之上、基于进程容器的轻量级VM，非常适合微服务。

大数据上云

数据上云，一般来说有两种经典模式：

托管模式：核心是通过云的能力简化了集群的创建、运维，以Amazon EMR为典型代表。
服务化模式：进一步简化了大数据的使用，用户不用关心集群、资源这些事情，只需要将大数据任务提交给大数据云，享受相应的服务即可，经典代表是微软的Azure Data Lake Analytics。

上云测试

功能性测试点

功能测试：即确保被测系统所提供的服务符合预期，主要包括如下方面：
系统验证测试：端到端的测试
用户验收测试：
互操作性测试：切换基础设施，仍然能无缝工作

非功能性测试点

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

弹性，也叫自动伸缩

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

多租户支持

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

故障转移/隔离

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

服务限流保护

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

应用安全

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

调用链追踪

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

可视化服务治理（可观测，可自动健康检查，服务优雅关闭等）

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

参考文章：