建议选 1，跳槽有的 hr 直接过滤外包经历。

卧槽，精辟，总结很到位，现况就是如此。

一句话需求

只能说互联网行业中的产品能力不可恭维。。但凡有好的产品逻辑和功能，就不会有这么多后面的问题😄

就两名，3 个前端，3 个后端，大概 20 人内的公司，自研

感觉总结起来是产品调研不充分，考虑不全面；评审不认真，事后马后炮赶进度；任务排期混乱，领导、客户说啥就是啥。

你们公司是不是没有测试制定的流程，大概有多少名测试啊

是的，，，我们都是混一起排，大概要多久定个时间，导致，大部分时候，测试都是吃亏的状态，因为还要联调，看需求，写用例，功能测，验收 bug，还有其他的跟产品，开发，扯皮需求，扯完需求可能还要再加逻辑，改逻辑，这么一点时间根本不够。

羡慕了，能够排这么细，人性化。

唉，看来我们公司真的是乱的很，，，全部混一起排了

这排期一看就是瞎搞乱排，工作都没拆分好粒度，怎么可能会科学合理。

正常排期的话，用例编写、测试执行、回归集成都是分开排工作量，这些事情本来就不是并行的（当然一定要并行也不是不行，倒排项目也这样）。

会按实际评估的工作量去排，比如购物车功能：用例编写 0.2 天，测试 1 天，上线 0.5 天，因此共排 1.7 天

我们是这样的：首先产品写出需求后测试组长和开发组长会去评估然后拆分任务，如果没问题的话就开始需求会议。结束之后组长们协调安排日期，开发时间、联调时间、测试时间都要安排清楚，然后就按照安排的时间来。像你说的这种本来就不够的测试时间还要被严重压缩在我这边第一步都过不了

23 年年末再来看，只能说以前的恶果在慢慢呈现

测试相关的文章，在 github 怎么找~~

我想加这个，可以拉我么

全量覆盖没有必要吧，而且也不可能做到

+1，需求变更频繁，领导还拼命推行【全量覆盖自动化】

其实这个问题也要全局去看
1.有很多产品可能是半路接手这个项目，原有功能以及关联影响很难做到全面了解，如果是这个需求一直都是这个产品跟会相对好一点。而测试如果也是半路来的也是一样的其实

情况 1 的出现：测试流程不规范导致，缺少拉通对齐阶段；
解决：a.开发应该对技术方案评审，拉通改动范围，开发内容，涉及上下游
b.TestCase 评审阶段，标记出冒烟用例（给到开发），UAT 用例（给到 PD）；拉通对齐三方
c. 增加 kick off. showCase 等卡点
情况 2 的出现：迭代周期就应该确定好，本迭代内容；
解决：
a.完善提测流程，提测分支锁定，做好发布卡点；
b.TC 评审时确定需求进度，以及提出自己介入时间点以及需要测试时长，防止 开发周期太长，测试时间不够，最后需求超期

情况 3：和情况 1 类似，UAT 用例（给到 PD）,让 PD 明确产品能力
情况 4: 以上情况 123 没资源推动不了解决，趁早跑路...

一个字 摆，我这五年就是这么过来的。

我们像这种情况，都是小需求，简单的功能，，，如果复杂的功能，起码要一个星期。所以我们还没有出现过这种情况，起码要发版之前，要确保功能符合需求，测试通过。

你点评到位，产品确实是对需求，缝缝补补，这里有问题就补这里，那里有问题就补这里，似乎，从头到尾，都是开发跟测试，发现出来的问题，为何产品做不到，甚至再完美一点，从全方面一步到位，可以要求 100% 没有问题，但是起码，也要考虑周全，要不然累死的永远是测试跟开发。

情况 1：需求相关人员拉个群，涉及到需求有啥疑问或者改动直接群里说，确定好改动了再 @ 一下相关人员

情况 2 通常还会叠加几种情况： 冒烟用例过不了无法转测，开发重写，测试这边凌晨才开测