对于之前聊过的关于云原生自动化测试，设计实现来临，如果你在工作中涉及到了这部分，可以参考这个架构。
云原生自动化主要分为两个部分，云原生接口自动化/云原生CMD命令行自动化，本章节主要讲述命令行自动化，也是我以前工作中的一个总结，市面上针对命令行自动化测试缺少系统的框架以及方法论，对于很多入门的小伙伴非常不友好。这篇文章也预告了Opensourcetest的下一次大版本更新，将会上架云原生基础组件之CMD命令行自动化测试，拖更很久了。。。
什么是命令行测试？
类比普通的业务测试，众所周知，一个普通的单体服务，简单可以看成三个部分
- 前端服务
- 后端服务
- 存储中间件
那么云原生组件也可以这么简单划分，一个云原生组件可能有前端服务（cli agent），cli agent可以看成一个接收即时命令的入口，和前端界面类似，会向后端服务即云原生组件服务发起请求，只不过是通过执行命令的方式，之间的请求可能是http，也可能是grpc，或者其他协议。
测试人员此时入口只存在两种方式，一种是执行CMD命令，另一种是直接调用接口，通常来说，开放的接口只针对于集群环境中的其他云原生组件，或者业务组件，所以只通过接口的方式并不能覆盖所有的情况，使用这个云原生组件的人员，不止业务方，还可能有其他运维/实施/技术支持等角色。
所以对于命令执行的准确性、及时性、可靠性、以及命令本身在服务中的流转状态至关重要，完全可以看成是一个微缩版的前端服务，不同的是，入口可能只有命令，例如linux 工具包中的curl/wget，或者中间件命令，docker/redis/nginx等。另外中间件的测试过程当中，强依赖linux命令/其他中间件的命令，所以也是云原生测试岗位为什么会要求熟悉linux的原因。
命令行使用的用户群体是谁？
运维/研发/实施/售后技术/测试等
命令行自动化测试能解决什么问题？发挥了哪些作用？
- 解决云原生组件提供的命令人工手段回归耗时长的问题
- 解决混沌测试自动化中对于其他组件/机器操作困难问题
- 解决命令逻辑变动导致devops回归难问题
- 解决稳定性/高可用测试中的依赖测试问题
- 配合其他测试方法进行使用，集成于其他自动化场景中
命令自动化框架结构
前面大致讲了为什么需要命令行自动化测试以及它能解决什么问题，下面讲一下OpensourceTest框架中的CMD命令自动化测试的总体架构，以及数据状态流转
我将整体框架分为四层：
- 映射层
- 用例层
- 解析层
- 执行层
映射层，主要作用是将编写的CMD yaml文件，通过内置的工具映射成可执行/可引用的python模块，每一个python模块都是一个CMD obj，在用例层直接通过链路调用的方式，set不同的命令内容即可，当被测云原生组件进行CMD命令行变动时，只需要再次使用工具映射即可生成最新的文件对象
用例层，负责在测试用例的步骤中，调用CMD obj对象，设置不同的参数集，不影响其他测试框架的使用，例如pytest/behave/unittest等等，当成一个普通的Py工具包来使用即可，然后获取CMD obj对象的输入输出进行请求响应断言处理
解析层，用例层通过调用CDM obj对象，CMD obj对象会自动去解析可执行参数，生成可执行的命令，以及记录可执行的命令日志
执行层，通过Shell/SSH的方式，连接远程/本地服务器，执行相应的CMD obj命令，获取Stdout、Stderr、Status Code，返回给CMD obj对象，以及记录执行命令的相应日志，正确输出、错误输出、状态码等
下面是一个具体的流转图：
- 编写CMD Yaml文件，进行解析，解析错误，报错，提示具体的问题
- Yaml解析成功后，在项目的对应路径下生成可引用的CMD obj 模块
- 在用例中调用CMD obj模块
- CMD obj自动链接对应服务器进行命令执行
- 命令执行过程中出现异常，中止当前用例执行，返回错误信息，状态码
- 命令执行无非预见性异常，响应StdOut/StdErr/Code
- 用例中对于响应信息进行断言
CMD 命令行自动化测试不要局限于某一个云原生组件，而是拓展思路，例如混沌测试中对于依赖组件的启停，进程的优雅/强制退出，服务器的启停等等，也可以结合接口进行测试。好了本次的分享到此结束，希望大家有所收货，有问题社区滴滴我！！！
QQ群：816489363（自动化测试-夜行者，测试交流社区）