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方法

dao/test_case/TestReport.py
dao/test_case/TestReport.py

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

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

📙 update方法

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

🍦 end方法

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

📙 新增并发执行用例方法

新增run_multiple方法
新增run_multiple方法
接口实现
接口实现

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

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

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

想象一下:

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


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