服务端开发十几个，客户端 + 前端开发十几个，正式测试几个，外包几个，模糊数字 4:1 ~ 3:1 之间吧？

看看这里的内容小程序自动化，微信官方有提供小程序云测能力（monkey 等一系列），我理解其中有兼容测试的相关服务。
至于自动化，我都没用过，minium 和 airtest 的使用方式不一样，前者有官方的控件识别能力，可以做准确精细的控件识别；后者基于图像识别，理论上使用成本会稍微低一点点。就看你喜欢哪种。我自己更倾向官方的能力。

那你就试试继续回退版本咯，比如 1.22.2 。瞎搞一通看看行不行再说，这没有信息量

选择哪种都好，直观上对测试影响不大，但是对研发运维影响大；哪种都有可能，估计多数是云服务

同意 5 楼。

从范围上来说，方案 > 计划，计划可以在方案上详略得当地体现。

方案，要求你具备分析过程，从测试对象、业务分析、质量风险分析、做哪些测试、用什么工具怎么测，要达成什么质量目标等一通平时我们心领神会的东西，都得写出来。核心是要完整，要齐全，要前后有逻辑连贯，要体现【因为所以】。

计划，说的是执行层面的事情，精确到事情、排期、人力，用来传达这个事情投入多少资源花多少时间，就可以比较确定性地完成。

对，你们确实挺特殊反过来做，不过只要线上不出问题怎么做都算是正确的。流量回放虽然可以获取海量流量，但是筛选流量上面也是看运气，要做明确的测试覆盖，还是靠人为控制参数的接口自动化效率更高。

还有一些特殊场景，比如产品活动，可能活动的代码已经上线了，但因为还没到活动宣发日期所以不开启入口，这种情况下线上零流量，就得用接口自动化去主动覆盖。

好吧，我看着没写，但是又想听，所以问问

线上参与，可以报名吗？（人在深圳）

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

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

线上事故⚠️

这是已经财务自由了吗

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

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. 一个增删改查的开发，多多少少也创造了产品，如果没有这些开发，连能给我们测试的东西都没有。所以谁是第一创造者，谁的钱更多也无可厚非……