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

以前大会也有听过直接在测试机安装 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 个告警是否有异常了。如果按照这个思路兜底，我理解更合适的方案是，审计的时候自动计算 总应付金额（基于订单表计算）是否等于 总实付金额（基于资金流水表）+ 使用的优惠券对应金额（基于优惠券使用记录表计算），这样应该会更准确？不过我觉得最简单的是，兑换券一人最多可拥有多少有个上限，直接查有没有人超过上限即可。

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

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

我这句是针对你前面的 搞测试自动化，写代码、coding 测试用例是最正确的姿势 才特意补充的。

你这句话我的理解是，只要不是用写代码、coding 的姿势搞测试自动化，就不是好方法，死路一条。
我想表达的是：就算用的不是写代码或者 coding 的姿势搞自动化，只要能有效果提高效率的就是好方法。

直白点说就是，我不认同你的观点。

才看到正文补充的第一次执行报错。。。

你把 node_modules 文件夹整个删掉，让它从零开始重新下载吧。你第一次报错意思就是有个库需要从 github 下载源码，但你的网络环境让它死活下载不下来。。。

写代码最灵活，也最容易接触底层，了解更全面。可以理解为是最正统的方式。

但不代表每个人都必须要这么高的灵活度和深入度，对企业或者公司来说，招少数人写平台或框架，多数人直接基于这块写用例，性价比更高。现在行业还没完全提高到随便一个测试人员都能直接 coding 写自动化用例的水平，会 coding 和不会 coding 还是有成本差异的。

个人观点：正统方向要有，但也不能一刀切。只要能帮助团队提高效率的，都是好框架。好框架不等于需要百年长青、面面俱到，能解决当下问题就很足够了。

PS：就算 coding ，也要有相对统一的规范才好协作的。开发有各种比较明确具体的分层架构（MVC、MVVC 等），而且都是业内相对通用，换家公司还能继续用的。但测试这块目前太少了，基本都是各家自己定，而且内部还不一定能全员都理解和用对。缺少统一架构的 coding ，维护起来比天然就能统一写法的平台或框架，更痛苦呀。

整个实践挺完整的，不错，特别是考虑到了用例依赖这个点，对流程类用例挺有用的。提个小建议，后续这类记录除了结果，可以加入一些背景以及思考，背景便于别人了解前因，思考便于自己发现不足，下一次做的更好。

好奇问下，用 yml 这种方式，用例编写及维护体验如何？

个人感觉相比 excel ，好处是可以支持更灵活的结构，对版本管理也更友好（excel 是二进制文件，不好看出每次改动 diff），缺点是批量处理时相对没 excel 方便，然后各种缩进容易踩坑。但实际项目只用过 yml 来做配置，没试过用 yml 写用例，想了解下实际写起来感觉如何？

请说出你的故事~

主要还是 wda 得另外弄开发者证书会麻烦点吧，不过目前好像没见到其他可以绕过这块的解决方案。

找运维拿线上正式的 ssl 证书，加到 filddle 里面。

慢慢积累就好，非专职性能的一般不会要求太深入，掌握大概思路就好。具体技巧工具用到了再去学就行。

npm 有配置过国内镜像么？看报错是有的依赖没找到。