这个比例对测试来说应该很友好了，为啥测试时间压缩这么严重

如果纠结想去一线大厂就别选外包呗，否则无所谓的；像我一个朋友外包出来，直接跳到一家大的上市公司，薪资也有 20k+

2 是字节外包吧。我曾经带过一个外包，后面干得不错还转正了。

选 1

必然是 2 呀

建议选 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 没资源推动不了解决，趁早跑路...