验收还有用例？

背锅侠

每个公司的情况不一样，我觉得上线如果测试有决策权，这个也并不坏。
当然有权力就有义务，你可以驳回一切不合理的东西，但出问题也要承担责任。

以前平安科技就是这么做的
而验收测试用例，要么业务/用户自己写，要么让他们从测试组的 case 里面挑选一部分做，没啥不妥

后续来了：

公司组织层面是把研发划为技术部门，产品/UI/测试划为产品部门的，所以暂时这个流程制定沟通只是在产品部内部沟通不含技术。我领导就是 ‘产品总监’。

在今天下午我牵头组织了哈会议，我毕竟经验较少发表的意见可能不专业。今天参与会议人员里包含了 UI、产品和测试。领导是异地办公制，我们在大本营，语音开会。
领导聊的第一个点是：“测试不要继续做 UI 还原度测试，因为做的也不专业，直接让 UI 自己来做测试，提交 bug 跟进 bug 解决状态”。

UI 组的同学比较被动，反驳的点也就看起来没有力量，如：
‘1.本来也是在做 UI 测试这个事情，但是没听说过哪个公司里的 UI 还要对项目实现产出负责的’，
‘2,是觉得，按照现有的节奏里，UI 做了测试之后出具文档交个测试组，测试组自己根据情况提 bug 再由测试组回测，遇细节控如 ‘间隔几个像素’ 这种问题，再返给 UI 来做。也是没问题的’

领导坚持有：
‘1.测试只能做个大体的视觉上的校验，但是并不专业和细致，比如，是用那个色号，间隔几个像素，粗细几个像素，都测不到，而且在测试用例上也体现不了这条，那么就是没有用的，直接由 UI 来做更合适’，
‘2.是应该秉承谁提交 bug 缺陷谁跟进负责解决，那么，这种由 UI 负责提出的，就应当由 UI 负责跟进解决没有’，
‘3 是测试职责里面应该是不包含这块的’；

这个点的起因也是比较怪，起因是测试小伙伴提交了一个 bug 是 ‘截图 + 文字说明’，bug 是说，研发的提示文案错了需要改。
但是这个 bug 因为研发没有认真看，看到图就以为是要改 ‘UI 弹窗样式’，所以就跟 UI 沟通说项目里怎么这么多个弹窗样式，但是截图截的是原型图，用于提示研发，是在这个页面，和表示与原型不符。有争执，出现了个 ‘理解偏差’ 的问题。

我认为，这个起因事情完全是研发不认真看 bug 说明，完全可以让研发规范认真阅读就可以了吖。诶，领导非要说，因为我们测试不专业，所以要规范哈避免这种问题。好嘛，避免的方式就是这种，我也是不理解。我觉得，UI 还原度测试，就可以 ‘’ 测试和 UI 一起做的 ‘’，不应该是 UI 全权负责的，虽然是看起来减少了测试工作量，但是这个不对，不应该。所以就杠起来了。

结论嘛，当然就是 ‘遵从领导意见，你说啥是啥’，UI 只能接受和执行了。。。

第二个聊的就是最开始上面描述的，领导认为 (我简要概括的)： ‘测试应对项目质量负责，为了能够对项目质量负责，那么，测试应当兼顾 QA 职责，规范流程，出具测试报告，出具上线标准，和上线决策权’

能杠起来的话也就是具体的点了。

这一整段描述里面，我只认同 ‘测试应对项目质量负责’ 这一个。 ‘出具测试报告’ 这个是因为，这个报告里面要纳入 ‘验收/和 UI 测试的部分’，我的理由就很简单，不是我经手我没办法出。

‘QA 职责’ 没办法兼顾，实力不允许啊，但我觉得按领导的对 QA 的描述，他给出的 QA 不是行业标准的那种，就是 ‘QA 只制定规范，保证规范被正确执行。’，他描述的不是这种，感觉像是项目经理或者团队融合剂，比如领导说：“咱们现在测试做的好多事，都是 QA 的”。我反驳的理由很单薄吖：“没人上吖，公司业务到那个点儿了吖，本来就不是测试的事情，是产品的事情”。 领导：“不是产品的事情，是 QA 的事情”。 我：“而且测试组整体实力是不允许的，没办法兼顾”；。

