今年正好是不惑之年，步入测试这个行业十多年了，曾经也在大厂短暂待过，目前在一家算是中厂的公司，坐标北京，2 年前入职的，主要的项目从立项到现在差不多 16 个月的样子，这一年业务的变化非常快，下面仅从数据的维度来给自己做个简要的总结。
工作
- 测试团队 1x 人，有少部分外包同学，研发测试比在 3.5 比 1 左右，功能测试占比 90% 以上；
- 全年交付大小需求 1000+，用飞书多维表格进行管理，累计提交的 BUG 数 8000+，最多的同学 1200+；
- APP A，一周一版，全年累计发版次数 50+；APP B，8 月启动，一周一版，全年累计发版 20+；DAU 均百万 +；
- 个人全年基本上 10105，发版日则取决于最终发版时间，全年平均发版时间应该在晚上 11 点-12 点之间，最晚凌晨 3 点多；
- 全年有测试主导或者参与的线上事故问题复盘共 6 次，没有出现 P1 和 P2 级别的问题，其中测试人员被罚款共有 2 次，主要原因：
- 新版本 T，需求 A 影响到了已有功能 B，测试阶段和回归阶段未发现，T+1 版本回归测试发现连带问题并一并修复，但 T 版本对该功能造成了一定影响（非收入），最终客户端研发和测试责任对半分；
- 某核心系统存在设计上的缺陷，导致某需求上线后在部分地区存在异常，该系统研发负责人在一周后的例行巡查时发现问题，但造成了一定的资损，最终服务端研发占责任大头，测试占少部分；
- 其他的几次，要么是事故主要责任在研发，跟测试相关性不大；要么是事故等级没有到罚款的程度而作为处理。
生活
- 2025 年 3 月底参加公司的年度体检，体重超重，BMI 25.9，轻度脂肪肝；
- 从 4 月中旬开始，利用中午或晚饭后的空闲时间，开始通过快走的方式来提升能量消耗，配速 10 分出头，6 月份最长一次走了 2 个多小时，距离 13 公里 +；
- 从 6 月中旬开始，人生第一次开始尝试跑步，最初只能跑几百米，跑走结合，循序渐进，6 月底能够坚持跑到 3 公里。到了 7 月下旬，跑了人生中的第一个 10 公里。到了 8 月份，最长一次跑步 16 公里。现在主要周中和周末各跑 1 次，每次 5-10 公里之间，配速在 5-6 分之间；
- 截止到2025年12月31日，全年 8 月半月的时间，快走 234 次，累计 605 公里；6 个半月时间，跑步 62 次，累计 351 公里。体重减少 23 斤，BMI 指数 21.8，回到正常水平，脂肪肝是否消失待年后体检。
代码
- 【客户端】完成双端埋点测试辅助脚本，辅助发现重复上报、漏报、特定场景下的数据统计、关键字段校验等问题，双端代码行 400+，组内绝大部分同学都在使用；
- 【客户端】Android 端继续完善基于字节开源的 Fastbot 的自动化测试框架，全年累计自动化提交崩溃的 BUG 120+，研发解决率 70%+，线上崩溃率从最高的 3% 降低到目前 0.2% 左右；
- 【客户端】完成对 Android 端 Deeplink 的自动化测试，主要用于每个常规迭代版本的回归测试，避免新增功能影响到既有的 Deeplink 跳转，代码行 200+；
- 【客户端】完成 2 个最核心，也是最高频的基础业务场景下的 UI 自动化测试建设，主要解决长时间使用这些功能时可能会出现的页面异常或者切换失败等问题，代码行 700+；
- 【客户端】完成双端性能测试脚本的开发，覆盖 CPU 占用、内存使用、流量使用、FPS 等维度的性能数据抓取，再加上冷启动时长、核心场景下的响应时长等，上述场景全年都有优化，目前绝大部分指标都优于竞品，核心代码行 450+，HTML 趋势报告代码行 200+（非必须），现在每个月左右跑一次；
- 【服务端】在自研的数据驱动的接口自动化测试框架下新增了 5 个主要的业务场景 30+ 接口的自动化测试支持，代码行 800+，发现线上配置类问题 10+；
- 【服务端】在接口自动化测试的基础上，开发对用户可见内容的自动化测试巡检脚本，从资源维度进行全方面的巡检，代码行 1000+，发现资源维度的问题 300+，90% 以上的问题已经联动产运调整配置或者研发优化代码完成修复；
- 【个人学习】空闲时候则在 Leetcode 上刷刷题，全年共解决简单问题 168 题，中等 53 题，困难 8 题，在团队内部分享如何解题共 10 次。
"【服务端】在接口自动化测试的基础上，开发对用户可见内容的自动化测试巡检脚本，从资源维度进行全方面的巡检，代码行 1000+，发现资源维度的问题 300+，90% 以上的问题已经联动产运调整配置或者研发优化代码完成修复；"
细说这个啊宝子
【客户端】完成双端埋点测试辅助脚本，辅助发现重复上报、漏报、特定场景下的数据统计、关键字段校验等问题，双端代码行 400+，组内绝大部分同学都在使用； 想学习这个 T.T 球球
大佬，还能细点吗 弟弟们多看、爱看、喜欢看
客户端双端埋点测试辅助脚本，这个是怎么实现的啊 固定包吗？现在也是在做 app 测试 包不一样埋点触发逻辑也不同没办法涵盖吧 有具体的实现方案吗大佬求教
关于埋点
我们这边的埋点没有接比如神策这种的第三方，是通过服务端提供的单独的接口进行上报的，同时会写一份数据到阿里云上，那么对于我们来说，之前的测试方式就是客户端手动触发，然后去阿里云的后台查看，通过一些关键字进行查找，但这种方法比较好测试出来有没有漏报，但重复上报也勉强能看，但比如多上报了其他不应该上报的埋点这个就不太方便了，另外就是我们的业务场景要统计某个埋点在一段时间多次上报的累计数值，这个后台完全没办法，只能自己一个个记录下来然后去算，效率也很差，结果也往往不准。
怎么做
有几个思路，第一是客户端调用埋点上报，第二是服务端接口处理，第三是落库数据查询，第四是阿里云埋点数据分析，这几个方法都是可以去尝试的，除了第三种（这个生产环境的数据库权限比较敏感），我都有尝试过，这里都可以给大家大概说下。
- 先说第四种：这个就是手动把一段时间内的埋点按照要求查询并导出一份数据，阿里云支持 csv 的，然后就可以用代码来解析，也可以用 pandas 来。但这个一般适用于线上所有用户下的某些埋点或者针对某些特定用户的埋点数据进行异常检查，比如核心埋点 A，有 N 个枚举值，你在测试过程中可能覆盖不全，或者生产上可能会出现完全意想不到的异常情况，那么这个就可以派上用场了，我一般会定期的来分析一些特定的埋点，给研发提一些埋点上的问题。举个例子，埋点上报了某个异常，那就可以通过这种数据分析的方法来判断是不是某些资源出了问题，因为如果是资源的问题，那就会比较集中在某些资源上。
- 再说第二种，这种可以通过中间人代理的方式来做，有个工具 mitmproxy，大家可以研究下。这个其实跟 charles 这些抓包工具类似，不同点在于可以通过 python 代码来把抓到的接口请求和返回数据做处理，去分析里面是不是有重复上报的问题，去计算某些埋点统计数据的问题，这些都是可以做的。工具很强大，也能支持 MOCK。之前我们 APP 做合规自动化测试的时候我用的这个，一边跑 MONKEY，一边把所有的接口数据都抓到，然后看接口的 header、data、cookie 里面有没有像 androidID，经纬度之类的一些敏感的字段，以满足合规方面的要求。埋点的数据也是如此，不过因为一直要连着代理，略微麻烦一些，而且像支付类的接口不能代理，会测试不到。
- 再说第一种，也是我现在用的。客户端调用接口上报埋点成功的时候，将埋点的数据通过 tag 的方式，把日志打印到 console 端，然后 Android 借助 adb logcat，IOS 借助 tidevice syslog 就可以抓取到所有的日志，然后通过 tag 的方式进行过滤拿到所有上报的埋点数据，然后去解析埋点的 event name 和 event info。这样连着数据线测试，一边操作，电脑终端就实时显示埋点信息，也非常方便，比如进入某个页面，上报了一堆埋点，能够很明显看出哪些埋点是不需要上报的，这个用之前的方式是很难测到的。重复性判断也简单，
def checkDuplicate(self, tsp, eventName, eventExtra):
# 检查当前埋点是否重复上报，并输出上报的次数
key = f'{eventName}---{eventExtra}'
if key in self.eventsDict:
self.eventsDict[key][1] += 1
print(Fore.RED + f"{self.eventsDict[key][2]}！！！请注意：{eventName} 检测到有{self.eventsDict[key][1]}次重复上报：{eventExtra}" + Style.RESET_ALL)
else:
self.eventsDict[key] = [eventExtra, 1, tsp]
eventInfo 是可以转成 json 的，所以你可以很方便的提取出来里面的数据，然后进行累加计算这种（这个解决了我们测试的一个难点问题，我们要统计某个埋点上报的时长字段，需要多次操作触发这个埋点然后计算总数），而且也可以校验某些字段是否缺失，某些字段的值是否异常（举个简单例子，一个上报时长的字段，研发之前异常处理有问题，上报了一个很大的时间戳数值之类的）。至于 tag 和打印到 console 端的日志，这个就和研发这边沟通好就行，需要注意的是，Android 一般只能在 debug 包上测试（跟环境无关，测试和生产均可），iOS 一般也是在 debug 包进行测试，release 的包一般不打印日志的。
大佬。我们这边客户端埋点上报都是调用 aws 的 sdk，直接到 aws 的日志库 这种想通过本地的脚本怎么实现埋点的测试
大佬公司外包同学占比多少呢？感觉外包越来越多了
卡丁车卡丁丁
回复
我做巡检的目标是：用户可见即可用，也就是用户打开 APP，从各个页面能够看到的那些数据，都是尽可能正确的。以其让用户来反馈我们问题，还不如我们自己主动去发现问题。举个例子，电商 APP，比如 JD 这种，用户打开 APP 会在首页看到很多的内容，但基础的可能就是像活动、商品这些基本元素，那我的目标就是通过接口自动化的方法，拿到用户看到的这些数据，然后去调用对应的接口比如活动详情页的接口，商品详情页的接口等等去拿到实际在端上显示的内容，然后去做检查，比如商品，那就可以去检查商品图、商品描述、规格、优惠券、促销这些信息，如果配置上存在一些问题，那么从接口层面就能够巡检出来。。但线上数据可能很多，所以这里就需要用数据库把测试过的数据及结果存到表里，这样就不用重复测试，而且像商品这种，价格是很敏感的，首页看到的价格和商详中的价格如果不一致，用户是完全可以去投诉的，这种我之前做电商业务的时候经常遇到反馈，后面就是通过这种方式巡检查到某些商品 sku 促销或者秒杀等情况下系统处理有问题导致价格不一致的问题，发现问题就通知研发或者产运去改好了。再比如视频的项目，视频的封面、描述、封面图（第 I 帧可能会是黑屏）、音轨、字幕、视频流这些都是可以作为基础元素去做巡检的。
我的做法是：有点像数据驱动的方式，先通过接口抓到用户可能看到的数据，比如首页这种，然后针对每种基础元素可能会去调用其详情页的接口，这里用到了我写的一个方法，能够将抓取到的数据自动转成自动化的测试用例，然后去执行，最后再做断言。我用的还是传统的 unitest 框架，自动将数据转成自动化测试用例用到的是 setattr 这个方法，比如我从首页抓到了 100 个活动和 300 个商品，那么这一轮测试就可以动态生成 400 条的测试用例，测试报告用的是中文版的 htmltestrunner，测试报告里面能够看到每一条 case 以及测试结果，失败的 case 也可以通过对接飞书发送提醒啥的。资源异常类的 case，我单独拉了个产运的群，失败的 case 都会推送到飞书群并 at 到对应的人员进行跟进，目前看效果还可以。
总结的真好 善于思考 付诸行动
【客户端】完成双端性能测试脚本的开发，覆盖 CPU 占用、内存使用、流量使用、FPS 等维度的性能数据抓取，再加上冷启动时长、核心场景下的响应时长等，上述场景全年都有优化，目前绝大部分指标都优于竞品，核心代码行 450+，HTML 趋势报告代码行 200+（非必须），现在每个月左右跑一次； 大佬这个怎么弄的