我觉得你这个思路有问题，A 设备做了 xx 操作，会在 B 设备体现，为什么不分离开？A 设备操作了，操作的对不对，你看下数据存储的地方，比如 sql 或者消息队列或者缓存，做下校验，对了，那 a 就是对的。B 的体现，你就先造好数据，在 b 上看就的了。

为什么非要搞到一起尼。万一 A 设备操作错了，B 设备处理错了，两者结合反而达到你预期，你能说你的 case 成功了，没有 bug？

自动化场景怎么设计？那你写自动化是为了回归，究竟是回归什么尼，是想所有 ui/case 都去回归吗，还是单纯为了 kpi？不要为了自动化而自动化。。。

pre test 里写个值作为参数，每次执行 case 时，先执行 pre test 获取值，然后把这个值传到一个你写的获取 roleid 的方法里。只要你这个获取 roleid 方法足够强大，那基本啥情况都能满足

大佬，十几天前招测试开发 12-18k。现在这个 45k，是不是太不公平了。。。。

大佬求持续分享

“服务端：掌握接口测试、抓包工具使用、如何校验接口的完整性”

杠一下，我觉得抓包工具使用应该被归类为前端测试，尤其是移动端 app 上更合适。
谁同意，谁反对？

是不是·合肥有分公司？

看 yaml 不支持 ios？

你这 ssh 和界面化连接数据库有啥区别

全局代理怎么弄。。求教

这个帖子还有大佬在吗。。求助，怎么做

nice！！良心哪

感觉很适合 35 岁以后国内厂干不下去的 qa。。。对了，这个对年龄有要求（歧视）嘛

微信版本问题，据说是要用 7.0.14 版本能解决

百度一下，你就知道！！！！！！

我们这用户体量是比较大，android 端日活 60w，ios，30w 左右。。leader 层次都知道的，人力问题暂时解决不了

不是，这个确实是占性能的，因为后端已经已经计算好了某个瞬时值，前端显示需要动态的，这个要求 1s 计算好几次，而且每次上百万用户。所以理论上 1s 有 500w 次计算，其次就是 500w 次的推送，还是比较耗性能的。单元测试的事情，确实想到了，还是要看代码

下单已经做了自动化了，下完单去查数据库校验前端传参数是否正确。但是像可用余额这种，纯前端计算的，没有接口提供值做对比，自动化从界面拿到值方便，但是怎么断言这个值是否正确？自己去写一套公式不现实的，相当复杂，依赖好几个接口，ws 的推送计算得来

人多了都好做，主要就是人力不足。下单，2 种交易产品 6 个模式，5 种下单方式，2 个方向（买/卖），3 种条件，2 个触发方式，我算了下，下单有 200 多种情况，这个已经用脚本解决了。然后类似于 avbl 这种，纯前端计算，公式极其复杂，如果仅仅是针对这个公式测试，就要准备 20 多条 case，更别说还考虑上其他交互上的。然后类似于 avbl 这种，全靠 app 前端自己计算的点还有 4 个点。这些公式复杂到什么程度尼，就是这个本可以放到后端计算的，但是因为考虑计算复杂及实时性，比较占用服务端性能，所以放到前端。

多谢🙏，学习下别人是怎么做的

这个不现实啊，前端测试的人少，公司大部分投入在后端测试上

3 周 1 个版本，版本里很多新功能。。每次发版本后，几乎都有 hotfix 版本

我这个是核心业务，客户投诉，大老板，cto 都能看见，影响很大，而且很明显，这种问题，上来就是，测试没测出来的锅啊

前端 bug 很影响用户体验啊，影响很大

感谢，找到了。。