‘出具上线标准，和上线决策权’ 这两个东西我觉得测试都不应该参与吖，但是领导是觉得，就应该测试来做。理由也是简单粗暴，跟上面的问题是继承的。大概意思就是，为了要对项目质量负责，那么就需要决策权，不然，测试是没有立场的。

我还是妥协了的，毕竟是领导嘛。掰扯清楚了几个东西。

1. 要做这些规范是因为目前的项目上线和项目开发过程中，总是有这样那样的问题，不顺畅，且上线后质量不高。

2.是明确出了，不管是 QA 还是 QC 都是不能解决问题的，应该是需要一个 ‘项目经理’ 来串，串各部门各小组，协调作业，效率高一点。

3.是领导理这些问题的时候，觉得，测试这边要扩大职责，扩大职责就需要干这几件事情。
1》明确缺陷 bug 分级（本来是有的，但是是内部的，没公布过，这次这么郑重的话，那么是要重新定义的）
2》出具测试报告，报告包含，验收和分出去的 UI 测试缺陷部分
3》制定上线标准

这几件事情，除了第一个我觉得可以做，剩余 2 个我都不想做。诶，脑壳痛

明天跟领导会继续讨论。 我有做的不对的地方，亲们，请指教哈。

我觉得 ui 这个事，你领导说的对

从测试用例里抽取是可以的。能杠起来是觉得这部分跟测试是没有关系的，不用测试干预验收的事情，也不用把验收结果纳入测试报告。

阿？这样啊。我是觉得测试本来就有做 ui 还原度测试，不应该让 ui 全权接手。

用户验收测试，简称 uat，是一直以来都有的概念，很多公司都有这个环节。

嗯嗯，是的，这是肯定有的。我挣扎的是说，这个环节测试不用参与。

我的一些意见，仅供参考：
1、UI 部分：我觉得是完全 OK 的，因为有些时候，测试只能保证没有研发的 BUG（起码是这个方向），并不能保证没有产品或者 UI 的 BUG，最常见的一种情况就是，实际效果与产品或者 UI 同学预期不符。所以让相关同学到测试环境验收是很好的解决办法。
2、上线标准部分：这个标准没有确切的指出是程序质量标准，还是产品设计标准。如果是前者，肯定可以测试出具的；如果是后者，最好还是设计或者产品自己来啊。
3、出具测试报告：可以帮忙出具报告
4、决策权：还是跟 1、2 点一样，分为从实现质量方面来决策是否上线，还是产品质量来决策是否上限，前者我们可以接，后者肯定不接啊。不是为了甩锅，我们要做自己专业能力内的事情，不要去接别人专业能力内的事情（产品质量是指设计质量）

我的观点是上线决策如果测试能力足够是可以测试做。
但是实际执行的过程中，除了华为，可能测试都没有这么大的决策权。
原因在于：
1.是不是对故障 0 容忍。
2.如果原因 1 不成立，测试能否从项目整体、产品整体思考问题。
我个人是不同意测试决策上线的，最好还是产品经理和项目经理决策。

谢谢指教！
嗯嗯，是的，UI 这部分已经共识了。测试报告是可以出的，争执的是出具范围嘛。产品质量和产品设计标准，领导没提到，不确定是忘了。

emmm...然后是，我不理解这个产品质量和产品设计标准，同 ‘实际实现质量，程序质量标准’ 的区别在哪里？

项目质量包括过程质量、代码质量和测试质量，只有测试保证不了质量的

分那么清楚干啥……测试也是人家做，你无非就是帮忙把报告一起发了啊，这 SIT、UAT 两份报告少一份怎么能够上线呢？
我觉得你可能就是不想去写那个报告而已，如果都是系统自动给你生成了，你还会纠结这个问题吗？

