情况 1：
需求定的时候是 A 需求，，开发的也是 A 需求，可能开发过程中，变成 A+ 需求
丢到测试这边，测出来有一些逻辑问题，可能会变成 A+++++ 需求
期间开发不知情，测试提了 bug 给开发，开发很愤怒，表示不知情，开发的时候并没有这个需求
虽然可以提转任务，，，但是一些需求达不到转任务的要求，因为就是一些细微的调整，但又涉及的地方多
情况 2：
需求早上提，中午评审，下午开发，傍晚测试，，，晚上发版
情况 3：
需求开发完，发版线上，，，客户试用完，这里有问题那里有问题，，，需求跟客户实际需求有偏差
导致，不断的迭代，需求推翻，重构优化
你很难想象，同一个功能，，在一年内，翻了 4 个版本，，每个版本都是大改里面的逻辑。
情况 4：
导致幕后老板不满意，一度怀疑是技术开发的问题，属于那种，吃力不讨好，做了，又达不到效果，不做又不行。
情况 1： 很正常，你这是遇到工作经验不足且意志不坚定的产品，对初始需求缝缝补补，然后又不同步需求更新情况，导致转测时，开发 产品 测试三者的信息不一致
情况 2： 也很正常，小的项目节奏都很快，例如 H5 需求
情况 3： 流程问题，但是也属于现实中很可能发生的事，甚至还有客户满意了，但是大老板不满意的场景。这种只能你们产品去带头搞好体验
情况 4： 大老板只看结果和数据，所以需要会写 ppt 的人和做些看得到的事
你这些情况都是现实测试会遇到的情况，个人感觉实际的测试工作这些才是难点，具体就看你怎么权衡了。很多技术帖都是贴着最理想的情况去做一些左右移的理论描述，现实里就是这样，光是需求这一块，产品流动几个，流程就乱七八糟了
情况 1：需求相关人员拉个群，涉及到需求有啥疑问或者改动直接群里说，确定好改动了再 @ 一下相关人员
万文博
回复
你点评到位，产品确实是对需求，缝缝补补，这里有问题就补这里，那里有问题就补这里，似乎，从头到尾，都是开发跟测试，发现出来的问题，为何产品做不到，甚至再完美一点，从全方面一步到位，可以要求 100% 没有问题，但是起码，也要考虑周全，要不然累死的永远是测试跟开发。
万文博
回复
我们像这种情况，都是小需求，简单的功能，，，如果复杂的功能，起码要一个星期。所以我们还没有出现过这种情况，起码要发版之前，要确保功能符合需求，测试通过。
一个字 摆，我这五年就是这么过来的。
情况 1 的出现：测试流程不规范导致，缺少拉通对齐阶段；
解决：a.开发应该对技术方案评审，拉通改动范围，开发内容，涉及上下游
b.TestCase 评审阶段，标记出冒烟用例（给到开发），UAT 用例（给到 PD）；拉通对齐三方
c. 增加 kick off. showCase 等卡点
情况 2 的出现：迭代周期就应该确定好，本迭代内容；
解决：
a.完善提测流程，提测分支锁定，做好发布卡点；
b.TC 评审时确定需求进度，以及提出自己介入时间点以及需要测试时长，防止 开发周期太长，测试时间不够，最后需求超期
情况 3：和情况 1 类似，UAT 用例（给到 PD）,让 PD 明确产品能力
情况 4: 以上情况 123 没资源推动不了解决，趁早跑路...
夏思聪
回复
其实这个问题也要全局去看
1.有很多产品可能是半路接手这个项目，原有功能以及关联影响很难做到全面了解，如果是这个需求一直都是这个产品跟会相对好一点。而测试如果也是半路来的也是一样的其实
+1，需求变更频繁，领导还拼命推行【全量覆盖自动化】
感觉总结起来是产品调研不充分，考虑不全面；评审不认真，事后马后炮赶进度；任务排期混乱，领导、客户说啥就是啥。
只能说互联网行业中的产品能力不可恭维。。但凡有好的产品逻辑和功能，就不会有这么多后面的问题😄
一句话需求
踢 
