目前测试的产品基本都是微服务架构的产品，这是企业从面向服务架构往微服务转型的必然趋势和过程。微服务的架构给质量交付团队带来了新的技术架构思维和挑战。我们结合一个具体的案例来说明，如很早期的一个产品，在客户需要的时候进行安装，那么就可以服务好客户就可以了，但是新的架构模式，客户只需要订阅，那么就可以使用这个产品了。那么这意味着一个微服务的架构产品可以服务几千甚至几千万的客户来使用。这个过程中，抛开混沌的不确定性以及稳定性，和服务稳定性的体系，就单纯的说功能验证而言，它的挑战和压力是非常大的，这些压力主要具体体现在：不管产品服务多少个客户，所有的客户业务形态是一样的，但是数据的存储数据库是分离的，那么是不是验证一个用户，其他的用户就不需要验证了？从理论上而言，这样是合理的，因为不管是一个用户还是很多个的用户，底层服务都是针对上层应用而言都是共享的。但是这仅仅是理论上而言，事实上这样做业务质量保障而言，还是存在很大的不确定性和风险，这些风险主要在不同用户之间存在差异性，这些差异性并不是业务形态，而是用户的数据存在差异性，这就导致在即使相同的业务逻辑中，可能由于数据的不规范性就会导致产生一些其他的问题，从而影响客户的使用。
第二是众多的用户就需要集群的模式来进行部署，比如服务的用户有一千家，那么一百家客户部署一个集群，也就是说这一百家用户使用一个数据库的资源，按照刚才说的用户群的个数，就需要十个集群的模式。那么这对质量交付团队而言带来的一个压力和挑战就是每次发布上线后，十个集群都是需要验证的，为什么这样说了？虽然不同集群的业务形态是一样的，但是由于不同集群使用了不同的数据存存储引擎，很难保证数据引擎这部分不出问题，比如连接数泄露，无连接数以及DB本身出现资源瓶颈，那么必然就会影响到客户使用产品的正常数据读写。因此，基于这样的一个现实问题，就需要一个良好的解决方案，解决问题的突破口可以理解为:
- 不管有多少个集群，使用的服务始终是一套
- 针对第一个的点，测试需要思考的是使用一套代码，能够持续的可流水线式的验证多个不同的集群
- 结合CI持续集成可以有效的打造可持续的流水线的作业。
然后结合Jenkins就可以打造可持续的集群规模化的流水线的验证，这样可以形成可持续的质量交付。从代码的角度而言，每个订阅的客户都使用的是不同的账户和密码，但是订阅成功后，使用账户以及密码登录到系统，系统的业务形态以及场景都是一样的，那么我们可以从这点进行突破，也就是说针对每个不同的集群，选择有代表性客户的账户作为验证集群的可用性和DB层面的可读写性。下面代码案例具体体现的是不同账户的分离，具体案例代码如下：
#! /usr/bin/env python
# -*- coding:utf-8 -*-
#author:无涯
import pytest,requests
from page.book import *
from utils.operationYaml import getUrl
from utils.operationJson import readJson
def pytest_addoption(parser):
parser.addoption(
'--username',action='store',default='wuya',help='myoption: type1 or pyte2'
)
parser.addoption(
'--password',action='store',default='admin',help='myoption: type1 or pyte2'
)
@pytest.fixture()
def username(request):
return request.config.getoption('--username')
@pytest.fixture()
def password(request):
return request.config.getoption('--password')
@pytest.fixture(name='token')
def getToken(username,password):
r=requests.post(
url=getUrl()+'auth',
json=readJson(username,password)['auth'])
return r.json()['access_token']
@pytest.fixture()
def headers(token):
return {"Authorization":"jwt {0}".format(token),
"Content-Type":"application/json"}解决了账户的问题后，下来具体需要每个集群验证哪些业务形态，其实相对而言是特别简单的部分，这样我们在CI中执行的时候，可以指定不同的账户和密码来进行执行，这样的好处是解决了一套代码能够规模集群化的验证很多的集群，第二是可以实现自定义的指定想验证的租户。和CI整合后，形式可持续的流水线的交付，具体如下：
微服务是一种好的架构模式，它把“软件即服务”体现的非常完美，但是同时也带来了很多需要解决的问题。后续会逐步的更新关于队列，调度，任务优先级，线上巡检机制，全链路监控以及可持续的解决方案。
