1、iPhone 是装上了 wda 但不能启动，还是连 wda 都装不上？
2、装上了不能启动，iOS 系统日志里应该会有更详细的错误信息，是否有抓取查看过？（用 mac 自带的 控制台 ，设备悬着那台 iOS 设备，就可以看到了）

模拟器相比真机，一些校验是会被省略掉的（比如应用签名校验），所以模拟器能起来，说明程序本身没问题，出问题的应该是在你的配置上。

你修改下你的正文吧？你的问题不是要怎么去做自动化，而是你觉得你现在的方法不大好，想看下有什么可以优化。

可以把你现在用例怎么写的，也举个例子说明下吧，要不不知道你用的方法和大家理解的是否一致。

同样后台搜索不到。 @Lihuazhang 有空看下？

iPhone 上面已经有 webdriveragentrunner app 安装了，但是好像无法启动？

看下 iPhone 的日志输出，看有什么报错？

另外，你用 xcode 界面启动 wda ，有启动成功么？（启动成功会看到在 running ，并且 xcode 底部有应用日志打印）

额，不至于吧。自动化的我看你问自动化的问题，应该已经有基础了。至于说清自己测试业务核心接口背后逻辑，问下开发应该也可以问到。

加分项不用关注那么多，基本要求才是核心。

直接写接口调用去调？grpc 可以直接根据 proto 文件生成不同语言的调用函数吧。

可以看看：https://testerhome.com/topics/28953

社招的基本要求是有一些自动化/写代码的经验，熟悉自己测试的业务，能说清自己测试业务系统核心接口背后的逻辑（类似技术方案里的时序图，先到哪个服务，后到哪个服务，服务间用什么中间件传输等）。能 review 开发代码，或者有做过工具平台有自己思考的，会是加分项。

现在还在招聘中，有兴趣可以直接投递简历给我哈：chenhengjie@lizhi.fm

这个不大方便那么公开说。。。

目前了解到的一些公司，提高设备使用率的方法基本都是把使用频率较低（比如机型用户量不大）的放到平台上，通过平台借用，减少大家手上长期持有测试机的数量。

以前大会也有听过直接在测试机安装 app 或者某个底层服务，只要网络连通，就自动连上云真机服务端随时用来跑自动化的，和你这个思路接近。实际用起来效果怎样，不大了解。

当然这只是我自己的思考，没有实际实践过，不确定是不是这些问题是否会这么突出。鉴于技术上是直接可行的，你也可以小范围试验下，看看效果？

有几个点想确认下：

1、你说的 windows、mac 上没问题，是这两个系统上的 jenkins 没问题，还是纯粹这两个系统上普通用户执行命令行没问题？
2、跑下 npm list --depth=0 ，看下你实际 npm install 装了哪些包；也 cat package.json 看看，是不是里面定义的 dependencies 都装上了？
3、可以把你没问题环境上的 npm install 和 npm list --depth=0 输出日志也补充上来，对比下有啥差别？

从目前日志上看，有两个比较特别的点需要留意，但需要先确认上面几个点：

1、npm install 没报错，但装的包有点少，才 6 个（added 6 packages, and audited 3909 packages）。一般前端项目应该不至于只有这么点依赖。
2、编译报错里面，除了少数是外部依赖（如 React），其他大多是内部依赖（如 /var/lib/jenkins/workspace/t/src/pages/TrailUser/register in ./src/.umi-production/core/routes.ts）。不确定是不是路径解析时根路径不一样或者别的原因导致。

你这个不解决稳定性问题呀。

举个场景：
张三在 atx 上用李四的华为 mate 10 测试，刚操作完一个用例正在登记 bug，李四刚好也要用，反正设备在自己手上，看起来也没在动，直接拔掉自己用了。张三登记完发现设备没了，没法继续用。

如果你是张三，来一两次这样的场景，是不是会放弃用 atx 而改为直接去借手机？

从设备拥有者角度，也有几个问题要解决：
1、怎么标识啥时候我想共享，啥时候我不想共享而是自用？这个标识方式尽可能要自动，手动总容易忘记。比如息屏时间超过 5 分钟自动进入共享模式。
2、共享到退出共享的这个时候，怎么通知拥有者现在有人在用，暂时不要退出共享，需要找使用者沟通？

个人更建议，可以直接收集一波日常使用率不高的设备（比如一周也就用 1-2 次的），统一放到云真机平台。谁要用都直接上平台用，这样可能更简单有效。

建议你趁着现在想法还热乎，抓紧时间看看 httprunner 的设计思路和试用一下吧。消化掉 httprunner 应该能给你带来不少新的想法思路。

很多框架毕竟不方便完整开放，有些设计思路不方便说得太直白，或者不一定通用。既然你已经找到了 httprunner 这个不错的学习对象，而且李隆也有在自己公众号持续分享整个过程中的设计思路和思考，先赶紧学起来吧。

先在无头浏览器里截个图看看界面和你正常打开有啥不同吧？

思路可以，技术上也可行。只是难点是怎么保障稳定性，毕竟每个 provider 控制权在每个人手上。

稳定性保障不了，这个借用方式可能很快会被放弃。

没有用 excel，测试用例就是直接写代码。只有在数据库校验的地方用了 csv 记录断言（要校验数个表共计数十个字段，写代码太累了）。这个断言也是可以自动生成的，一般很少直接编辑。

因为业务流程比较长，各个接口依赖上一个接口数据比较普遍，所以我们大部分是流程类用例。单接口各种不同参数组合的比较少。因为开发这类校验大多直接用 JSR303 注解做得，直接 review 代码 + 调试用例时人工调整下就够了，没有太多长期自动化回归的必要。

客气拉

先灌输理念，ABCD 都认同，再去做。用高大上一点的话来说，就是要先标准化，才能工具化平台化。

