这是一个创建于 180 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的
上周五公司例行发版上线，在最后测试最终回归本期上线的主要功能时，发现有个 api 接口调用失败了。然后研发排查发现，是实现本期功能的时候忘记考虑到 api 的也要适配了（本期功能大概是将 web 端的两个列表数据合并成到一个列表，因为合并需要增加字段，所以 api 那边也需要适配一下）。最终只能将问题遗留处理
细节方面
1 、这个 api 之前是获取其中一个列表的数据，研发在提测前的自测是只造了之前列表的数据，当前接口可以被调通，问题没有被发现。
2 、这个 api 在上线前 2 天，被提过另外的问题（有点阻碍继续测试），研发第一时间解决后置回给测试，测试在上线前最后时刻进行的复测。
我的疑问
1 、研发在自测时是否有必要进行很全面的测试。如上面说的，研发只是造了点数据，保证了接口正常，没有考虑到两个列表数据同时存在的情况。
2 、测试如果在第二天研发解决另外的问题后，及时复测，是否能提早发现问题，给研发充分的时间修改，不至于到最后来不及了。
上周五公司例行发版上线，在最后测试最终回归本期上线的主要功能时，发现有个 api 接口调用失败了。然后研发排查发现，是实现本期功能的时候忘记考虑到 api 的也要适配了（本期功能大概是将 web 端的两个列表数据合并成到一个列表，因为合并需要增加字段，所以 api 那边也需要适配一下）。最终只能将问题遗留处理
细节方面
1 、这个 api 之前是获取其中一个列表的数据，研发在提测前的自测是只造了之前列表的数据，当前接口可以被调通，问题没有被发现。
2 、这个 api 在上线前 2 天，被提过另外的问题（有点阻碍继续测试），研发第一时间解决后置回给测试，测试在上线前最后时刻进行的复测。
我的疑问
1 、研发在自测时是否有必要进行很全面的测试。如上面说的，研发只是造了点数据，保证了接口正常，没有考虑到两个列表数据同时存在的情况。
2 、测试如果在第二天研发解决另外的问题后，及时复测，是否能提早发现问题，给研发充分的时间修改，不至于到最后来不及了。
第 1 条附言 · 180 天前
再补充一点，我们公司就几人团队。产品提需求基本都是一个小文档，把想要的东西介绍清楚，剩下的就是研发自己想象了。
整个需求中，
产品做的事：
1 、发布一个说明文档，告诉研发想要什么。2 、研发根据说明文档实现时遇到的问题进行实时解答。
研发做的事：
1 、根据产品提供的说明文档，编写设计文档，定具体的设计方案。
2 、代码实现。
3 、功能自测，并提供自测用例。
4 、跟测试一起评审测试用例。
测试做的事：
1 、根据研发的设计方案、产品的说明文档、研发的自测用例、对需求的自我理解 多个因素结合编写测试用例，并进行测试。
2 、遇到跟研发有歧义的问题，跟产品确认。
整个需求中，
产品做的事：
1 、发布一个说明文档，告诉研发想要什么。2 、研发根据说明文档实现时遇到的问题进行实时解答。
研发做的事：
1 、根据产品提供的说明文档，编写设计文档，定具体的设计方案。
2 、代码实现。
3 、功能自测，并提供自测用例。
4 、跟测试一起评审测试用例。
测试做的事：
1 、根据研发的设计方案、产品的说明文档、研发的自测用例、对需求的自我理解 多个因素结合编写测试用例，并进行测试。
2 、遇到跟研发有歧义的问题，跟产品确认。
31 条回复 • 2024-05-14 11:38:43 +08:00
 |
1
yuhongtai114514 180 天前
很全面的测试，前提是时间要够，项目坑要少，但大多数项目都是倒排的吧，研发没时间测那么多 case ，需要测试兜一下
|
 |
2
xiaoHuaJia 180 天前  2
为什么！！！你们都喜欢周五这种放假前发版！！！！！！！！！！！！！！！
|
 |
3
zephyru 180 天前 1
这东西，没有什么绝对值...也没啥意思
锅在研发的话，那就是，研发在开发阶段没有全面的评估接口的影响面 想甩的话，那只能是，比如评审阶段没有人提出来 锅在测试，那就是，测试没有从业务层面考虑到这几个接口会相互影响及时复测，或者没有全面测试 但，如果测试说了，这个迭代不进行全量回归就甩不过去（很少有小迭代做全量回归的） 锅在产品，那就是产品没有在需求阶段指出这些需求（接口）会有关联 比较牵强，但也不是甩不过去 其它还能把锅甩给，线上的错误收集/监控/自动测试体系，如果有，那就是没有及时发现问题/用例有问题/不完善 如果没有，那就是需要搞一套 |
 |
