如果单就标题的问题做回答，我的答案是单纯是录制回放肯定是不够的，接口自动化优点是目的性强，流量录制目的是查漏补缺成本低。

一般是先做接口自动化，再用流量录制回放来补充线下自动化的测试盲点，或者观察线上流量有没有特殊未考虑的情况。

线上事故⚠️

这是已经财务自由了吗

我就是在小程序/小游戏的业务里的，不过我是属于提供能力的一方，楼主是属于使用能力的一方。

1.小程序除了和 APP 类似的测试点之外，还有什么需要额外注意的吗？
其实也没有，小程序客户端关注的还是功能、性能、稳定性、兼容，都是业务视角出发就好。重点要注意的，就是产品所使用的小程序接口，可能会有版本兼容问题导致的前后表现/返回值上的不一致，甚至不可用。所以一定要主要留意，如支付宝小程序版本升级（小程序 SDK 能力接口的升级），要做好全面的功能回归测试。

2.是否可以使用模拟器进行测试？
可以是可以，但是不推荐，因为模拟器环境和真机肯定是有差异的（至于差异和影响是啥很模糊，参考公司内部有人做过的调研，主要是 so 库加载失败，包括 libjiagu.so、libX86Bridge.so、libshell-super.so、libDexHelper.so 等，这些库都是各大厂商发布的 App 加壳库，模拟器上的架构和真机有差异导致加载库失败就会出现 app 崩溃）；而且你在模拟器上发现的问题，研发肯定要求你在真机上看看能不能复现，再考虑当 bug 处理。既然如此，为何不直接真机测试，除非真的没有手机，那还可以考虑云真机。

3.当小程序稳定后，如何进行小程序的自动化测试？我可以学习哪些技能？（有 python 基础）
搜了一下，没找到支付宝有提供类似微信小程序的自动化框架，但是有人用 airtest+pytest 搞，看 链接。

4.针对小程序性能，我该如何测试？
和手机 app 一样，找个 perfdog 等性能数据采集工具，怼上去就是一通跑测试用例；再找一些同类业务竞品做想通口径性能数据采集和对比，结合来看你们家产品性能 ok 不 ok。

5.求推荐一本测试小程序或者 app 的书籍
实话说真没必要，小程序只是大前端技术栈的一个细分领域，况且还只说测试，如果这都能出书那必然是一本水书；至于 app 测试，我至今都没看到过一本好书。

在座各位都是诗人 说什么重新开始，还不如去鸡娃哈哈哈哈

个人从小到大的爱好是玩变形玩具（就是变形金刚、日本特摄超级战队那种），已经规划好准备拍玩具分享视频传 b 站了。
赚不赚钱就算了，买玩具本身很费钱，和楼上买基金一样是负业（别说了，我基金股票亏的够在老家几十线小镇买个二手房了😭……）

• 优化测试工作量视角：

  1. 梳理出哪些地方可能会多端不一致，依赖研发配合做，明确多端肯定一致的地方就不需要重复测试
  2. 不同的人拿不同端同时测试，依赖大家对 bug 的标准要足够一致
  3. ui 自动化 + 图像识别，但是没足够空余时间不建议上这种玩意儿，很不稳定

• 业务权重视角：

  1. 按业务优先级，先在多端上测重要的场景，时间不够就砍掉低优场景

针对最后多端不一致的问题，先提了 bug 再说，代表问题已经发现了，是否修复研发来判断，责任也转移了绝大部分。

是啊，之前没跟对老板，工作虽然努力，但感觉一直无效输出，做的东西不被认可的同时又不给有效的指导意见，就让我自个儿在那里摸爬滚打浪费时间。
最后跟 ta 沟通的时候，ta 竟然美其名曰：人自己不亲自做过 xx 事情，靠别人帮助才能完成，就学不会去做 xx 事情…… 难道这就是 ta 作为一个老板不帮助下属解决障碍的原因吗？

我也遇到过两任奇葩老板，但不至于这么离谱，虽然老板奇葩好歹多多少少还是有些收获（就是时间有点被浪费，本来可以有更多收获）。
工作越久越感觉选择大于努力，跟对业务、跟对老板，才是最重要的事情，只要这两个选择对了，很快就能兑现到一些收获。

我的观点：

1. 测试左移理论上是正确的，而且优秀高效的测试团队确实在不同形式实践测试左移的理念 —— 但是往往实践不会和理论一模一样，会做一些删减；按照测试人数被压到较少的常态现状下，需求都是倒排的形式插入，测试多数以配合交付为主，确实没有人力在需求最早期就参与进去的，属于心有余而力不足；如果真的能做到这种程度，我个人倾向于认为是外企、国企，或者很成熟的行业才能这么考虑人力利用。

2. 不做测试左移，或者没做好测试左移，不代表测试团队能力不足（作者没表达类似观点，我属于插播）—— 测试左移只是保障质量的其中一种手段，搞质量需要先认清当前测试人力容量，在能以至少及格分水平支持需求交付的测试之外，再额外做一些中长期对质量有改善的工作，包括但不仅限于流程改进、度量运营、灰度发布、线上监控、研发构建效率等很多不一定是传统测试领域的事情。测试左移可以适当投入，做到 70 分程度 ROI 就不错，如果要做到 80 分甚至 90 分，必然有边际效应。

3. bug 数作为绩效考核，听闻很多公司都会用这种办法去衡量产出，至少在大厂里对外包也会做 bug 数的横向对比以考虑某外包是否留下（还会结合该外包经手的需求质量）；可以说它粗暴，但是不能说明它不合理。因为想把它做得很合理是要成本的，当 “这个成本 超过 拍脑袋决定绩效 导致的损失” 之后，就显得无足轻重。所以它确实有问题，但除非能提出更好的办法而且足够低成本，不然…… 那就忍受

