服务端测试之集群验证（一）

在Saas化的架构下，测试首先需要思考的是如何能够去验证多个集群，这是不得不面对的一个问题。在单体的架构下，我们只需要端到端的测试后，即使上线我们也可以使用这样的策略方式来进行验证，从而保障产品的质量。Saas化的架构下，测试的复杂性相比单体架构而言更加复杂，因为你无法预知一个集群好的就可以推理出其他的集群也是正常。抛开技术的思维，我们就拿生活中的案例来说，我们总是以过去的经验以及数据来推理今天以及未来的结果性，这个过程本身就是可假设性的，任何理论上的假设都是基于事实的数据才来验证理论的准确性，我把这样的一个过程描述为“在不确定性中来推理不确定性然后来证明可确定性”。就像刚才说的案例，基于理论的事实和推理，我们可以得出一个集群如果是好的，那么其他集群也是好的，根本就不需要去校验和验证，但是事实上真的是如此吗？当然我们在这里并不计划去讨论这些哲学问题，我们更加关注的是在一个Saas化的产品下，每次产品的更新和发布，如何能够去验证到每个集群的功能。可以从如下图看看出，我们需要被验证的集群：

那么依据图，可以得到底层服务是共享的，基于服务共享的思想下，每次服务发布或者更新以及上线，我们需要去验证上线的功能点在每个集群是否满足发布的要求，或者更加准确的说就是需要进行冒烟测试，保障新上线的功能点和系统已有的功能点都是符合产品质量要求的。

基于如上叙述，就涉及到一个点，针对每个集群它都是有不同的存储方式，也就是数据库，这是一个点，另外一个点是不同的集群都部署了不同的用户群体，要验证每个集群就得有账户去登录到每个集群然后在里面验证具体的点。如果单纯的常规思维，一套代码怎么能够做到多集群的验证了？这是在服务端的测试中必然要面临的一个问题，如何一套代码可以使用在多个集群去校验和执行，这样就可以打造可持续的流水线来进行验证了。针对如上说的，单独的参数化是解决不了该问题的，只所以说参数化解决不了该问题是因为我们去验证每个集群的账户是不确定的，是比较随性的，比如可能是1，也可能是100，也可能是A账户，当然还有其他的账户，每个账户登录到系统后返回的数据都是不一样的，参数化等于是把这个过程账户写死，缺少动态修改的一个过程，并不是我们想要的，我们更多想要的是如果使用账户A，那么就在命令行使用A账户，如果是B，就使用B账户，这样就可以很自由的指定我们所需要的账户，也达到了想验证那个集群，就可以指定那个集群的账户信息。我们可以通过Pytest框架中的命令行解释来实现，具体代码如下：

#!/usr/bin/python3
#coding:utf-8

import  pytest
from selenium import webdriver

def pytest_addoption(parser):
   '''添加pytest的自定义命令行参数--userName'''
   parser.addoption(
      '--userName',action='store',default='wuya',help='myoption: type1 or pyte2'
   )

@pytest.fixture()
def getUserName(request):
   '''参数处理成fixture'''
   return request.config.getoption('--userName')

这样我们在具体的测试点中，针对传进去的不同账户，我们指定执行用户后，在验证具体的接口返回的响应数据，也验证具体指定的用户，这样就很轻松的解决了上面说到的问题。

这样每次发布后，我们可以打造一个流水线，定时执行或者手动触发后能够一次性的验证到所有的集群，而不需要一个集群一个集群的去校验。见流水线的截图信息，如下图所示：

当然这样就不详细的去演示流水线执行的过程了。