4
SuperAllen 180 天前
@xiaoHuaJia 是因为周末双倍工资吗 [doge]
|
 |
5
iOCZS 180 天前
测试案例拿出来啊，看看是不是有遗漏
如果更多的是涉及代码细节的，那就是开发的问题 |
 |
6
NessajCN 180 天前
权责对等
测试如果有更大话语权，譬如测试可以给研发规定工期，可以把码农拉去训话，那测试被锅 如果测试只能辅助研发，跑跑现成的 workflow ，提 bug 模板也要按研发给的格式，那研发背锅 |
 |
7
brader 180 天前
这种可以大概率复现，且有很直观的页面表现的 BUG ，我觉得上到测试环境，测试发现了那就是开发的锅。
如果上到生产环境去，说破天都是测试的锅。 不在于开发有没有全面测试、有没有发现。你测试是最后一到防线，如果开发全面测试，就能拦住了，找你测试来干什么 |
 |
8
Tsing2 180 天前
测试例分为本期功能的，和历史功能的回归测试
回归测试如果做不到全自动化的话，那就是挑着人工测（否则成本过高），至少挑了哪些，怎么审批的，这个流程是谁把控谁签字的，需要复盘 如果测试例遗漏是可以接受的，那就没人背锅，优化流程，Review ，执行，皆大欢喜 如果一定要有人背锅，那就是测试例审批的人，一般是小领导 如果根本就没流程，瞎拍脑袋的，那就呵呵了 |
 |
9
walkeronway 180 天前
作为测试人员，我的观点：
1. 这个问题不能简单定到某一方的责任。首先产品一般不会关注到 API 层面的改动。其次这个改动影响到的 API 应该是没有在需求范围内，是更后面的调用，这种问题一般开发和测试都会很难留意到，这种问题得看经验了，如果测试很熟悉系统的 API 调用关系，这种问题其实是可以提前感知到的。 2. “在最后测试最终回归本期上线的主要功能时，发现有个 api 接口调用失败了” 说明这个 API 是可以在发版前在回归测试中发现的，但是“测试在上线前最后时刻进行的复测”导致了新的改动而没有时间做最终版的回归测试。当然也可能没有安排在测试环境针对主要功能进行这么全面的回归测试。可以硬说测试有责任，但是不建议，因为会感觉很憋屈。 3. 赞同 2 楼，我们这边是极力避免休息日前一个工作日、或者补班期间（如果用户有其他国家的）发版，因为出问题了，要么得加班解决，要么用户没有第一时间发现、导致问题持续 1 个工作日以上扩大影响产生大量脏数据增加后期擦屁股的难度。除非是 OKR 而且卡在了 due date 前。 |
 |
10
me1onsoda 180 天前
搞不懂，测试真的好喜欢跟开发分锅😅
|
 |
11
fulvaz 180 天前
我觉得 qa 锅再大，研发也需要背锅....而且不会因为有 qa 而可以锅就可以小一点....
另外从个人成长的角度，难道没了 qa ，研发就写不了代码了？ |
 |
12
Puteulanus 180 天前
1 我觉得没必要，一个是开发自己一般带着一些定视，很难保证没有遗漏的；第二个是在全面的测试上开发肯定没有 QA 专业（熟练、有常用的测试工具、数据）。相反在时间非常有限的情况下我倾向于开发只做自己认为最小的测试之后就丢给 QA ，把时间都留给专业人士，QA 早点测出问题打回来还能留时间改完再测一轮。
我们一般是开发改完告诉 QA 修改大致可能的影响范围，QA 再去决定要把哪些可能受影响的测试用例都重新测一遍。 不过如果低级错误开发没测出来漏到 QA 那边的多了容易被他们屌。 |
 |
13
darkengine 180 天前
@iOCZS 我觉得大概率没有测试用例。。。不然不可能覆盖不到
|
 |
14
Sanshi4396 OP @xiaoHuaJia #2 巧合，正常是 每月 10 号发一版
|
|
15
Sanshi4396 OP @iOCZS #5 测试用例有，测试没来得及测，最后发版前一刻才测出来。研发是压根没想到这个点，相当于漏做了。
|
|
16
Sanshi4396 OP @Sanshi4396 #15 再补充一点，我们公司就几人团队。产品提需求基本都是一个小文档，把想要的东西介绍清楚，剩下的就是研发自己想象了。
整个需求中， 产品做的事： 1 、发布一个说明文档，告诉研发想要什么。2 、研发根据说明文档实现时遇到的问题进行实时解答。 研发做的事： 1 、根据产品提供的说明文档，编写设计文档，定具体的设计方案。 2 、代码实现。 3 、功能自测，并提供自测用例。 4 、跟测试一起评审测试用例。 测试做的事： 1 、根据研发的设计方案、产品的说明文档、研发的自测用例、对需求的自我理解 多个因素结合编写测试用例，并进行测试。 2 、遇到跟研发有歧义的问题，跟产品确认。 |
 |
