walkeronway

@geeksammao 主要好久没用 安卓机了，不了解情况，不对比避免引战。

我是 iPhone 12 标准版换的 15pm ，12 用了快两年还有 86%的电池健康度，耗电是真的快，电量低于 30%我都不敢出门，相机耗电肉眼可见。换了 15pm 之后，15%电量我都敢出门坐地铁去上班，没了续航焦虑。
然后说大小，我本来是不太喜欢大屏手机的，12 在我看来都已经算大屏了（ 12 之前用的小米 6 ），但小屏能选的就是小米 14 和 iphone se ，但我看小米 14 所谓的“小屏”其实也就是跟 iPhone 12 一样大，不是真的小屏。se 续航好像巨拉跨。最后就直接上 15pm 了。12 这个尺寸是我单手握住手机两边进行操作的极限了。换了 15pm 之后单手操作就只能小指托着和靠其他放在背后的手指移动手机位置来配合操作了。大部分时间都在双手操作，双手操作了就对重量没多大感觉了。不过本来也没感觉重量上有啥不适应的。
单就续航这一点我都觉得换得值（不比较安卓机），充电速度也比 12 快。不过信号好像比之前的 12 差了，之前用 12 的时候，微信很少出现弹通知但 app 出现消息延迟的情况，换了 15pm ，微信经常等半天才看得到消息。不知道是不是个例。

你说的这个用例，是指发版前最后改的那个问题，还是线上那个问题对应的用例？

@Sanshi4396 #15
??? 测试用例覆盖到了但是没有执行？？？？测试用例没有完全执行，测试负责人有向项目组同步这个风险吗？项目组负责人点头同意带这个风险上线了吗？
如果没有提前同步到项目组，这个严重性已经升级了啊，有用例但不执行也不告知风险，测试全责了，没有讨论的必要了

作为测试人员，我的观点：
1. 这个问题不能简单定到某一方的责任。首先产品一般不会关注到 API 层面的改动。其次这个改动影响到的 API 应该是没有在需求范围内，是更后面的调用，这种问题一般开发和测试都会很难留意到，这种问题得看经验了，如果测试很熟悉系统的 API 调用关系，这种问题其实是可以提前感知到的。
2. “在最后测试最终回归本期上线的主要功能时，发现有个 api 接口调用失败了” 说明这个 API 是可以在发版前在回归测试中发现的，但是“测试在上线前最后时刻进行的复测”导致了新的改动而没有时间做最终版的回归测试。当然也可能没有安排在测试环境针对主要功能进行这么全面的回归测试。可以硬说测试有责任，但是不建议，因为会感觉很憋屈。
3. 赞同 2 楼，我们这边是极力避免休息日前一个工作日、或者补班期间（如果用户有其他国家的）发版，因为出问题了，要么得加班解决，要么用户没有第一时间发现、导致问题持续 1 个工作日以上扩大影响产生大量脏数据增加后期擦屁股的难度。除非是 OKR 而且卡在了 due date 前。

看起来好魔性

会 python 吗，mitmproxy 了解一下，可以二次开发简单地实现很灵活的规则

试试这个，https://www.v2ex.com/t/1021838