回顾
上一节我们说到了去并发执行
用例,我们提供了一个async的接口,利用asyncio达到了提升用例执行速度的作用。
今天我们就来完善我们的测试报告
相关的功能。
明确目标
目前对我们来说:最关键的
就是用例可以批量执行
。上一步我们已经完善了,那用例可不能只执行不输出。所以我们今天搞定它!
tips: 最近虽然没更文,但是代码写的进步比较超前了,我也有点不太适应
现在的模式。
我们把每次用户的执行
,算作一次构建,今天要做的就是生成这样的构建数据。
站在巨人的肩膀上
以jenkins
为例,它的每一次触发都会生成一个构建记录
。
我们有好的产品去对比学习,这样我们就会少走很多弯路
。
image
以上图为例,jenkins构建的记录都在这里进行展示,大家可以搜索也可以看到具体的执行时间
,最重要的是我们知道执行的结果
。(红色代表失败了)
表设计
表设计是个老话题了,我们还是拆分3个模块:
- 通用字段(包括主键,创建更新时间,创建人更新人等)
- 业务字段
- 预留字段
class PityReport(Base): __tablename__ = 'pity_report' id = Column(INT, primary_key=True) # 执行人 0则为CPU executor = Column(INT, index=True) # 环境 env = Column(INT, nullable=False) # 花费时间 cost = Column(String(8)) # 测试集合id,预留字段 plan_id = Column(INT, index=True, nullable=True) # 开始时间 start_at = Column(DATETIME, nullable=False) # 结束时间 finished_at = Column(DATETIME) # 成功数量 success_count = Column(INT, nullable=False, default=0) error_count = Column(INT, nullable=False, default=0) failed_count = Column(INT, nullable=False, default=0) skipped_count = Column(INT, nullable=False, default=0) # 执行状态 status = Column(SMALLINT, nullable=False, comment="0: pending, 1: running, 2: stopped, 3: finished", index=True) # case执行模式 mode = Column(SMALLINT, default=0, comment="0: 手动, 1: 自动, 2: 测试集, 3: pipeline, 4: 其他") deleted_at = Column(DATETIME, index=True) def __init__(self, executor: int, env: int, success_count: int = 0, failed_count: int = 0, error_count: int = 0, skipped_count: int = 0, status: int = 0, mode: int = 0, plan_id: int = None, finished_at: datetime = None, cost=None): self.executor = executor self.env = env self.start_at = datetime.now() self.success_count = success_count self.cost = cost self.failed_count = failed_count self.error_count = error_count self.skipped_count = skipped_count self.status = status self.mode = mode self.status = status self.plan_id = plan_id self.finished_at = finished_at self.deleted_at = None
表里面注释都写的很清楚,我们来简单说下。
- executor
本次构建触发人,可能是人或者系统(system),这里我叫做CPU。 - env
构建执行的环境,与环境表对应。
其他的包括,执行耗时,执行成功失败等数量,开始/结束时间,执行模式大家应该都比较清楚。
报告表的不同之处
报告表和其他数据不一样的地方在于,我们的流程
不一样。一次报告很可能是先读到一部分数据:
比如执行人,开始时间等等。到构建完成了以后,我们才能拿到剩下的数据。最后,我们没有手动添加
报告这样的诉求,所以我们新增报告
的时候要拆分为2个方法。
梳理一下整个过程,insert拿到report_id,并记录开始/执行人相关信息,用例飞速运行,结束后把搜集的数据写回到report_id这条数据。
start方法
dao/test_case/TestReport.py
新建这样的数据,利用aiomysql
进行异步操作。把核心数据传入: 环境
,执行人
,模式
。因为我们这里目前还只支持手动执行,所以mode一般写死为0
。
其实代码没啥难度,理解就好。简单的说就是新插入一条数据,但是不是完整
的数据。
update方法
在执行过程中,可能需要修改构建的状态。比如我们构建如果被用户手动停止
了,我们需要把报告状态改为已停止
,所以这边有个update的方法,一般是用来修改状态的。如果后续还有其他的数据要修改,也可以调整一下这个方法
。
image
end方法
当用例结束之后,我们把搜集到的所有数据都回写到这条数据中。利用mysql主键的特性,保证我们每次新增的id都是唯一的,所以数据并不会串
。
image
新增并发执行用例方法
新增run_multiple方法
接口实现
在Executor类下面编写静态方法: run_multiple
。
具体的并发过程和之前差不多,注释已经写的很清楚了,从step1到step5.其他无非是一些获取用例执行数据
的信息。
最后为啥需要返回report_id呢,因为前端页面通过report_id可自动到达报告页面。
想象一下:
前端通过访问: /report/4
就可以拿到对应报告的数据,那就打通了整个执行->报告的过程,虽然目前还没有自动执行那一步
。
今天的内容就到这里结束了,下一篇讲编写构建历史页面,类似于jenkins左侧构建记录
。