大家好，我是米洛，求三连！求关注龚仲耗
测试开发坑货!
项目地址: https://pity.readthedocs.io/
回顾
上一节我们说到了去并发执行用例，我们提供了一个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左侧构建记录。
网友评论