该文原创为新潮质量保障技术团队中的 “上进的中年软件测试从业者”，用于技术交流分享

2 月 10 日，地铁上最多不超过平时 1/5 的人相互之间自觉的隔开距离，而且有空座也不坐的那种，我刻意站在了车厢的连接处，今天是公司正式在办公区复工的第一天。老婆担心疫情太厉害想开车送我上下班（疫情有利于家庭和睦一点也不假，从未有过的待遇），结果车因为二十几天没开打不燃了。。打不燃了。。。。老婆在家打电话找保险公司救援处理，我骑单车赶地铁去公司。

测了三次额温，外加洗了一次手后，时隔十七天再一次打开公司的电脑。严格来说，没有任何的恐惧，虽然我比以前怕死。反而我更期待能够切实的开始工作。

01 开篇

从事互联网开发/测试工作的同学，肯定对定时任务或多或少的都有了解，实现的方式和成型的产品有很多，如：

• Windows 系统自带的任务计划程序
• Linux 系统自带的crontab
• Jenkins 支持的定时构建（基于 crontab）
• java 语言的开源框架xxl job

定时任务的场景和作用很容易理解：

• 指定时间自动触发任务，如每周六凌晨 2:00 自动备份数据库
• 减少服务器压力的同时最大限度的同步数据，如想准实时的看到当前的测试进度，可以通过定时任务间隔 15 分钟去同步测试进度到测试平台数据库
• 当然也还有一些骚操作，如凌晨 1:00 发报告给老板

定时任务的两种触发方式：

• interval：间隔
• cron：定时

我们上面有提到，对于 java 开发者来说，xxl job 可以作为很好的定时任务管理工具。但是对于 python 开发者来说，应该如何处理呢？

02 调研

最开始只是想通过 cron 的方式定时执行测试计划，所以设计上面就很简单：

• 测试计划执行时间只包含小时、分钟
• 另起一个线程来监控当前时间并扫测试计划，时间到了就执行对应的测试计划

紧接着就发现测试平台需要准实时的拿到项目的测试进度，那就需要因为 Interval 这种方式来实现，也为了长远的打算，所以又做了一次调研，从搜索出来的结果来看，好像没有别的选择：

APScheduler 提供了两种调度方式：

• BlockingScheduler
• BackgroundScheduler

采用BlockingScheduler阻塞的方式执行，发现服务根本没办法启动，所以在这里并不适用。BackgroundScheduler 为测试平台选用的定时任务调度方式。

03 实现

初始化

定时任务配置

了解 crontab 的同学，这里很容易就能上手。包括 trigger 的方式，触发的时间等。这样很容易就实现了定时任务的执行。

缺陷
随着平台的使用，慢慢的我们发现了一些问题：

• 如果想更新执行策略，必须要重启服务。
• 如果莫名其妙的，所有的定时任务都会丢失，只能重启服务自动加载。

04 调优

上面我们有提到当前实现的方案有缺陷，针对上述的缺陷我们做了如下的改进：

• 采用 mongo 作为定时任务存储媒介
• 利用 flask_admin 框架来实现对定时任务的管理（篇幅过大，下一篇介绍）

定时任务存储媒介变更

• max_instances: maximum number of concurrently running instances allowed for this job（翻译过来就是并发执行 job 的 instance 数量，如当前的 job 有排队的情况，可以设置这个参数）
• add_jobstore：第一个参数为存储方式，如 mongo; client：用 MongoClient 进行连接的客户端。

05 结语

下一期我们将继续介绍定时任务第二篇（flask_admin 对定时任务的管理），里面主要是小丹来牵头实现的。

解决难题的时候，相信大家都会有这样的感受：你以为翻过了一座山，面前却是一条河，是过河继续穿越未知的草地，还是翻山回去，还是选择原地不动。不同的选择有不同的结果，我们尊重所有的决定，但是同样也要接受不同选择而带来的不同结果。
很意外的是，公司居然上了热搜，也有朋友发消息求证和问候。
意料之中的事情，反而不想有太多的想法，顺其自然做好自己就是了，但是如果你是一个经营者，这次的免费营销是不是棒棒的。反过来自己又有了偷懒的理由，今年是真没钱投资自己了。另外今天也证实了一件事情，连续戴几个小时的口罩后，耳朵真的会痛。
还有，感谢所有关心我的人（居然有哥们要送我口罩这种硬通货）。

第一天正式办公我还 OK。