测试平台系列(47) 编写测试报告之构建记录

大家好，我是米洛，求三连！求关注测试开发坑货!

如果阅读完毕后想和作者有更多交流，可以点击阅读原文找到底部评论区，给作者留言啦！

项目地址: https://pity.readthedocs.io/

回顾

上一节我们说到了去并发执行用例，我们提供了一个async的接口，利用asyncio达到了提升用例执行速度的作用。

今天我们就来完善我们的测试报告相关的功能。

明确目标

目前对我们来说：最关键的就是用例可以批量执行。上一步我们已经完善了，那用例可不能只执行不输出。所以我们今天搞定它！

tips: 最近虽然没更文，但是代码写的进步比较超前了，我也有点不太适应现在的模式。

我们把每次用户的执行，算作一次构建，今天要做的就是生成这样的构建数据。

站在巨人的肩膀上

以jenkins为例，它的每一次触发都会生成一个构建记录。

我们有好的产品去对比学习，这样我们就会少走很多弯路。

以上图为例，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方法

新建这样的数据，利用aiomysql进行异步操作。把核心数据传入: 环境，执行人，模式。因为我们这里目前还只支持手动执行，所以mode一般写死为0。

其实代码没啥难度，理解就好。简单的说就是新插入一条数据，但是不是完整的数据。

update方法

在执行过程中，可能需要修改构建的状态。比如我们构建如果被用户手动停止了，我们需要把报告状态改为已停止，所以这边有个update的方法，一般是用来修改状态的。如果后续还有其他的数据要修改，也可以调整一下这个方法。

end方法

当用例结束之后，我们把搜集到的所有数据都回写到这条数据中。利用mysql主键的特性，保证我们每次新增的id都是唯一的，所以数据并不会串。

新增并发执行用例方法

在Executor类下面编写静态方法: run_multiple。

具体的并发过程和之前差不多，注释已经写的很清楚了，从step1到step5.其他无非是一些获取用例执行数据的信息。

最后为啥需要返回report_id呢，因为前端页面通过report_id可自动到达报告页面。

想象一下:

前端通过访问: /report/4就可以拿到对应报告的数据，那就打通了整个执行->报告的过程，虽然目前还没有自动执行那一步。

今天的内容就到这里结束了，下一篇讲编写构建历史页面，类似于jenkins左侧构建记录。