本框架大部分代码都是有详细的注释，配合此教程系列，把流程梳理通应该是没有什么问题。在梳理流程的时候，可以使用debug模式进行运行，可以看到详细的代码执行过程。
ios如果已经配置好了相关环境，可以通过tools文件夹中的start_ios_devices.py文件一键启动ios的WebDriverAgent服务。
框架执行流程图
流程非常简单易懂：
1、首先是调用主函数进行获取在ini已经标记的设备id
2、每有一台设备则开启一个进程
3、每个进程针对该设备向测试文件传入设备id并执行ini中所勾选的测试用例
4、执行测试用例，用例由用户编写，可以再开启线程执行，具体根据需求
5、生成测试报告于Reports文件夹中，并配有相关截图在报告中展示
主功能逻辑
主要就是这一段
# 获取TestCase下需要启动的设备列表
runDevicesList = list(getAllTestCase().keys()) #拿到的设备名称全是小写，全是config的锅
print('当前标记的设备列表：',runDevicesList)
# 判定配置表里面TestCase下的设备是否在线
for device in runDevicesList:
if device not in [x.lower() for x in allDevicesList]:
print(f'\033[31m{device}设备不在线，可能未开启WebDriverAgent服务，请在tools文件夹下启动start_ios_devices或检查设备是否配置好相关环境!\033[0m')
# 只有在TestCase配置项下配置了,并且在线的设备才会进行运行
d = dict(zip(range(len(allDevicesList)), allDevicesList))
for k, v in d.items():
if v.lower() not in runDevicesList:
d[k] = []
finalDevicesList = [v for k, v in d.items() if v]
print('等待跑用例的设备列表:',finalDevicesList)这一部分就是获取ini文件中devices的列表，同时需要判定该设备是否在线，只有在线才会开启线程进行执行。
需要注意的是，读取config.ini文件后，所有的字母都会变成小写，所以这里面我加了一个.lower()的判定。
主函数核心功能讲解
进程的开启。
pool_list = []
pools = Process(target=enter_processing,args=(i,MD,start,))
pool_list.append(pools)
for pool in pool_list:
pool.start()
for pool in pool_list:
pool.join()每个线程都去执行enter_processing函数，这个函数里面会再去调用执行用例的方法，RunTestCase.RunTestCase()
if (startflag=="Success"):
RunTestCase.RunTestCase(MD, start) ################ 用例在这运行
print("{}完成测试".format(devices))
else:
print("{}未运行测试。".format(devices))通过RunTestCase.RunTestCase()去执行对应用例。
红框处为本框架最核心之处，大概讲一下这个算法逻辑。
1、由于我使用的报告为unittestreport，这个报告的执行器是通过discover去遍历文件夹下的测试文件，所以我是基于此，去设计的。
2、discover是遍历所有的测试文件，而我配置文件中是自己选择了执行哪几个测试文件，那么如何只选择我勾选了的呢？
3、通过_tests属性，我们可以拿到对应discover所遍历到的测试用例相关信息，通过split切割拿到和配置文件中名称一致的测试文件名。
4、通过exec动态导入测试类，这一步可能会比较难理解。
5、拿到了一致的名称，再通过suite.addTest()将测试类加入到我们的测试套件中执行。
这个地方就来重点了，如何将设备的id传递给用例去执行呢？
suite.addTest(ParameterizedTestCase.parameterize(eval(x['test_class_name']),device_id=device_id))就是这一句咯，那它是如何执行的呢？我们下一期再见！
下期预告
unittest的testcase外部传参函数剖析
