就这个事情来说，我感觉应该先把服务重启列进去研发和测试上线的 checklist 中去。

也很奇怪，服务升级部署本身不就是重启的过程吗？

不涉及米的时候都 OK，涉及减米的情况下这位 LD 确实有点无用了，至少进一步确定下问题原因，真的只是因为没重启吗？那谁应该去重启呢？为什么没重启呢？重启后验证有提前报备吗。。。
反正涉及米的情况下，如果 LD 这么轻易的就拿起了锅然后放到我的背上，我会冲了 T！

犯大吴疆土者 盛必击而破之

测试就是背锅的，无论是不是你的问题，产品的问题也得咱测试背锅
昨天亲自经历，我司的一个小程序，订单上要显示一个类似于订单号的一个字段，分明需求都未设计的东西（但是我们有给产品提过，产品说不需要）
昨天老板，冲出办公室就说，这测试咋测的？？？
我当时瞬间懵逼了啊，我能怎么办，fuck

感觉你们 leader 全览啊，个人觉得这个不能归单独咎于测试，这种数据库中间件等底层升级的，发布说明肯定都要写清楚的，且上线方案也要有吧。不然糊里糊涂发布，那上下肯定都是回归基本功能就行，不可能做到全覆盖。

想知道揽锅 ld 是怎么想的

不是只有测试背锅，而是你们 leader 把锅接回到自己部门。这种情况，是我就直接开喷了，这垃圾技术方案谁做的，负责人怎么把控全局了？

建议以后遇到类似大型升级服务，把测试回归方案拉着开发，产品一起开会讨论一下，把讨论结果记录下来，发布后如果出现问题，相关的人员都要负责，就不是测试背锅了；他们参与了会议，review 了测试回归方案

既然提过，就要在 Bug 管理系统中有所记录，关闭此单的时候备注上产品表示暂时不需要。等上面来找你测试追责的时候，你把这个工单截图出来，问题就不在测试身上了。测试做过的事情，一定要有所记录，有所备注；

ld 玩 T 社吗

测试，下等人

测试领导明显不懂业务逻辑，怎么能附和开发和运维的思维，自己揽责任。
重启问题应该是开发自己做的不到位，和测试有什么关系，自己考虑不全，测试负责的是基本功能回归，不负责线上的运维服务，由于服务流程和部署问题导致的问题，不属于测试问题。
需要明确责任边界，为啥没有重启，为啥发布之前没有考虑到，是什么原因? 有没有提醒过测试，需要做重启后的验证？发布之前有没有影响范围的说明？

需求本身就没有，为什么要测试承担？如果所有的风险都测试承担了，那还要产品干什么，那产品的工资是不是能发一部分给测试？
测试与研发提，只是需求评审时，当时以会议的形式提出来，产品当时就一句，不需要
抛开这个问题，还有其他类似的问题，我们是有记录的，让产品去找老板三番五次的确认，最后给的回复都说不需要，结果上线，用的时候就来一句为什么没有？测试怎么测的？

测试 ld 可以揽问题，毕竟测试要对质量负责的这点责任心要有。但不能全揽在自己头上，测试可以改进，但是问题全甩到测试头上，那以后还怎么搞。其他部门对质量就完全没有一点责任了？测试完全兜底了？
这种问题在我看来，测试就是算有责任也是小责任，可以基于问题做为后续改进的参考。主要责任还是在前期准备，是流程的问题，要罚也罚不到一线测试。如果我是这个测试 ld，要罚就罚 ld 啊，这样大家也会比较信服。

看样子不是楼主背锅

我觉得权责要对等，谁背锅谁负责，我都是直接说，我背锅那以后都是我负责，你们都得配合我，看整不死你们。。。。。。。。。

??? 我像是进了朋友圈了 哥们 冒昧的问一下 说测试轻松 的是你发的吗

看错了，是 tidb 数据库，mysql 的话如果是 mgr 模式的高可用集群，没主键的话会报错；单机则不会，tidb 的话不太熟悉，稍微查了下，集群模式下也会要求每张表要有主键，所以建议确认一下

1、测试环境除了数据库版本一致，其他的如部署方式（集群 or 单机 or 高可用方案）是否一致

2、我对重启服务就解决有点疑问，猜测是改了表结构，加上了主键

1. 开发是否有在 run book 里面说明要重启？ 如果没有，是没有识别出来这个步骤。
2. 如果 run book 里面明确写了这个步骤，是不是运维没严格执行？
3. 开发 lead 和运维 lead 背责，整个上线流程有问题。
4. 一定要挑测试的问题，或者从质量最后一关的责任人来看，是不是你们的测试流程有瑕疵，或者覆盖率不够，导致不能发现问题。 虽然主要责任不在测试上，还是有优化空间。

好家伙，不要把群里面的图片乱发出来。害死人的

核心问题不是为什么升级数据库，需要服务重启，但是上线没有重启吗？

问题都提交到缺陷管理软件上，要有记录能回溯

环境部署问题也在测试缺陷之列啊，这个场景是：运维升级线上数据库后，测试需要对相关功能进行回归验证。
测试覆盖不全，导致问题泄露
运维升级有误，导致出现问题

你说的相关功能是不是全量啊？

精准测试，测试范围需要开发、测试、业务一起评估