是的，这是另一个方向，我们也在实践

非常抱歉，迟来的回复
比方说：
手机有很多 sku 属性 和 spu 属性：
Spu 属性一般包含：品类、品牌、型号
Sku 属性一般包含：颜色、网络制式等

在不同的系统中属性的 id 以及属性 id 的值 可能是不一样的（有一些定制化操作），运营同学会把 A 系统 与 B 系统 的不同 spu 和 sku 属性 做一个映射关系，保存在数据库中。开发同学在拿到 A 系统传过来的属性时，需要根据映射关系，映射出来最终的结果。

比方说：
A 系统中 spu、sku 属性为： 手机、华为、荣耀 5
Sku 属性为：颜色：白色、网络制式：移动 4G、联通 4G、电信 4G
Spu 映射关系为：
外部品类 外部品牌 外部型号 映射后的品类 映射后的品牌 映射后的型号
手机 华为 荣耀 5 手机 荣耀 荣耀 5
需要测试：B 系统是否能够通过映射关系，映射出来了手机、荣耀、荣耀 5；

Sku 映射关系为：
颜色\网络制式 映射后的颜色\网络制式
白色 深空灰
移动 4G 移动 4G
联通 4G 联通 4G
电信 4G 电信 4G
移动 4G+ 联通 4G 双网通
联通 4G+ 电信 4G 双网通
移动 4G+ 电信 4G 双网通
移动 4G+ 电信 4G+ 联通 4G 三网通

需要测试：B 系统是否能够通过映射关系，映射出来了深空灰、三网通；

如何进行呢：
1、 拿到运营同学维护映射关系【已知的映射关系】
2、 使用 python 脚本 pandas 进行筛选，入参为手机、华为、荣耀 5；然后把筛选结果与开发的结果进行比对；来判断开发写的映射关系逻辑是否正确。
3、 入参为白色、移动 4G、联通 4G、电信 4G；然后把对筛选结果进行遍历逻辑处理，然后获取结果，来判断开发写的映射关系逻辑是否正确。

抱歉，迟来的回复
比方说：
手机有很多 sku 属性 和 spu 属性：
Spu 属性一般包含：品类、品牌、型号
Sku 属性一般包含：颜色、网络制式等

在不同的系统中属性的 id 以及属性 id 的值 可能是不一样的（有一些定制化操作），运营同学会把 A 系统 与 B 系统 的不同 spu 和 sku 属性 做一个映射关系，保存在数据库中。开发同学在拿到 A 系统传过来的属性时，需要根据映射关系，映射出来最终的结果。

比方说：
A 系统中 spu、sku 属性为： 手机、华为、荣耀 5
Sku 属性为：颜色：白色、网络制式：移动 4G、联通 4G、电信 4G
Spu 映射关系为：
外部品类 外部品牌 外部型号 映射后的品类 映射后的品牌 映射后的型号
手机 华为 荣耀 5 手机 荣耀 荣耀 5
需要测试：B 系统是否能够通过映射关系，映射出来了手机、荣耀、荣耀 5；

Sku 映射关系为：
颜色\网络制式 映射后的颜色\网络制式
白色 深空灰
移动 4G 移动 4G
联通 4G 联通 4G
电信 4G 电信 4G
移动 4G+ 联通 4G 双网通
联通 4G+ 电信 4G 双网通
移动 4G+ 电信 4G 双网通
移动 4G+ 电信 4G+ 联通 4G 三网通

需要测试：B 系统是否能够通过映射关系，映射出来了深空灰、三网通；

如何进行呢：
1、 拿到运营同学维护映射关系【已知的映射关系】
2、 使用 python 脚本 pandas 进行筛选，入参为手机、华为、荣耀 5；然后把筛选结果与开发的结果进行比对；来判断开发写的映射关系逻辑是否正确。
3、 入参为白色、移动 4G、联通 4G、电信 4G；然后把对筛选结果进行遍历逻辑处理，然后获取结果，来判断开发写的映射关系逻辑是否正确。

好啊好啊

数据管理：
Case 所需测试数据，有专门的文件存储测试数据，有特定的方法提取测试数据，所以编写 Case 的时候，补充好就可以了。
Case 执行所需的前提条件数据：会有方法进行数据创造，之后再执行测试逻辑
Case 执行过程数据：Case 执行过程中，会产生 框架 log ，Case 执行 log，Device log, 失败时截图，及 Case 视频，log 及截图，本地会保存文件，也会在执行结束后通过平台接口，上报给平台存储，方便通过平台查看 Case 执行过程，Case 视频会直接上报平台 ，不会本地存储，文件的存储会使用 ftp, 测试结果及执行信息 会存储数据库
Case 执行产生的应用数据： 会在测试结束后，通过特定的方式，将产生的测试数据进行清理

Case 分量执行建议：
如笑哼所说，框架本身有配置开关控制，是否在使用多设备时，进行 Case 分量执行，各执行一部分，设备越多，使用的时长会越短
测试平台方面：有一个后续的计划，一直都保留着 Case 在 各个设备 及版本上 成功 / 失败的执行耗时， 可以利用这个数据，在选择 Case 列表 和设备后， 根据历史数据，进行计算，计算出，预计最短时长的分配方案，尽量保证各个设备使用的时长相近。

Ui 框架本身，可以设置失败重试次数，当 Case 执行失败时，会立刻进行重新执行，结果会分开保存。
测试平台，因为框架本身有重试测试次数设置，所以也可以配置重试次数，下发任务执行
测试平台本身，也提供了批量重新执行的策略，在一次测试记录的测试结果页面 或者 测试计划配置页面， 可以一键触发 重新执行，上次执行记录中的所有失败 Case，重新执行前，可以更改分配的设备 和 使用的被测应用安装包

现在：
设备管理方面：我们在做一个设备管理平台，已经上线试用，主要是分布式管理，在多台设备上安装 Agent 服务，实时与设备平台同步信息， 设备平台也会下发任务给 Agent 服务，指定设备执行特定的任务
设备控制方面：Android 如笑哼所说 暂时接入 STF，iOS 还在调研，可能先试用一些各位大佬已开源分享的方案

以前：
UI 框架： 执行时，会 获取已连接设备列表，获取当时 预使用的 Appium 端口占用情况 ，根据执行时设备的选择（配置的设备平台 和 是否指定了设备），为设备分配端口执行
测试平台未接 设备平台时，本地服务异步更新设备连接状态，设备有 是否被占用 & 是否连接 两种状态，用来区分设备是被测试占用，还是未在线不可用，哪些是已连接并且可用的。端口处理同框架。设备基础信息的存储

可以结合 minicap 实现无页面 实时 录制屏幕么

可以只用一条命令同时启动 Worker 和 beat ，在启动 Worker 的命令里加一个 -B 试一下

wda 的问题解决了么
dyld: Library not loaded: @rpath/XCTest.framework/XCTest
求助