我们一般进入开发阶段前，会叫上各个团队的骨干或者最可能用这个工具的人，一起来参加我们的设计评审，说明我们计划做什么，解决什么问题，以及怎么做，做完后大家大概怎么用。评审时确认有什么地方是认知不一致的（比如有的业务场景和我们之前理解不大一致），现场讨论。如果讨论不出结果，这个功能就先 hold 一下，后面重新调研设计。

兼容习惯成本高，而且人员流动也会导致习惯改变。同时产品同个功能使用姿势太多样，新来的同学也会容易懵逼。

✖ Webpack
Compiled with some errors in 58.10s

Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
ERROR Failed to compile with 12 errors 8:42:33 AM

These dependencies were not found:

/var/lib/jenkins/workspace/t/src/pages/TrailUser/register in ./src/.umi-production/core/routes.ts
/var/lib/jenkins/workspace/t/src/pages/User/SetPwd in ./src/.umi-production/core/routes.ts
@/pages/Home/Widgets/Widgets in ./src/.umi-production/core/routes.ts
@/pages/Home/Widgets/tiles/weather/weatherUtil in ./src/models/weather.ts
React in ./src/pages/Home/Equipment/Components/ApplyTemplate/ApplyTemplate.tsx, ./src/pages/Home/Equipment/Components/ChangeDeviceStatus/ChangeDeviceStatus.tsx and 4 others

打包的错是因为缺少依赖导致，要通过装依赖解决。装依赖（npm install）的错贴上来看看？

目前有点迷茫，感觉辛苦写框架，还不如直接学 httprunner

我倒觉得你有这些思考，这个写框架的辛苦就很值得了，不要那么快放弃。你迷茫只是因为你还没想好自己框架的核心目标是什么，是要让没有太多编程知识的人也能用（易用性），还是让有编程知识的人用得更高效（灵活性），这块得想好。

建议可以先研究下这类问题 httprunner 怎么解决，然后再看看放到实际项目里 httprunner 是否满足，还需要扩展什么。

我们之前接口自动化框架基本就是用 testng + 各类调用库（如 http 的用 rest-assured）+ 报告生成库（extent report），主要编写是用 java 代码来编写的。相比易用性，更偏向灵活性。会要求有一定的编程基础，不过因为从整体团队角度，也希望借助这个让大家熟悉 java（至少会仿照别人的写法写）便于后面看开发代码，所以这个也没太大问题。

后台查不到， @Lihuazhang 看看？

1、fildder 是抓包工具，不是接口测试工具吧
2、接口测试相对会比较容易自动化，所以有不少人的用法是直接用可以自动化执行的方式来写接口测试用例的，反正成本差异不大，写起来也差不多（基本都是定义请求参数，然后校验返回参数，只是界面上写，还是 yml 或者代码文件写而已），还能让自己回归开发 bug 的时候直接一键执行，后面加入 CI 持续自动运行，挺爽的。当然实际情况还要考虑数据是否可以重复使用，不一定真的直接能重复执行哈，只是举个简单的例子。

httprunner 本身也可以简化一些写用例的成本（比如通过抓包保存 har 文件，直接导入后，写接口用例时只需要写各个参数的 value ，不用再写 key），也可以支持一些业务特殊的定制化（比如接口参数加密、不同的鉴权方案）以及流程化的接口自动化测试（比如电商的登录 - 选商品 - 下单 - 支付整个流程，印象中 postman 得付费版才有这个功能）。

也有封装成平台，体验和 postman 接近甚至更优的（比如开源的 meterphere，录入接口文档的功能后，写得时候连 key、path 都不用额外写，直接写 value 就好。一个接口多个用例时写起来更爽）。

接口测试的工具还是蛮多的，建议你可以多试试，找到最合适自己的。

不知道其他人经历，只说我自己的。一般只会针对比较重要的参数做比较全的测试，其它非核心的过一个有正常值 + 一个异常值就完了。

其实参数组合这块，我更喜欢先 review 代码看逻辑。因为很多比较通用的规则，实现开发就一个注解（JSR303）或者 controller 里前几行校验就搞定了。比如非空 @NotNull，指定范围 @Size(max, min) 。

这个就是看界面效果了，个人能想到就是通过截图或者录视频来判定。

推荐你看看视频类这些异常检测相关的文章，这块和普通应用 UI 自动化还是有点不大一样的。

没看懂你需求，你是要点 unselectable="on" 的元素？这个元素人工点本身可以点么？

想探讨下，这个告警误报率会不会很高？

从逻辑上看，只要用了优惠程度大一点的券都会告警，有可能 100 个用优惠券的，实际只有 1 个钻空子，但你就得检查这 100 个告警是否有异常了。如果按照这个思路兜底，我理解更合适的方案是，审计的时候自动计算 总应付金额（基于订单表计算）是否等于 总实付金额（基于资金流水表）+ 使用的优惠券对应金额（基于优惠券使用记录表计算），这样应该会更准确？不过我觉得最简单的是，兑换券一人最多可拥有多少有个上限，直接查有没有人超过上限即可。

文中第一个场景没看懂，之后在微信客户端对兑换券进行退款操作，然后再将之前客户端的订单取消 ，退款的意思是退掉兑换券么？如果是，那兑换券退掉可以重新领取，还是符合一个用户最多拿一张兑换券的规则，看起来没啥问题。

第二个场景，就是兑换券已使用（待支付）时，没有限制住不给退了，订单支付时服务端也没有二次确认兑换券是否有效，属于很明显的业务逻辑漏洞。一般这类场景，业务逻辑应该是这个券被使用了（待支付）就会进入锁定或已使用状态，无法退掉。取消订单的时候，才会重新退回。