开始正文.... （为了报告数据收集开发，我必须先准备好数据才行，所以需要先实际的请求并发的用例，才能产生数据库数据。这个过程因为我没有对之前的wqrf_run_case.py进行过测试，所以大概率是有bug的。所以这个阶段我们顺便也要来自测和解决bug。）
首先我新建了一个项目：
然后进去，再新建两个空白接口：
接口的设置上，我准备用自己平台的某些接口做测试：
还记得我们之前做测试用自己写的俩个接口么？
俩个测试用接口都是很简单百分百可以调用成功的。我们本次的目的是测试bug：（测试并发用例的时候，用例1 的step会跑到 用例2的 报告中）所以接口能否调通这个问题上我们就不要再给故意弄的太复杂了。
然后平台的接口库的俩个接口开始设置调用 test_api_A 和 test_api_B , 然后顺手调试一下，看看能否调用成功：
然后我们去用例库，新建俩个大用例：
然后依次设置，选择仓库接口后，输入新步骤名字， 左下角大用例名字即可。
目前每个大用例我们只用一个步骤，用例1 调用 接口1 ，用例2调用接口2
然后别着急，我们为了保证大用例正常，所以需要先单独运行一下，看看报告是否正常。之后再去测试并发功能。
大用例1单独运行：
结果是成功的。
大用例2单独运行：
结果也是成功的。
好了，然后我们开始正餐，测试并发功能。
先别着急，我们先来梳理一下，点击并发按钮后的每一步。
这个过程叫做代码走查，属于静态检查的一部分。在我们日常的开发活动中，是经常需要这么做的。
从前端的并发按钮开始：
然后是这个按钮的作用：
原来是发送了一个请求给后台，并且带上了项目id：
该路由url关联的函数如下：
注意，其中的引入似乎出了问题，被划了红线。于是修改成如下即可。
然后梳理下这个函数：
先是找出了项目下所有参与并发的用例id 列表。
然后用了多线程的方式，同时启动wqrf_run_case模块内的main_request主函数，并传进了所需的项目id。
那么这个main_request主函数的逻辑，就是通过用例id，拿到下面的所有小步骤，并且循环依次调用do_step函数来真实请求。
而do_step函数一边请求，一边也把请求的数据，返回体，断言结果 写到了数据库中，以便于之后点击并发结果的时候用到。
整个过程就是这么简单，现在梳理一遍后，是不是感觉非常清晰了？
那么本节课到此结束，下节课我们开始正式测试，并且观察数据库数据了~
别忘了点赞和分享哦~
