adb install 也一样会在手机上弹出个确认框，现在手机大多做了 adb 远程安装限制

值匹配，针对字典{"a": "1","b": "1"}类型

expect_format = Matcher({
"a": "1", # a key 存在，值为"1",
"b": "2", # b key 存在，值为"2",
})

值类型匹配，针对字典{"a": "1","b": "1"}类型

expect_format_2 = Like({
"a": "1", # a key 存在，值类型为 type("1")
"b": "2", # b key 存在，值类型为 type("2")
})

数组值类型匹配，针对数组 - 字典 [{"a": "1","b": "1"},{"a": "1","b": "1"}] 类型

expect_format_3 = EachLike({
"a": "1", # a key 存在，值类型为 type("1")
"b": "2", # b key 存在，值类型为 type("2")
})

看是要做值校验，还是值类型校验

把人带歪了啊，这么想搞测试平台，去做开发不好么？

依赖第三方的数据 mock 掉，如果有第三方回调的话自己调用下就行

满满的干货

我不是说分享不好，只是感觉那些分享大多是个人用来学习技能的项目，实际落地效果可能会堪忧，感觉大家有点浮躁，偏离了测试的本质

我觉得这才是设计测试平台思路，从解决用户痛点出发；现在论坛里好多都在分享测试平台开发帖子，感觉基本都华而不实，有点本末倒置了

没定位到元素

是不是没在手机上装证书？

这个不用一个个字段写啊，一般把实际返回的数据复制进去再改改就好了

我不是大佬 ；契约测试我也研究过，也搞过一个 demo 出来，最终落地不了了之，网上也没啥比较成熟方案；这个比接口测试的层级更底一点，属于测试左移的范畴，越底层的话，写脚本需要投入的时间就越多，我觉得从接口层搞起来比较合适，先把接口层的覆盖的差不多了再考虑往下层考虑。

现在环境已经这么恶劣了么

我搞不懂为啥都想往平台化发展，是测试组规模已经大到要平台化协同，还是说单纯的想学点新技术

太多了，有点无从下手的感觉

我感觉你是开发，站在测试的角度，如果是老接口，我可以接受没值的字段不返回的情况；如果是新开发的接口，我会当 bug 处理

你想的太理想了，如果接口文档能实时更新，前后端开发完全按照文档来，那这个自然没问题，但是实际项目中很难做到这点，至少我经历的公司做不到这种程度；管理终究是人来做的，是人都会有疏忽和懈怠，有技术手段去做一个补充的话我觉得更好

我想问下楼主发这么多帖子是想拉人去培训么？

这个应用面有点窄啊，页面数据有变更的怎么办？

个人建议不要把用例写在 excel 里面，这个看起来做到数据代码分离，但是写起来效率很低，还要封装各种关键字，后期如果接口变更也很难维护，直接写 python 脚本是最好的。开源工具的话可以看下 httprunner

看要生成脚本来干什么用，录制脚本去做接口测试是可以的，能节省些工作量，这个 fiddler 跟 jmeter 都可以做到；录制脚本去做接口自动化的话，在 jmeter 里面也不好维护，也比较难扩展，我比较倾向的做法是 fiddler 抓包，导出 har 文件，再根据 har 文件按照自定义的模板生成脚本，httprunner 的录制回放就是这个思路

props 是父组件向子组件传参（你这个子组件只绑定了 pieData 参数吧）；sync 是子组件向父组件传参，就是个语法糖的用法，本质上跟 v-on 是一样的，只不过不用自己写。

sync 修饰符了解下，使用起来比你这个示例简洁一点
https://www.jianshu.com/p/6b062af8cf01

fiddler，jmeter 都可以抓 https/http 的包
wireshark 可以抓到 tcp/udp 层的包，也可以抓到 https/http 的包，只不过 wireshark 没证书，https 的包都是加密的，看不到明文

就抓包工具而言，fiddler 使用体验比 jmeter 好太多；用录制的方式生成脚本，很难一键运行成功，而且很多时候要维护自动化脚本，需要做些封转分层之类的，这个就不太合适了。
总而言之，fiddler 抓包比 jmeter 好用，录制功能意义不大。个人见解哈

我去体验了下，理性上来讲，基本功能是有了，只是比较粗糙；我最抗拒的一点是用例要一条条自己填数据进去，这个太浪费时间了，如果要在项目中使用这个平台，我想我是拒绝的