在上节课我们初步完成了并发后，很多同学都发现了一个bug。
就是利用htmlrunner生成的测试报告会出现内容显示位置错乱的问题。
比如A和B俩个大用例，单独执行，会生成俩个大用例报告，互不影响。
但是当A和B同时一瞬间执行时，就会互相问题，比如A报告同时显示了A B的内容，而B报告空白.....
这个问题，经过我深层实验后确认，罪魁祸首就是这个作为母体的run_case.py中的Test类。
还有这些设计技术：关键字驱动，闭包动态生成，多线程并发，测试平台用例-步骤设计，防干扰初始化设计 等等。
没想到单独都不错的设计，放在一起后会产生如此糟糕的化学反应。
针对这个问题，我的解决思路大概有以下几种：
1. 每个用例生成不同的实体.py文件，防止Test类实体被共享冲突。执行后自动删除.py文件即可。
2. 做个并发专用.py脚本，融合所有大用例，在同一个.py文件中生成多个Test类，然后直接运行该脚本即可。
3. 弃用unnittest技术，unittest技术的优点在于手写用例脚本的灵活和多种断言等等。但很显然，在该测试平台的封装下，用户只能在页面上进行接口的用例设计，代码层面已经写死，unittest也好，pytest也好，最大的优点无用了，性价比都变低了。或者说，我们平台需要的仅仅是一个底层执行接口请求的引擎，而非一个面向用户变成自由自在完善的一整个测试框架。
所以出于性能，便利，问题修复，升级空间来说，是时候打造一个接口测试平台的专属底层驱动和专属测试报告系统了。
好了，针对上面的三种设计，其实都可以成功完成最终解决这个问题，那么到底应该选哪种设计呢？欢迎小伙伴在下面投票，博主将会根据投票结果来选择实践方案。
这里要说明一下，本教程接口测试平台没有名字，也不准备取名字，我不希望大家把这个平台当做完成品去看待，它仅仅是读者们初入测开领域的第一个教程项目而已，在这个接口测试平台的设计基础上，诞生了很多更专业更漂亮的其他平台， 甚至达到人手一个。