1.整个团队为产品质量负责，而不仅仅是测试
2.测试顶多能决策这个产品具备达到上线的质量要求，上不上是需要看整体安排、用户需求、业务规划的。测试能决定上，就说明产品没啥整体规划，或者对这些不敏感，能上就无脑上了。
3.如果需求上明确指出哪个色号，间隔几个像素，粗细几个像素，测试能不测？
4.说实话，项目里角色其实并不完全是泾渭分明的，你强你可以多管管，能力不行就多学。围绕 “整个团队为产品质量负责”，问题都是能解决的。从出发点就开始分锅，最后的解决大多不欢而散。

分清楚职责和我帮你去做，是两个事情嘛。因为是在界定职责晒。 测试报告是肯定该测试出的，帮忙的部分在界定的时候就需要界定出来。

领导认为，项目开发完成后，包括迭代开发完成，流程里面要把验收加进来，但是应该由测试出具 ‘验收文档’，再把验收情况结果纳入测试报告中展示，并由测试决策，这次上不上线。

我觉得你领导说的没啥问题，是你过度解读了而已，至于那个由测试决策……其实只是说决策质量或者测试这个工作环节的成果是否达成出口标准了，未达成，测试有一票否决权而已，否则难不成需求都没做完测试就有权力要求必须上线？

我觉着我是没有过渡的，这次讨论的范围，本来定义的就是梳理规范，流程，职责和职责边界定义。再是说，根据我们公司具体情况，具体安排。

你看哈。产品项目流程加入 ‘验收’，这个没毛病，本来就应该加。然后是说，测试出具测试报告的范围，比如说，纳入验收部分，那么这份报告的性质就变了，就不是单纯 ‘测试报告’ 了，这份报告应该是 ‘’ 项目实际情况阶段报告 ‘’ 类似这种的了。

再有是 ‘否决权和决策权’ 这个事情，因为领导是把这两个混成一个的，按照你举例子来，意思就是，既然测试说上线了，那么需求完成没完成就是可以上线的。这才能让测试对 ‘质量负责’，就是测试对上线是完全把控的。

嗯嗯，谢谢指教。

是的，上线决策这个事情，测试组我评估出的是没有这个能力做。我也是告诉领导，如果执意要求的话，那么测试定义的上线标准就是 ‘0bug 上线，即所提出的所有 bug 都被修复无衍生问题就上线’，这样测试才能保证做出的 ‘上线决策’ 是不会出问题的，避免因对整体项目/公司计划/业务理解偏差不到位造成事故

嗯嗯，谢谢指教。

感觉领导是想要项目质量是可以被监管可以及时干预的。所有，这块的话，应当是除测试外的另一个岗位来做这个职责。

嗯嗯，谢谢指教。

是的，不同的职能，要求和承担的责任就会不一样。

今天依然是跟领导继续讨论的一天，但是还没有最终定义的。今天没有进行电话会议了，昨天电话了一天没有实质性进展而且耽误工作，所有改变策略，用微信群远程，而且，我觉得，文字在一个字一个字敲出来之后，也会再次思考一次是否合适。所以，今天经过上午的沟通，有进展，但还没有结束。

如，上午跟领导已经有共识。测试不做上线决策。出具的测试报告中不含 UI/验收部分，如果涵盖那么就是另一个意义上的报告了，跟测试脱出来。

我有做的不对的地方，再次请 ‘亲们’ 指教哈。

说说个人拙见：
1.验收测试，肯定是由用户方来做验证。前期测试工作比较到位、测试场景覆盖全的话，一般不会担心用户验收会出现问题，因为能发现的问题在测试阶段都已经提交并得到修复了。如果验收测试过程，还发现明显的缺陷，那说明测试工作还是有疏漏（这也是难免的问题）。所以这时候可以要求产品/用户，提供 UAT 测试业务场景，在交付验收前，把他们比较关注的业务场景测一遍；
2.测试对于项目上线有决策权，这个我理解测试对能否上线有一定的表决权，能否上线估计测试决定不了，至少在上线前我会把测试过程存在的潜在风险问题提出来，研发评估、产品是否接受，一致觉得没问题那就上线（最终决定是否上线还是老板，除非测试人员能力非常强，能够把控到位，不过身边没遇到过这样的 leader 或同事）；
3.关于测试报告问题，这个属于测试职责范围内的事情，测试相关的产出测试人员做好相应记录。

