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

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

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

会按实际评估的工作量去排，比如购物车功能：用例编写 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 通常还会叠加几种情况： 冒烟用例过不了无法转测，开发重写，测试这边凌晨才开测

情况 1： 很正常，你这是遇到工作经验不足且意志不坚定的产品，对初始需求缝缝补补，然后又不同步需求更新情况，导致转测时，开发 产品 测试三者的信息不一致

情况 2： 也很正常，小的项目节奏都很快，例如 H5 需求

情况 3： 流程问题，但是也属于现实中很可能发生的事，甚至还有客户满意了，但是大老板不满意的场景。这种只能你们产品去带头搞好体验

情况 4： 大老板只看结果和数据，所以需要会写 ppt 的人和做些看得到的事

你这些情况都是现实测试会遇到的情况，个人感觉实际的测试工作这些才是难点，具体就看你怎么权衡了。很多技术帖都是贴着最理想的情况去做一些左右移的理论描述，现实里就是这样，光是需求这一块，产品流动几个，流程就乱七八糟了

没啥有效方案，虽然一个接口通了和 10 个接口通了没啥区别，但是你敢不全量回归吗，不回归出了啥问题都是全责

其实要混个证书的话很简单的，我上家公司就是我一个人负责部署和测试的，底层手动回归一下重要的业务，然后普通业务流程保证流程畅通就好了，然后录个视频给适配的厂商，写个文档就好了

俺这边服务端国产化涉及资金支付的系统，全量回归；其他子系统，主流程回归；
另一种客户端国产化的，比如识别指纹，人脸，档案扫描，银行卡身份证识别等等硬件国产化的，兼容性回归。

信创认证吗？这边今年大部分时间都是在搞这些，都是国产中间件适配，目前是接口自动化 + 页面主流程回归

所以你是想测啥？这些东西的变更对你的被测目标有啥影响？

高质量的技术交流群就跟高质量对象一样难找

即使在一个群，不熟悉的人一般没有分享欲望

高质量的群维护成本很高的，早期可以卖课的时候，还有一些儿有人维护的群，后期就不行了。再说了，人家辛苦学到或是总结的技术，为什么要分享出来啊？得不到好处的话，分享的会越来越少的，这也是现在社区里没有好文章的原因。