现在是吃鸡模式了，得趁早逃出裁员圈，按这趋势后面的卷翻天

不是我危言耸听，的确看得不少要求 30 以下的，我现在积极探索中，真的 30 岁被裁一下，感觉得失业。当然你是字节大佬，还是有很多公司可以跳

有转行的好方向记得一起分享下

下次把昵称改成测试专家就可以防止你这种人了，别回我了，我真的想吐

只能说羡慕了，一份职业能做 10 年真的已经超越很多测试了，我这新一代的，难受呀

你这种就是最保险的方法就是完整测试，就怕环境变动带来的不可预知问题。接口自动化不保险、UI 自动化不值得。不知道你是不是那种 H5 的小活动，或者你可以用 airtest 快速写个交互验证的自动化

你说得对

你能不能别 @ 我，不好意思，我比较厌蠢，特别是你这类的

额。。。。。我是想表达测试的 UI 自动化的进化方向有问题。。。。你可以造机器人，希望机器人造成后，螺丝还没生锈或者已经不需要拧螺丝了

我也喜欢听邓紫棋 + 周杰伦

买不起 4 呀，能用 gpt-3.5 的做替换吗

纯本末倒置的做法，用一件本身就很复杂的事情 去帮助另外一个实用性不高且复杂度也不高的事。类似一个螺丝用手拧紧的事，简单的方案有电动螺丝刀，但是你却制造了一个机器人，让它拿着螺丝刀模仿人去拧，为此不断去调试这个机器人。请问你到底是要拧这个螺丝，还是为了制造机器人？

居然说成本不高.......

这么说吧，必要的点点点减不了，非必要的点点点时间看起来省略了，其实转换成写 UI 自动化用例的时间 + 维护用例 + 日常报错检查

现在人均都有一个博客吧，我自己也有一个，文章会在上面写，其他高兴时就来社区活跃下

。。。。

增加点安全感，每次有新增小需求，可以跑一跑

算不算有用的废话？

遇到偶现 bug:

1. 记录复现步骤、复现的时间、复现的环境、截图、日志
2. 记录客户端的版本信息（如有旧版本就验证下旧版本是否复现 对照下）
3. 频率评估，根据发生的频率做 bug 等级判断
4. 创建 bug 单：将 1、2、3 记录的信息都写在 bug 单里
5. 根据实际情况通知相关人士

想下 bug 的原因

排查 bug 一般就是猜下原因，然后根据原因去逐步排查，你这个是列表显示问题，那么就有可能是以下几种情况：
1. 请求延迟： 本地网络不佳或者服务器网络波动，导致未能及时获取数据
2. 异步加载：网络延迟、服务器响应时间太久、处理回调的时间较长影响数据的及时显示
3. 定时器： 可能开发写了定时更新或者刷新玩家列表，你刚好在刷新的那一刻点进去
4. 内存泄漏导致：卡顿和响应延迟、刷新频率降低、内存回收等
5. 缓存：缓存加载延迟、缓存过期导致显示为空、缓存刷新

那你排查步骤一般就是：

1. 先确定下你看到的列表是 H5 还是原生
2. 先检查自己本地网络环境和设备性能
3. 对比安卓端和苹果端应用是否问题一致（确认下是单端问题还是双端问题，又或者是后台问题）
4. 抓包下用户列表的接口，做下接口的基准测试，就看下响应时间和错误率（如果错误率高、响应时间长，找报 bug 给后台）
5. 多次复现下客户端的 bug，抓包日志数据
6. 报 bug 单给客户端开发，让开发去定位（测试这边更多是把 bug 分给正确的人，描述清楚 bug 的复现步骤，还有贴上你上述对本地网络环境、设备机器型号、后台接口测试、双端复现结果、还有日志） .

功能趋于稳定，无频繁新增需求、无版本大改动、线上还要使用个三五年的项目

差不多，30 岁现在是处于被嫌弃的红线了。现在年轻的测试学习资料多，基本想要进互联网的，大三大二就开始看培训机构视频了吧，话说测开技术就那么些，要学还是挺快的

难呀，我想着 30 岁前能尽快转个方向，去做硬件测试或者其他人少一点的行业，这软件测试太卷了，全栈老测试都没多少面试

应该是 log 上报吧，你可以抓包看下电商页面，或者王者也行
类似王者的这样定义下
|id|user|event_name|

id: 事件唯一标识符。
user: 用户唯一标识符。
event_name: 事件名称，例如按钮点击、页面浏览等。

然后前端点击时，通过 http 请求发出去 |1|12345|button_click|

我没那么深的觉悟 ，我就是个打工的，公司墙头草，无限趋利避害

难受呀，要 GPT-4 账号