回顾
上一节我们说到了去并发执行用例，我们提供了一个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左侧构建记录。