有些 SRE 团队确实是不配 QA 的，东西都是他们自测上线…… QA 资源不是所有团队都会配置，尤其是很多内部不直接面向外部用户的系统；至少我司在以前是没有 SRE QA 的，不过现在我记得是有了

是楼主理解错，还是我理解错。

tps = Transactions Per Second

Total Througput 就是吞吐，随着线程数一直提高（相当于请求总量也提高了），服务器那边有性能瓶颈达到上限了，所以 Transcation Response Time（不是 tps）的 95 分位数在升高，我感觉很合逻辑。

身边有类似的案例，但还没去到这种程度…… 我的建议：

1. 所以谈话保持全程录音，并保证对方说话要说完整，以便未来取证
2. 细看劳动法，防止自己被对方钻空子搞，也要去钻对方的空子；在合法完成工作的前提下，多出来的准备面试
3. 如果自己耗得起就硬刚，耗不起的话还是认栽尽快跑

实话说，运维系统团队还不一定有配测试呢……

别说磁盘空间不够，业务增长导致表唯一 id int32 位不够用出问题都见过……

原来标题的【一线】是指一线城市……单看标题还以为是逆天言论，测试竟然还可以不在一线

先坚定思想

IT 是一个挺卷的行业，这个行业很多人进来并不是自愿，而是因为相对其他行业稍微高一些的工资，所以大可不必去模仿大佬的生活，你自己的生活如果已经想清楚该怎么过就怎么过。

并不是每个人都可以逼迫自己去持续学习，对于你自己来说，所谓的【进步】也不一定非得是技术上的精进或升职加薪才叫【进步】，而是适合你自己的，让你的生活往下一个你更喜欢的状态去推进也是【进步】。

优秀的 IT 从业人员大多数也是因为热爱这个行业、热爱技术，既然楼主对技术不喜欢，或者说至少不感兴趣，那就没必要继续苟下去浪费年华。尤其是这种想离开/有退路的想法一旦种下种子就会一直发芽。

我的建议

废话不小心说太多了。当你产生这个想法并且上来论坛问，其实就代表着离开的想法已经足够壮大了，回老家考公上岸是很不错的选择。不然就是去个很稳定的国企外企继续过日子，但是得考虑被裁的长远风险有没有足够的资金应对。这个时候空闲下来多看看老家有什么机会，对应这个机会你要储备什么，然后针对性地学习（比如你要考公那就要学考公技巧和刷题）。如果你自主学习动力不足那就果断报班，永远不要高估自律能力。

有几个点其实深究就很难解释清楚：

1. 会做好自动化，会干性能测试，会分析性能问题 —— 这里的 “会”，到底去到什么程度？是因为熟悉业务所以有经验，还是因为技术思路、排查实践都很熟练？这里面前者并不一定通用，后者才是通用的硬实力，有时又要两者结合。所以 “会” 实在很难下定义
2. 一个增删改查的开发，多多少少也创造了产品，如果没有这些开发，连能给我们测试的东西都没有。所以谁是第一创造者，谁的钱更多也无可厚非……

1. 如果线下就能拦截所有 bug，那为什么还需要小流量、灰度、众测这些东西？有多少个团队能在线下发现全量 bug？还是说产品太简单……
2. 片面追求线下拦截所有 bug，要考虑人效和能力（是否允许足够长的时间测试，是否有足够多的 bug 发现手段），你的组长能拍出这样的决定，证明他对这些东西没考虑全面
3. 有些 bug 在当下迭代不会出问题，随着未来的用户量级提高，用户环境会越发复杂，或者未来某个代码变更触发隐藏问题，这种 case 那个组长怎么判断？又该不该扣绩效？

如果只会追责到人，不会分析事情本身，打绩效如此粗暴，证明这个组长水平有限。我建议是换老板、换团队、换公司任选一个。

云原生那本书有没有机会上到社区的积分兑换里面？

表示被 openssl 这玩意儿的版本坑过好几次，记得有两次是编译 python 源码，两次是装 ruby 环境

这个过程中，个人最难的还是用例的持续维护，要面对诸如人员离职、架构变动、工作调整等一系列主动/被动变化带来的影响，对应的用例运营机制一定要明确、可执行可管理、考虑严谨。一旦维护跟不上就有破窗效应，越做越烂，最后被放弃。

感觉自己没有资格留言，来围观一下

就这个具体案例，那你可以同一个全局变量来保存这个 id 值，查了一下 pytest 有个叫 pytest-ordering 的插件可以控制用例运行先后顺序，然后在后置用例里再检查全局变量是否有值和可用，不可用报错，可用就正常跑这样。

基本原则是用例之间不能耦合。

如果一定要这么搞，你就只能在依赖数据的用例里，加判断去看前置数据是否准备完毕（这个判断可以是一个全局变量，可以是一条数据库标志性数据等），如果前置数据没准备完，要不阻塞，要不直接跳过不跑（但是显然都不合适）。

个人建议的做法是，把前置依赖的那块数据 mock 好，这才是正规做法；也可以让他们合并成一个用例一起跑，至于怎么合并就看你实际用例怎么写

那大概是因为不需要做什么也能水涨船高跟着往上走吧。顺风舒服，逆风翻车，管理要做好真的需要一直绷着一根弦，要十分清醒不能松懈，即使事情规划得很好，但还是依赖到下面的人能否有效执行，还要兼任一定程度的过程管理，确实累。