能力强嘛就多做点，多承担点；能力有待提高，就多学点；技多不压身嘛。

嗯嗯，是的。 测试产出是需要做好对应记录。
能力强多做点是关系的，多学习总是好的。
就我坚持的是：如果是在界定职责范围，那就是需要明确的定出来。

感谢亲的，指教啦~谢谢你。

en......看了一半，忍不住出来冒个泡。 首先夸下你领导，我觉得做法没什么问题，和我们目前实践的过程很相似。

1，验收要由测试做用例文档出来，供需求方来验收。
2，测试应有决策权，决定项目上线否。
3，决定上线应对照上线标准来，但是上线标准是根据测试报告来的。

问题 1： 我不清楚你们的业务是自研的系统还是向第三方开发的系统，如果是第三方的，这个步骤肯定非做不可，这个是交付物之一。
如果是自研的东西，也是要测试用例的。不过在于测试用例是啥形式。
比如公司自己的电商网站，俩周一迭代，处于项目前期，那么着重与内部迭代堆砌功能，写个 xmind 保障快速验证就 ok 了。
到中后期以后，每次上线都要做大量的回归，那么这个时候要分析的东西就多了，是否影响其他功能，是否影响历史数据，是否要做兼容性测试？压力测试做了没？主流程要跑哪些？ 最关键的是，你怎么证明你的结论是可信的 ----- 只有用例。只有你执行用例的测试计划能说明。

问题 2：测试是否要有决策权，决定项目上线否？
必须要有， 这个是血淋淋的教训，遇到能放权的领导，一定要逮住别放。
我们之前发布节奏很紧张，由于是按照微服务拆分的团队，中间还会时不时的出现各团队发布热修复的事情。 所以项目交错的情况下，时不时来个发布，测试会疲于奔命，累死不说，还无法保障发布质量，上线就背锅。
反馈有有风险之后，前面的领导的解决办法就是，加班或者号召开发一起测试。但是实际产出是不明显的，在团队能力没有达到快速验证，快速发布的情况下，发布的越多，失误越多。 测试全盘防守，bug 攻其一点，屡战屡败。
后来新调任的大佬拍板，后续的发布申请最后一环由测试团队老大决定是否发布，发布频率要维持两周一个版本，中间发布的规则，测试来制定。 这样运行以后，测试这边的工作量大幅下降，除了一个第三方对接的问题，目前其他团队没有听说反馈很严重的线上问题了。

问题 3：上线标准的问题。
一定要有，和问题 2 结合起来看。 建议采用 DI 值来控制质量，大于 DI 阈值，坚决不能上线。
这个 DI 的结果是直接从测试的测试报告中拿来的，让测试的结果直接决定是否达到质量标准。这样测试才能对质量负责，其他情况下受团队干扰或者发布日期干扰后得出来的发布结论都是不靠谱的，猜都不用猜，肯定是带病上线。

再后说下 UI 校验产出的问题。
测试做 UI 测试，真的是不专业，这个是事实。 产品上线后，UI 有问题，测试挨骂，UI 也得挨骂。
所以怎么办？专业的人做专业的事。 每个迭代发布前，让 UI 检查交互和页面是否符合自己的设计，但是问题的定级是否必须修改，这个需要测试和 UI 讨论下。

最后说下测试的角色。
以前看过一个大佬的帖子，说测试以前分功能测试，QA，测试开发，现在是三位一体。我觉得很对，我们这边目前招聘测试都是要问下是否用过 python，有没有写过自动化代码，你们的迭代过程哪里做的好，哪里不好，出现过最大的线上问题是啥，迭代延期了测试是怎么做的。 为什么问这个，因为这个就是测试现在面临的问题。
敏捷的文化已经流行起来了，当开发是小团队运行的时候，测试也会跟着去适应。1~2 个人负责一个团队的日常测试工作的时候，除了用例设计，执行这些要掌握，团队的沟通，问题反馈，持续改进，自动化落地，这些都是测试的事情。
测试处在整个软件开发过程的相对最末端，前面的需求，设计，开发，转测，哪个环节出了问题，受苦的不得是测试。 所以，保证一定的敏感度，推动改进，从利己的角度讲，也是必要的。

