软件测试回顾(11)
网站架构设计
48章：测试工程师为什么要懂网站架构设计？
不懂得网站架构设计知识，在开展测试时，就真的会有处处被掣肘的感觉了。更别提，这还会直接影响到你的能力提升和职业发展了。
传统软件企业,网站的架构设计知识对你来说可能没那么重要，想跳出传统软件产品测试这个舒适区的话，而在互联网企业进行软件测试的话，很多时候需要针对互联网的架构来设计有针对性的测试，另外对于互联网的压力测试以及结果分析也需要对架构知识有比较清楚的认识。
很多时候，你只是知道网站在架构设计上有这些组件，并不清楚这些组件真正的作用，在对应的测试设计时也很难做到“有的放矢”。
测试工程师怎么学架构知识？
同样是对架构知识的学习和掌握，不同角色的工程技术人员都有不同的视角，需要了解和掌握的全局知识和细节程度也各不相同。
对于测试人员来讲，学习架构知识应该有自己独特的视角，基本只要做到清楚原理、了解在被测系统中的部署架构，从测试的角度能够调用必要的接口就可以了。
根据我的个人经验，我认为应该遵循“由广度到深度”和“自上而下”两个基本原则。
“由广度到深度”中的“广度”是指在平时工作以外的时间中，应该多注重全领域架构知识的积累，此时那些系统性地介绍架构知识的书籍或者专栏就可以给你最大程度的帮助了。
推荐极客时间李运华老师的“从0开始学架构”专栏，以及李智慧老师所著的图书《大型网站技术架构：核心原理与案例分析》。它们都能帮你从广度上积累架构知识。
“由广度到深度”的“深度”是指，对于架构中某一领域的特定知识在项目中要实际使用的时候，必须要刨根问底，通过实际的测试来加深对架构知识细节的理解。
“自上而下”是指，在实际测试项目中，当需要设计涉及架构的测试用例和场景的时候，千万不要直接基于“点”来设计测试，而是应该：首先通过全局阅读理解上层架构设计；然后，在理解了架构设计的初衷和希望达成目的的基础上，再向下设计测试场景和用例。
对于架构知识的学习没有任何捷径可走，你必须一步一个脚印，才能达到下一个高峰。
接下来4章会分享网站的高性能架构、高可用架构、伸缩性架构以及扩展性架构。
49章：网站高性能架构设计
为了优化网站性能，业界出现了很多相关的架构改进方案和技术手段。单单依靠几篇文章是很难讲清楚的。从中精选了一些对测试工程师比较关键的概念和技术，和你展开今天的分享。
网站的高性能架构设计包括两大部分内容：一是前端性能，二是后端服务器相关的性能优化和架构设计。
前端的高性能架构
前端高性能架构比较直观易懂，其本质就是通过各种技术手段去优化用户实际感受到的前端页面展现时间。
前端性能优化的方法是相对标准的。而且，目前的前端性能测试工具，比如我在前面文章中曾经介绍过的WebPageTest和YSlow之类的工具等，都能系统性地分析前端的性能问题，并给出对应的解决方案建议。
后端服务器的高性能架构
后端服务器的高性能架构，业内采用的最主要的技术手段是缓存。同时，集群也可以从计算能力的角度，提升后端的处理性能。
缓存：
- 从缓存中读取数据的速度更快。
- 无需再重复计算即可直接使用。(降低后端运算负载的作用)
在系统和软件的不同级别对应有不同层级的缓存：
- 浏览器级别的缓存，会用来存储之前在网络上下载过的静态资源；
- CDN本质也是缓存，属于部署在网络服务供应商机房中的缓存；
- 反向代理服务器本质上同样也是缓存，属于用户数据中心最前端的缓存；
- 数据库中的“热点”数据，在应用服务器集群中有一级缓存，在缓存服务集群中有二级缓存；
- 甚至是用于URL和服务器IP地址转换DNS服务器，为了减少重复查询的次数也采用了缓存。
启用了缓存后，当应用程序需要读取数据时，会先试图从缓存中读取：
- 如果读取成功，我们称为缓存命中，此时就可以在很大程度上降低访问数据库的时间开销。
- 如果没有读取到数据或者缓存中的数据已经过期失效，那么应用程序就会访问数据库去获取相应的数据。获取到数据后，在把数据返回给应用程序的同时，还会把该数据写入到缓存中，以备下次使用。
缓存主要用来存储那些相对变化较少，并且遵从“二八原则”的数据。这里的“二八原则”指的是80%的数据访问会集中在20%的数据上。
如果我们将这20%的数据缓存起来，那么这些数据就会具有非常高的读写比。读写比越高，说明缓存中的数据被使用的次数也就越多，从而节省的数据库访问也就越多，缓存的优势也就越明显。
缓存技术并不适用于那些需要频繁修改的数据。对于这种需要频繁修改的数据来说，经常会出现刚刚写入缓存的数据还没来得及被读取就已经失效了的场景。所以，在这种情况下，缓存不仅不会带来性能提升，反而会增加系统开销。
现在的数据库已经习惯了有缓存的日子，假如哪天缓存系统奔溃了，就会在短时间内有大量的请求来访问数据库，数据库就很可能会因为无法承受这样的并发压力而宕机。
为了解决这个问题，有些网站会使用缓存热备等技术手段来提供缓存的高可用性，即：当某台缓存服务器宕机的时候，会将缓存访问切换到热备的缓存服务器上。
如果你采用了分布式缓存服务器集群的话，那么缓存的数据将被分布到集群中的多台服务器上，当其中一台服务器宕机的时候，也只会丢失一部分缓存数据，此时通过访问数据库来重建这些缓存数据的开销并不算太大。
分布式缓存架构的主流技术方案有两种：
-
一种是，在企业级应用中广泛采用的JBoss Cache。JBoss Cache需要在缓存集群中的每台机器上同步所有缓存的副本，当集群规模比较大的时候，同步代价会很高。而且，多份副本也会造成存储资源的浪费。但其最大的优点是速度非常快，所以JBoss Cache更适用于企业级规模不是很大的缓存集群。这种企业级的集群一般在几台到十几台服务器的规模。
-
另一种是，在互联网应用的主流Memcached。Memcached属于互不通信的分布式架构，集群中各个节点缓存的数据都不一样，缓存使用者基于Hash一致性算法来定位具体的内容到底缓存在集群中的哪个节点。
因此，Memcached具有缓存容量大，存储效率高，可以很方便地支持集群的扩展，但是速度相对较慢的特点。这些特点决定了Memcached非常适用于现如今的互联网产品架构，几乎成为了网站分布式缓存架构的代名词。
互联网产品架构的应用服务器集群规模一般都很大，即使小规模的应用集群也有上百台机器，规模大的话可以达到上万台，这种架构下的缓存集群规模要求也非常大。
从测试人员的视角来看看，在执行测试时需要考虑到哪些与缓存相关的测试场景：
- 对于前端的测试场景，需要分别考虑缓存命中和缓存不命中情况下的页面加载时间。
- 基于缓存过期测试策略的设计，需要考虑到必须要重新获取数据的测试场景。
- 需要针对可能存在的缓存“脏数据”，进行有针对性的测试。缓存“脏数据”，是指数据库中的数据已经更新，但是缓存中的数据还没来得及更新的场景。
- 需要针对可能的缓存穿透进行必要的测试。缓存穿透，是指访问的数据并不存在，所以这部分数据永远不会有被缓存的机会，因此此类请求会一直重复访问数据库。
- 系统冷启动后，在缓存预热阶段的数据库访问压力是否会超过数据库实际可以承载的压力。
- 对于分布式缓存集群来说，由于各集群使用的缓存算法不同，那么如果要在缓存集群中增加更多节点进行扩容的话，扩容对原本已经缓存数据的影响也会不同。所以，我们需要针对缓存集群扩容的场景，进行必要的测试和性能评估。
集群：
集群也是提升网站性能和并发处理能力的典型架构设计方法。
当一台服务器不足以满足日益增长的用户流量时，我们就可以考虑使用多台服务器来组成一个集群：外部请求将统一和负载均衡器打交道；负载均衡器根据不同的负载调度算法，将访问请求传递给集群中的某台服务器处理。
集群中的任何一台服务器宕机都不会给整个系统带来明显的影响。我们可以直接替换掉出现了问题的某台服务器。集群中的每台服务器都可以被随时替换或者淘汰掉，就像“牲口”似的可以任人宰割。所以，这种模式，就有点类似于“牲口”模式。
与“牲口”模式对应的是“宠物”模式，比如一些企业级的应用，它们往往不通过集群来扩展系统的能力和提高系统的性能，而是采用更为强劲的服务器。
综上所述，现今的互联网应用采用的都是“牲口”模式。在这种模式下，我们在开展测试时，相应地需要额外关注以下这些测试点：
- 集群容量扩展。也就是说，集群中加入新的节点后，是否会对原有的session产生影响。
- 对于无状态应用，是否可以实现灵活的实效转移。
- 对于基于session的有状态应用，需要根据不同的session机制验证会话是否可以正常保持，即保证同一session始终都有同一个确定的节点在处理。
- 当集群中的一个或者多个节点宕机时，对在线用户的影响是否符合设计预期。
- 对于无状态应用来说，系统吞吐量是否能够随着集群中节点的数量呈线性增长。
- 负载均衡算法的实际效果，是否符合预期。
- 高并发场景下，集群能够承载的最大容量。
50章：网站高可用架构设计
网站高可用指的就是，在绝大多的时间里，网站一直处于可以对外提供服务的正常状态。
业界通常使用有多少个“9”来衡量网站的可用性指标，具体的计算公式也很简单，就是一段时间内（比如一年）网站可用的时间占总时间的百分比。
我用下面这个表格，列出了四种最常见的可用性等级指标，以及允许的系统不可用时长。
一般来讲，业界的网站能做到4个“9”，也就是说在一年内只有53分钟的时间网站是处于不可用状态，就已经是算是非常优秀了。
1.网站不可用原因
造成网站不可用的主要原因有以下三大类：
- 服务器硬件故障；
- 发布新应用的过程；
- 应用程序本身的问题。
1.服务器硬件故障
某台服务器由于硬件故障宕机，可以说不是偶然，而是必然会发生的。网站后台的服务器数量也越来越多，所以由硬件故障引起问题的概率也是不断飙升。
2.发布新应用的过程
网站的新版本发布过程中，往往会出现需要重新部署新的应用程序版本，然后再重启服务的情况。
如果这个更新过程中不采用特殊技术手段的话，也会造成短暂的服务不可用。而且这种形式的不可用，相比服务器硬件故障的不可用更为常见。
互联网网站的功能更新迭代非常快，基本都是以“天”为单位来发布上线的，也就是说几乎每天都有需要中断服务来完成服务升级的可能。
显然，从业务角度来看，这种为了应用升级造成的服务不可用，完全不可能被接受。这就好比eBay或者淘宝告诉你说，我们每天某个时间段需要内部升级维护无法对外提供服务一样，让人无法接受。。因此，我们的高可用架构设计必须能够提供切实可行的方案，将这种停机升级的影响降到最小。
3.应用程序本身的问题
发布的应用程序版本身存在潜在的内存泄露，那么经过较长时间的运行积累后，最终会造成服务器的内存被占满，之后必须要靠重启服务来恢复。
应用程序在测试环境没有经过充分的测试验证，或者说由于测试环境的配置和实际生产环境之间存在差异，有可能造成应用程序在生产环境部署完后无法使用的情况，从而造成服务不可用。
网站高可用架构设计
们在网站高可用架构设计上，探索出了对应的三类方法。
- 第一类方法是，从硬件层面加入必要的冗余；
- 第二类方法是，灰度发布；
- 第三类方法是，加强应用上线前的测试，或者开启预发布验证。
1.硬件层面加入必要的冗余
对于第一类硬件故障造成的网站不可用，最直接的解决方案就是从硬件层面加入必要的冗余，同时充分发挥集群的“牲口”优势。
比如，对于应用服务器来说，即使没有伸缩性的要求，我们也会至少采用两台同样的服务器，并且引入一台额外的负载均衡器，所有的外部请求会先到负载均衡器，然后由负载均衡器根据不同的分配算法选择其中的某一台服务器来提供服务。
因此，从测试人员的角度来看，知道了应用服务器集群的工作原理，就可以在设计测试的时候，针对集群中的某一个或者某几个节点的故障情况设计测试用例。
再比如，对于数据存储的服务器来说，往往通过数据冗余备份和失效转移机制来实现高可用。为了防止存储数据的服务器发生硬件故障而造成数据丢失，我们往往会引入多个数据存储服务器，并且会在数据有更新操作的时候自动同步多个数据存储服务器上的数据。
从测试人员的角度来看，我们依旧可以针对这种情况设计出针对部分数据服务器发生故障时的测试用例，以完成系统应对故障的反应情况的测试
2.灰度发布
由于发布新应用造成的系统不可用，我们采用的主要技术手段是灰度发布。
使用灰度发布的前提是，应用服务器必须采用集群架构。假定现在有一个包含100个节点的集群需要升级安装新的应用版本，那么这个时候的更新过程应该是：
- 首先，从负载均衡器的服务器列表中删除其中的一个节点；
- 然后，将新版本的应用部署到这台删除的节点中并重启该服务；
- 重启完成后，将包含新版本应用的节点重新挂载到负载均衡服务器中，让其真正接受外部流量，并严密观察新版本应用的行为；
- 如果没有问题，那么将会重复以上步骤将下一个节点升级成新版本应用。如果有问题，就会回滚这个节点的上一个版本。
- 如此反复，直至集群中这100个节点全部更新为新版本应用。
在这个升级的过程中，服务对外来看一直处于正常状态，宏观上并没有出现系统不可用的情况。就好比是为正在飞行中的飞机更换引擎，而飞机始终处于“正常飞行”的状态一样。
加强上线前的测试+启用预发布验证
对于第三类应用程序本身的问题造成的系统不可用，我们一方面要加强应用程序上线部署前的测试以保证应用本身的质量，另一方面需要启用所谓的预发布验证。
我们一定遇到过这样的尴尬情况：应用在测试环境中经过了完整、全面的测试，并且所有发现的缺陷也已经被修复并验证通过了，可是一旦发布到了生产环境，还是立马暴露出了很多问题。
这其中的主要原因是，测试环境和生产环境存在差异。
为了避免这类由于环境差异造成的问题，我们往往会预发布服务器。预发布服务器和真实的服务所处的环境没有任何差别，连接的第三方服务也没有任何差别，唯一不同的是预发布服务器不会通过负载均衡服务器对外暴露，只有知道其IP地址的内部人员才可以对其进行访问。此时，我们就可以借助自动化测试来对应用做快速的验证测试。
51章：网站伸缩性架构设计
可伸缩性翻译自Scalability，指的是通过简单地增加硬件配置而使服务处理能力呈线性增长的能力。最简单直观的例子，就是通过在应用服务器集群中增加更多的节点，来提高整个集群的处理能力。
可扩展性翻译自Extensibility，指的是网站的架构设计能够快速适应需求的变化，当需要增加新的功能实现时，对原有架构不需要做修改或者做很少的修改就能够快速满足新的业务需求。
分层的可伸缩性架构
网站的可伸缩性架构设计主要包含两个层面的含义：
- 1 根据功能进行物理分离来实现伸缩；
- 2 物理分离后的单一功能通过增加或者减少硬件来实现伸缩。
物理分离后的单一功能通过增加或者减少硬件来实现伸缩
- 纵向的可伸缩性，指的是通过增加单一服务器上的硬件资源来提高处理能力。
- 横向的可伸缩性，指的是通过使用服务器集群来实现单一功能的可扩展性。
- 这种方式是基于集群的可伸缩性实现的，也是目前最主流的网站可伸缩性方法，也就是我之前提到过的“牲口”模式。很多时候当我们谈及网站的可伸缩性设计时，如果没有特定的上下文或者特指的场景，往往指的都是基于集群的可伸缩性。
基于集群的可伸缩性设计，是和网站本身的分层架构设计相对应的：
- 在应用服务器层面有应用服务器集群的可伸缩性架构设计；
- 在缓存服务器层面有缓存服务器的可伸缩性架构设计；
- 在数据库层面有数据库服务器的可伸缩性架构设计。
应用服务器的可伸缩性设计
当一台应用服务器不足以支撑业务流量的时候，我们就可以用多台服务器来分担业务流量。
为了保证这批服务器对外暴露的是一个统一的节点，我们就需要一个负载均衡器作为统一的窗口来对外提供服务，同时负载均衡器会把实际的业务请求转发给集群中的机器去具体执行。通过负载均衡算法（比如轮询算法、基于加权的轮询算法、最小链接算法等）将用户流量分配到集群机器。从这个意义上说，将负载均衡器称为任务分配器才更合适。
为了实现线性可伸缩性，我们希望应用本身是无状态的。此时，任何请求都可以在集群中任意节点上来执行，也就是说集群的处理能力将随着节点数量的增多呈现线性增长的态势。
但是，如果应用本身是有状态的，那么就会要求基于一次会话（session）的多次请求都被分配到集群中某一台固定的服务器上去执行。
从测试人员的角度来想想，应该考虑哪些相关的测试场景。为此，我总结了以下几点供你参考：
- 需要通过压力测试来得出单一节点的负载承受能力；
- 验证系统整体的负载承受能力，是否能够随着集群中的节点数量呈现线性增长；
- 集群中节点的数量是否有上限；
- 新加入的节点是否可以提供和原来节点无差异的服务；
- 对于有状态的应用，是否能够实现一次会话（session）的多次请求都被分配到集群中某一台固定的服务器上；
- 验证负载均衡算法的准确性。
缓存集群的可伸缩性设计
传统的缓存服务器集群是无法通过简单地加入新的节点来实现扩容的，
假定，一个缓存集群中有3台机器，那么我们在将需要缓存的内容存入缓存集群的过程，包括了这三步：
- 首先，将需要缓存的内容的Key值做Hash运算；
- 然后，将得到的Hash值对3取余数；
- 最后，将缓存内容写入余数所代表的那台服务器。
而此时，如果我们在缓存集群中加入了一台新的机器，也就是说缓存集群中机器的数量变成了4。这时Key的Hash值就应该对4取余，你会发现这么一来，原本已经缓存的绝大多数内容就都失效了，必须重构整个缓存集群。而这，显然不能被接受。
使得缓存集群也可以做到按需、高效地伸缩，那就必须采用更为先进的Hash一致性算法。
道了缓存集群扩容的实现细节后，我们再从测试人员的角度出发：
- 针对缓存集群中新增节点的测试，验证其对原有缓存的影响是否足够小；
- 验证系统冷启动完成后，缓存中还没有任何数据的时候，如果此时网站负载较大，数据库是否可以承受这样的压力；
- 需要验证各种情况下，缓存数据和数据库数据的一致性；
- 验证是否已经对潜在的缓存穿透攻击进行了处理，因为如果有人刻意利用这个漏洞来发起海量请求的话，就有可能会拖垮数据库。
数据库的可伸缩性设计
从实际应用的角度来看，数据库的可伸缩性设计主要有四种方式：
- 第一种方式是目前最常用的业务分库将一个庞大的数据库拆分成多个不同的数据库。比如，对于电商网站来说，它们可以考虑将用户相关的表放在一个数据库中，而商品相关的表放在另一个数据库中。
- 但最大的问题是跨数据库数据的join操作只能通过代码在内存中完成，实现代价和成本都比较高。这种方式目前在一些中大型电商有不同程度的应用。
- 第二种方式是读写分离的数据库设计其中主库用于所有的写操作，从库用于所有的读操作，然后主从库会自动进行数据同步操作。
- 这个架构最大的问题在于可能出现数据不一致的情况。比如，写入的数据没能及时同步到从库，就可能会出现数据不一致。另外，这种读写分离的设计对数据库可伸缩性的贡献来讲，比较有限，很难从根本上解决问题。
- 主要应用在中小型规模的网站中，同时读写分离的设计也通常会和业务分库的设计一起采用，来提高业务分库后的数据库性能。
- 第三种数据库的可伸缩性设计：分布式数据库。
- 分布式数据库同样存在数据不一致的问题，并且，这个方法通常只在单个数据表异常庞大的时候才会被采用，否则我还是更推荐业务分库的方法。
- 这种数据库设计可以说是比较主流的应对大规模高并发应用的数据库方案。
- 第四种方式则是完全颠覆了传统关系型数据数据库的NoSQL设计。
- NoSQL放弃了事务一致性，并且天生就是为了可伸缩性而设计的，所以在可伸缩性方面具有天然优势。因此，在互联网领域被广泛使用。
从测试的角度出发，无论是数据库架构哪种设计，我们一般都会从以下几个方面来考虑测试用例的设计：
- 正确读取到刚写入数据的延迟时间；
- 在数据库架构发生改变，或者同样的架构数据库参数发生了改变时，数据库基准性能是否会发生明显的变化；
- 压力测试过程中，数据库服务器的各项监控指标是否符合预期；
- 数据库在线扩容过程中对业务的影响程度；
- 数据库集群中，某个节点由于硬件故障对业务的影响程度。
52章：网站可扩展架构设计
可扩展性，指的是网站的架构设计能够快速适应需求的变化，当需要增加新的功能实现时，对原有架构不需要做修改或者做很少的修改就能够快速实现新的业务需求。
提升网站可扩展性性的核心，就是降低系统各个模块和组件之间的耦合。耦合程度越低，各个模块和组件的复用可能性就越大，系统的可扩展性也会越好。
从现在来看，实现网站可扩展性架构的主要技术手段包括事件驱动架构和微服务架构。
微服务架构从根本上改变了网站的架构形式，带来可扩展性便利的同时，还带来了很多其他优秀的特性。在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列的微服务组成。其中每个微服务可被独立开发和部署，各个微服务之间是松耦合的。每个微服务仅专注于完成一件任务，并要很好地完成该任务。
在微服务架构下，当网站需要增加新功能时，我们除了可以添加新的业务逻辑外，还可以利用原本已经存在的微服务来构建新的功能。由于服务和服务之间是相互隔离的，并且单个服务还可以被其他多个服务复用，所以系统的可扩展性会比较好。
重点分享事件驱动架构是如何提升网站的可扩展性的。
而事件驱动架构的落地靠的是消息队列，所以我会同时和你分享消息队列的内容。最后，我会再和你分享引入了消息队列后，从测试人员的角度来看会有哪些需要额外关注的点。
事件驱动架构与消息队列
系统各个模块之间只是通过消息队列来传输事件消息，而各模块之间并没有直接的调用关系、保持松散的耦合关系。
事件驱动架构最典型的一个应用就是操作系统中常见的生产者和消费者模式，将其应用到网站设计中就是分布式消息队列。
分布式消息队列同样采用了生产者和消费者模式：
- 消息的发送者负责将消息发布到消息队列中，也就是“生产者”；
- 另外，系统中会有一个或者多个消息接收者订阅消息，订阅目的是为了获取消息并进行处理，这里的消息订阅者其实就是“消费者”。消息接收者发现消息队列中有新的消息后，就会立马对其进行处理。
在这种模式下，消息的发送者和接收者之间并没有任何直接的联系，是松耦合的。它们的协作是通过消息队列这个“中间人”进行的。消息的发送者将消息发送至消息队列后，就结束了对消息的处理，而消息的接收者只是从消息队列中获取消息进行后续的处理，并不需要知道这些消息从哪里来，因此可以很方便地实现高可扩展性。
所以，采用这种模式的话，当网站需要增加新功能的时候，只要增加对应的新模块，再由对此模块感兴趣的“消费者”进行订阅，就可以实现对原有系统功能的扩展了，而对原本的系统模块本身并没有影响。
引入了消息队列后，我们不仅可以提高系统的可扩展性，还可以再一定程度上改善网站架构的高性能、高可用性和可伸缩性。
- 从性能方面来看，消息发送者不需要等接收者实际处理完成后才返回，也就是从原本的同步处理变成了异步处理，所以用户会感知到网站性能的提升。
- 从高可用方面来看，假如消息的接收者模块发生了短时间的故障，此时并不会影响消息发送者向消息队列中发送消息，等到消息接收者模块恢复后可以继续后续的处理，只要这段时间内消息队列本身没有被塞满而出现消息丢失的情况。从整体角度看，系统并不会感知到消息接收者模块曾经发生过短暂故障，也就相当于保证了系统的高可用。
- 从可伸缩性方面来看，消息队列的核心其实就是一个无状态的存储。所以，当系统需要能够保留更多的消息时，我们通过简单地增加存储空间就可以实现。尤其是，大规模的电商网站来更会将消息队列扩展成为分布式消息队列集群，来实现消息队列的可伸缩性。
在测试时需要特别关注哪些点:
- 从构建测试数据的角度来看，为了以解耦的方式测试系统的各个模块，我们就需要在消息队列中构造测试数据。这也是为什么很多互联网的自动化测试框架中都会集成有消息队列写入工具的主要原因。
- 从测试验证的角度来看，我们不仅需要验证模块的行为，还要验证模块在消息队列中的输出是否符合预期。为此，互联网的自动化测试框架中也都会集成消息队列的读取工具。
- 从测试设计的角度来看，我们需要考虑消息队列满、消息队列扩容等情况下系统功能是否符合设计预期。
- 除此之外，我们还需要考虑，某台消息队列服务器宕机的情况下，丢失消息的可恢复性以及新的消息不会继续发往宕机的服务器等等。
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
