一、背景介绍
- 项目名称：某游戏社区平台项目（Game platform）
- 项目简介：Game platform is a completely free APK downloader. You can get the latest popular games and tools for Android on this platform. All mods are safe and ad-free. Download 100% working mods with Game platform App from now on!!。
二、业务介绍
模块： - 首页
- 游戏详情页
- mod详情页
- 我的游戏
- 个人
- 设置
三、架构介绍
有3套环境，测试环境（test)、予发布环境(pre)、生产环境(prod)
app-test工程展现层3个服务，网关层2个服务，微服务层8个服务，中间件1个
console-test工程展现层1个服务，网关层1个服务，微服务层1个服务
四、测试方案
可以把自动化测试框架主体分为两部分，一个是内部框架，一个是外部框架，内部框架就是我们自己实现的测试框架代码，外部框架就是抛开我们实现的核心代码，要达到自动化测试框架设计的一些内容时用到的一些第三方工具。
1、内部框架
也就是分层框架，目的在于更好的优化和管理测试用例，更便捷的进行数据、元素、脚本的维护和更快速的创建新脚本
包含公用方法封装、与业务无关方法的封装、配置文件的统一管理、第三方库的管理、运行日志的采集、用例管理、数据驱动管理、执行报告收集等。
├── common 放全局变量的目录
│ ├── __init__.py
│ ├── getpath.py 定义了部分文件夹的路径
│ ├── header_manage.py 请求头定义与管理
│ ├── grpc_request.py grpc请求方法
│ ├── http_request.py http请求方法
│ └── yamlread.py 读取yaml文件
├── config 放配置文件的目录
│ ├── __init__.py
│ ├── env.yaml 定义执行环境的配置文件
│ ├── logging.conf 定义log等级和样式的配置文件
│ └── read_yaml.py 读yaml的文件(不用)
├── func 放proto及其生成文件
│ ├── compileproto 放解析proto生成的py文件
│ ├── proto proto项目
│ ├── __init__.py
│ ├── compile_proto.py 编译proto为py文件
│ └── proto_init.py 也是编译proto为py文件(另一种方式)
│ └── get_pb2_services.py 写grpc连接文件
│ └── get_conn.py get_pb2_services.py生成的grpc连接文件
├── lib
│ └── __init__.py
│ └── email_client.py 读取邮箱验证码
├── log 放log的目录（无需操作）
│ ├── __init__.py
│ └── test.log
├── report 放测试报告的目录（无需操作）
│ └── __init__.py
│ ├── html 测试报告
│ ├── result 测试结果
├── test_cases 放测试用例的目录
│ ├── __init__.py
│ ├── test_GetConfig.py
│ ├── test_Login.py 登陆测试用例
│ ├── test_sendVerificationCode.py 发送验证码的测试用例，读取yaml版
│ ├── TestSendVerificationCode.py 发送验证码的测试用例，测试版
│ └── yaml_read_demo1.py 读取yaml文件的demo
├── test_datas 放测试数据的目录
│ ├── __init__.py
│ ├── test2.yaml
│ ├── test_login.yaml 登陆的测试用例文件
│ └── test_sendVerificationcode.yaml 发送验证码的测试用例文件
├── .gitignore 定义不上传到git的文件或目录
├── conftest.py 公用方法
├── main.py 项目入口
├── pytest.ini pytest配置文件
├── README.md 本文件
├── requirememts.txt 记录项目依赖包的文件
└── requirements_int.sh 安装项目依赖包的脚本，初始化项目请先执行次文件
2、外部框架
用以实现持续集成、自动部署、脚本执行、远程调用、报告优化、报告发送等功能性框架，实现自动化框架设计原则的一些外围的组件。
代码管理：gitlab仓库，建主干和分支
持续集成部署：首选Jenkins集成，现有shell自动部署脚本备用
执行结果通知：小呱推送到相关飞书群
3、测试痛点
痛点1：需要同时支持http协议和grpc协议
方案：完成封装后用户写接口时调用相同方法
技术总结与介绍：接口有2种协议，grpc协议、http协议，需要同时支持这2种协议，http协议比较好处理，可以直接采用requests库处理，grpc协议是难点，首先采用grpc的官方demo写接口，发现可封装性不高，且传参数不支持json，在https://pypi.org上找支持grpc的插件，经过调研和实践选择了grpc_requests插件。
- 解决方案：
1、自动从gitlab上获取proto文件并进行编译，编译后按原有层级目录保存
2、遍历编译后的文件，获取grpc连接所需的services和method，写批量连接服务文件
3、封装get、post、grpc请求
解决效果：
http和grpc请求的用例管理用相同的模版，用户在写用例时调用相同的方法无感知差异
痛点2:由于业务变更，接口经常有变动，虽然变动范围小，但是影响范围不好圈定
方案：主要核心接口自动化，覆盖P0-P2级用例
技术总结与介绍：用yaml管理用例，采用pytest写接口
解决效果：
1、通过env.yaml文件配置test、pre、pro切换不同的执行环境，一套脚本可以支持不同环境，灵活性强
2、版本发布后直接先执行自动化接口，在3分钟左右就可以快速完成接口测试，保证版本质量
3、接口有改动时只需更新原有用例，原来需要2天/人的投入，现在只需0.5天/人的投入
五、问题汇总
- 自动化产生的垃圾数据怎么处理？
- 有些接口需要有特殊预置条件，比如token3个月过期，过期的会话登录后更新token信息，这种情况怎么测试？
- 有些代码在本地运行好好的，部署到服务器后居然不能运行
# repo = git.Repo.clone_from(url=gitlab, to_path=path)
# remote = repo.remote()
# # 从远程版本库拉取分支
# remote.pull(‘master’) # 后面跟需要拉取的分支名称