测试这个岗位需要懂的东西很多，除了测试理论，往高了走，简单的运维，开发技能，项目管理能力，推动解决复杂问题的能力，团队管理能力都是路上的必修课。

从你提问看起来，目前你应该是团队的 leader 了，最后，祝你好运！能快速的成长起来

大概看了下，没毛病。 为何要把边界分的那么清楚，部门内，哪个环节做更适合，就可以去干 。

我上个公司比较正规，可以给你参考下

1.测试中，我们会做UI和功能的测试，UI测试就看设计是否和实际一致。至于像素级的后面UED验收的时候会和前端要求更改
2.验收分四步，第一步测试分别在测试环境验收。第二步产品，UED在测试环境验收，产品验收功能，UED验收UI。第三步测试决定上预发布环境，验收；测试决定上生成环境，验收。第四步，发上线邮件。

整个过程都是测试做决策，因为测试是产品质量的保障，无论提前上线，插入新需求，延期上线都应该由测试决定。这关系着上线的质量。只不过相应的权力越大责任就越大。决定上线后测试的锅是最大的，开发只占小部分。

先感谢亲的长篇回复。我觉得你一定是个很温暖的人，愿意分享经验给我。所以，再次 ‘万分感谢您的指教，感谢’！！！

我们是自研业务项目，测试用例是用的 Excel 表格来做。测试计划倒是提醒了我，我之前是没有进行过书面的文档计划制定，都是靠经验来的，现在看来很不靠谱，我会提上日程，感谢亲！

我不接这个决策权是实力不允许，无法达成此项成就。按之前经验，我的确是在每次迭代过程中是做上线决定的那个人（这也是领导想让测试做决策的原因之一），但是是有前置条件的，就是时间节点已经非常明确，是非上不可的那种。这时我能把控的是说上线内容不会出现大问题，而且我能把控的只是研发完成进度和修复 bug 进度情况。相对于亲你的实际情况哈，我们公司 1 是没有做微服务化才分，2 是模式还是传统的开发模式，3 是产品总监也干预不了老板要求。大概就是每次干扰上线节奏的，是排期功能巨多完全不看实力，还有研发实际技术能力和公司穿插的业务支持工作。这不是测试做制定就能够干预的，1 是无法干预公司高层觉得和技术实力，2 是无法跟公司高层或业务层进行时时共享，协调支持时间或提早干预。 当然，亲的建议我还是觉得很合理，如果是专业的互联网公司，这样子的权限下放我还是很乐意接受的，但是，具体情况具体分析晒！

关于上线标准，前面有位同学的建议，我觉得是可以有，这个 DI 阈值确实只能保证实现质量，但是能否上线，应该还是需要一个业务标准来 参考哈。然后是具体情况具体分析，跟领导前两天的沟通力，我公司是允许带小瑕疵上线，而我是觉得的：有时候小瑕疵可能会影响业务但不影响功能。

UI 测试这个问题是在争执，UI 组去测试之后给的问题反馈是测试去回测还是 UI 自己去。然后就说到界定 UI 测试的范围，比如说样式布局算 UI 的还是测试的。领导给了个很有意思的界定，即：“测试组在测试过程中，如果能不去跟 UI 组确定核实的，就不是 UI 校验的东西”。emmm...诶，反正讨论已经结束了。现在正在执行中，UI 组一直喊我们去给他造数据，因为有些页面，有些小功能都出不来，我们又比较忙没时间造的很细致，就一直跟 UI 皮，磨....

就我自己来讲，我是不介意多做事情，因为我自己对这个是抱着学习态度的，做的越多知道的越多经验越多，往后越轻松，路越宽。

但就这个公司这个领导来讲，如果领导坚持界定职责范围，流程规范，我会坚持，定义就要去定义得清楚明白的。

最后，再次感谢你，谢谢你，分享经验给我。