17
ecloud 180 天前 1
锅在 CEO ，因为他根本不懂软件工程生命周期，双 V 模型。需求->设计->用例->编码->测试。这个锅不在你们这层
|
 |
18
children009 180 天前
其实这锅是你们整个团队的问题，每个人都有责任，产品文档不清晰或者表达不规范，在评审文档中没有明确，占责任 10-20% ， 开发已经提前知道 API 的作用，并没有着重反馈到测试团队，占责任 30-40%，同样，测试占 40% - 60%，其实业务模式强的测试很早就应该发现这个问题。
|
 |
19
changf 180 天前 2
1 、项目质量，不是靠 QA 测出来的，是靠产研测共同努力才能得来。
2 、只有在有严格分工，规范流程的大前提下，讨论谁的责任才是有意义的。 3 、很多团队其实研发流程，质量管理，项目排期本身乱成一锅粥。所以出了线上问题，团队应该想的是尽快修复，后面复盘也是为了避免出现同类型问题，而不是明确出来谁来背锅，没一点意义。 4 、小团队更应该有事一起背，本来就可能一人分饰多角，还玩谁来背锅这套，凝聚力全没了。 |
|
20
Sanshi4396 OP @changf #19 认同你说的，确实在小团队里，往往是多做多错的。我本身作为研发侧，发这个贴也是为了 解我自己的心结，有时候出现 bug 什么的，总是在想是不是我写的就是我背锅，虽然领导可能并不会因此指责我。
|
|
21
Sanshi4396 OP @changf #19 可能没在大公司呆过，对责任划分这一块真的很模糊。
|
 |
22
chinaguaiu 180 天前
几个人的团队还分出测试岗位不太现实。小团队基本上是谁写的谁负责到底。
|
|
23
xiaoHuaJia 180 天前
要不测试写代码，开发测吧。既要又要，想想开发为什么叫开发，测试为什么叫测试。如果测试负责不了那就全裁了，把钱交给开发让开发自己测。就喜欢在哪里叫叫叫
|
 |
25
huigeer 180 天前
这还能怎么甩，没有测试参与，研发全锅；有测试，55 分。项目管理先扛下来
|
|
26
walkeronway 180 天前
@Sanshi4396 #15
??? 测试用例覆盖到了但是没有执行？？？？测试用例没有完全执行，测试负责人有向项目组同步这个风险吗？项目组负责人点头同意带这个风险上线了吗？ 如果没有提前同步到项目组，这个严重性已经升级了啊，有用例但不执行也不告知风险，测试全责了，没有讨论的必要了 |
 |
27
lenglengyuchen 180 天前
上周的阮一峰周刊正好提到”无罪文化“，感觉把错误归结到个人并没有什么意义
软件公司应该提倡"无罪文化"。 发生产品事故或者服务中断时，不要认定罪人并惩罚他们，而要假设相关个人出于良好意图，只是没有得到正确的信息来做出更好的决策，或者没有工具及时制止他们犯错。 《关于无罪文化》 https://www.gybe.ca/a-few-words-about-blameless-culture/ |
|
28
walkeronway 180 天前
你说的这个用例，是指发版前最后改的那个问题，还是线上那个问题对应的用例？
|
 |
29
qooweds 180 天前
小团队讨论谁的锅没有意义,本身就是小步快跑的开发模式,效率高自然会牺牲质量.
改进方案稍微复盘一下就可以看出来: 1.产品设计尽可能考虑每一个细节,包括 API 的适配;需求文档加上评审环节 2.开发需要做设计评审,code review 3.测试用例需要细化到每一个细节,包括 API 适配的回归测试用例,并且需要产品和开发参与评审 每一项都会增加开发成本,降低开发效率,看你们团队的取舍了. 成本最低的是第一项 |
|
30
Sanshi4396 OP @walkeronway #28 线上问题对应的用例，本次上线其实时间上是有点紧的，测试也确实提前有知会过上线前可能不能把用例全部走完。。
|
 |
31
dododada 179 天前
发版时间改掉吧，周二发大版本，周四发小版本，有时间回滚
|
Select Language