时隔多日，随着中间插入的篇章【测试圈相亲平台】的完结，接口测试平台重新更新。不过最开始的篇章的很多设计都比较老旧了。大家其实可以不用一句一句跟，看个设计，混个眼熟，熏陶一下即可。
而接口平台的搭建，其实我更推荐用【测试圈相亲平台】的技术来重构，不过本公众号系列暂时就不从头再来了。毕竟这个教程里融合了很多粉丝的热情投稿和献计献策，所以重构还是放在未来吧。我们先解决眼下的这个新的并发功能底层。
回忆了一下上节，我们貌似一直在写具体步骤step的请求，现在回头一看，这代码量是真的庞大且复杂，毕竟功能点太多了。
我们之前写到并完成了加密策略这步骤。
接下来我们先把证书融合部分写完：
然后再考虑这个写入数据库请求数据的问题。
注意，我们这里有俩部分红圈内都是关于写入报告数据库表的。因为我们设计逐步实现，所以判断下方的这个写入数据库的函数write_res是无用的， 请删除：
原因如下：
最终的报告是多个并发的用例合并，而每个用例此时又有n个小步骤，每个小步骤既有自己的请求数据，还要有返回值的断言。最终的结果统一起来，才是完整的报告。
而整个wqrf_run_case.py文件，仅仅是负责一个用例的请求过程。最终控制多用例并发的功能和整合报告的功能 应该在它的上一层文件中实现。
针对这种复杂的结构设计和高度定制化需求，市面上的一切已有单测框架都不会满足。所以我们只能走出自研这一步。
既然wqrf_run_case.py文件只负责一个用例及旗下步骤的请求和结果，那么我们把这些结果存到数据库后，只代表一个用例的结果。所以上一层控制并发的时候，要去数据库提取出参与并发的用例的结果并合并。这就决定我们的数据库报告表的设计，只能以具体小步骤为基础单位 存放。
比如这样：
| 步骤id |
请求数据 |
返回数据 |
断言结果 |
| 129391 |
{} |
{} |
{} |
| 491941 |
{} |
{} |
{} |
上一层的函数在决定并发用例和整合结果的时候，就要从这个表中，提取出下面用例旗下的具体步骤的最新数据，并整合。
所以本节课我们需要先来设计下数据库表结构：
打开models.py：
先说下，这些自动为什么有的用默认值{}
因为在面对如此多维的数据存放在一个小小单元格的时候，最好的免失真办法就是用json字符串存储，所以我们之后从里面拿数据解析也是要把json拿出来转换为字典。但是为了防止如果为空字符串的情况转换字典报错，所以这里要设置成{} 即空json。
别忘了执行同步命令：
然后我们就可以把小步骤的请求数据放在这里面了，想放多少放多少。
今天内容到此结束。欢迎下期继续！