嗯嗯，是的呢，不太理解在项目这个阶段为啥要来做这个。因为是领导要开始做制度规范嘛，我觉得既然要做制度那就不能模糊，不然实施起来就会有很多问题，还是尽量清楚。

嗯嗯是的，做决策的自然是要承担对应责任的。还有是，我们这边测试要是做决策，相对应的制度规范从上到下都应该是有测试来定，这样才能全面提高项目质量，如果只是这一个 ‘上线否决策’ 由测试定，那也是无法保障的。再说，我们测试这边暂时做不了这些的制度规范，经验不够眼界不够，再是公司层也不会允许的。

最后，感谢你的回复和经验分享！谢谢！

'实际实现质量，程序质量标准'就是 “程序实际实现的质量”，设计质量一般指的是比如这个按钮是否美观，功能是否便捷

喔喔，好的呐，谢谢你分享经验给我。

我一般都是大概长得和设计图差不多就行了，等到最后要上线前，让设计自己过一遍，因为他们会纠结像素，间距啥的，我不是像素眼，我看不出来。
而且最后也会在上线前，给产品过一遍，因为是他设计的需求，他过一遍可能会发现我没有注意到的事情。
对于测试拥有上线决策权，我是持赞成态度的。如果测试说不能上线老板非要上线，上完出问题又会是测试背锅的

没有长篇回复，大概表明下我的观点：

1. 测试应该出测试报告，但是报告的内容必须是自己经手的，在测试团队的测试范围内！
2. UI 测试，测试团队测试较大粒度的测试，比如明显的位置偏差，按钮状态的变化，和 UI 设计图大致相符；更具体的小粒度（色号，像素级别的偏差）应该有 UI 设计团队负责，他们可以私下沟通解决，也可以给他们专门设置一个 BUG 类型让他们提交跟踪；
3. 上线标准应该是项目初期决定的，测试不能拥有上线决策权，但必须有表决权和否决权；测试只能出具系统是否达到上线标准和目前现状的测试报告，具体是否上线，应该有产品经理或项目经历进行评估和决策，但是在底线问题上测试团队可以在测试报告中针对某些问题拒绝上线！

嗯嗯，谢谢你，分享经验和看法给我。 我已经搁置和领导谈这个事情了，主要我也没有想的很明白。

嗯嗯，是的，测试报告只能出具自己经手后的。UI 这个领导已经拍板了，没得反驳余地，我也只能从旁协助，尽力。 上线标准，还未敲定，但我已经搁置和领导谈这个了。主要也没想明白。

最后，谢谢你，感谢分享经验和看法给我。

说下我的看法：我们是一个小公司，规模大约 50 人左右，测试 5 人，经过几年的摸索，目前的比较有效的模式是测试实际担当 QA 的责任，包括整个公司流程，上线决策都是 QA 决定，QA 拥有一票否决权，包括不合理需求也会否决；在提交测试前，开发要测试环境自测 - 提交产品验收 - 提交 UI 评审，产品和 UI 评审通过后，提交 QA 测试，QA 主要关注功能测试，当然 UI 有遗漏的也会关注到，测试通过会通知产品开发，他们在根据计划安排上线；责任方面，首先一定要明确，测试其实是决定不了质量的，开发永远是 BUG 第一负责人，其他人包括产品等连带责任，这样的好处是开发责任心大大增加，经常是积极协助 QA 测试，共同避免各种漏测情况，在开发是质量第一负责人的前提下，他们也积极进行质量左移，进行代码评审等工作；测试报告测试可以出，一定要明确目前测试情况以及预计风险等。

好哒，亲分享的经验很有用。我记下了。感谢你

今天跟领导聊了哈，细节。大体上就是这些东西。很细致了，但，上线标准哪里还是没有定。我也没整明白，这个东西该怎么弄。
说明，红色字体部分是确认了的。

测试只需要给出版本测试结果、上线意见，上不上不应该由测试说得算。

有 bug 也可以上线 上线不上线是取决于利益，质量这个东西没有 100% 不信你问问微软。测试可以去做上线决策 但是一定不符合老板的预期。真正的老板是让合适的人做合适的事情，知人善用此乃王道。