1:4

感谢大佬解答
对于问题 1、也就是说，开发与测试执行的时间比在 2:1 是吧，这测试时间还挺多的，我们实际比例大概是 3:1 或是 4:1
对于问题 3、压缩的时间主要是在提测后测试执行时间上，8 个开发开发了 2 周，2 个测试只给到 2-3 周时间来测试
项目负责人更重视效率不重视质量，急于交付一版成品，压缩时间的后果就是只能保证测试覆盖了主要功能点，细节没时间测。
这和自己想要保证质量是相悖的，但想要快速上线也只能牺牲质量在后续迭代再来弥补，说到底可能还是对质量不够重视

根本原因确实是没有标准的一套流程，没有对资源工作量做一个统计
背景是我们部门没有测试组，测试都是跟着项目走，缺少对测试工作的度量指标，想了解下大佬会从哪些指标来度量测试的工作效果

这个比例和我们差不多

比如开发 8 个人做 2 周，那 2 个测试该给到多久的测试时间呢
-------看团队质量意识，看测试业务熟练程度，看测试基础建设，看开发自测水平，看集成策略，看研发流程总体质量，看进度要求，来总体评估时间。单纯给个比例没啥意义，是在不行根据你们以前的实际样本采样后来评估，虽然各项都在变化，但好歹也有个参考。

在开发过程中，大家除了熟悉需求、设计用例之外还会做些什么
-------在测其他开发提交的测试，在实现别人 PPT 吹的牛逼。

项目负责人在做排期时压缩测试时间，该怎么说服 ta 给到足够的测试时间
-------从风险作为切入口来谈，测试策略上，保障高风险业务的测试时间，低风险业务提前约定好线上缺陷接受程度。如果又不给时间，又不让有缺陷，资源也不给，那就直接开喷，谁嗓门大谁就 NB，大不了打一架，没准比背锅的结果更好也说不准呢。

项目负责人在做排期时压缩测试时间，该怎么说服 ta 给到足够的测试时间

这里没有怎么压缩的细节（比如是测试给出的排期计划有些模块测试时间他认为过久所以压，还是啥细节都不看无脑压），不好说怎么说服。

结合你提到的这个测试跟着项目走的背景，以及项目负责人认为效率优先牺牲质量，那大致能理解项目负责人压缩的出发点。建议是和项目负责人沟通清楚，如果按这个时间，测试只能保障到哪些核心内容，哪些部分无法安排测试会有风险，如果项目负责人接受，那就按这个来走，出问题就拿这个东西来说明这是项目组决定的，有锅一起背。如果项目负责人觉得风险太高，但时间不能延长，那就从别的地方抽调资源来支援（比如这 8 个开发找一些来执行一下测试）。

这和自己想要保证质量是相悖的，但想要快速上线也只能牺牲质量在后续迭代再来弥补，说到底可能还是对质量不够重视

这么说吧，新产品还在求生存的时候，质量只需要保障够用就好，速度高于一切。重视质量细节只会出现在业务已经相对稳定，需要进行用户体验等细节打磨的时候。甚至有的产品其实还在小规模内测/公测阶段，质量要求可以低到只要冒烟测试能通过，就可以上线。公司生存靠的是业务，所以有些时候还是要结合业务来决定质量要求。

感谢解答
工时方面，具体项目情况要具体分析，不过还是想了解下大佬那边的时间比例，大家展示的多了也就知道普遍的一个情况；
开发过程中实现别人 PPT 吹的牛逼，哈哈哈，估计是项目之外针对测试专门的目标吧，我们没测试组，都没 PPT 可以去实现的；
老哥硬气，前期撕破脸总比发生事故了背锅强，是个可借鉴的角度，虽然现实可以不这么激进，但有这个意识还是会想着更多去争取测试时间，保证质量的

我们的比例是浮动的，有 1:2 的，也有 1:8 的，1：14 的，根据待测内容，测试人员素质，产品风险，成熟度等综合评估，最高甚至达到过 2:1，花了两倍开发的时间来测试。单纯固定比例，真不好固定，拍脑袋是简单，后面要还的。

8 个开发做 2 周，其中也区分前后端吧，一般根据业务的复杂度，以及质量要求标准，测试策略整体来评估 pd 数，只要合理，比例什么的应该也不是参考依据吧；

我们一般开发测试时间比 3:1 的，前期可以根据每一个需求的功能点去拆解和估计对应的测试时间，在开发技术方案评审后可以再根据技术难度衡量下前期估时是否需要调整

测试的估时，我这么理解的；
像题主所说的，开发 8 个人要开发 2 周，这周期的需求都算比较大的需求了，因为开发测试的周期总体会拉的比较长；
但是从测试的角度看，当需求评审完，我们这时候就准备着手写用例了，冒烟 case+ 测试 case。后边如果开发有技术需求评审，测试也需要参加，听完开发的逻辑流程在查缺补漏自己的用例。开发提测之前，（我们要完成测试用例的评审）将冒烟 case 给到开发；
当提测之后，如果开发做了冒烟，一般流程是 ok 的，如果有阻塞，提前知会开发解决。
1，两个测试，工作肯定是分模块的，不能两个人做重复的工作，2 个人一起的话，整体测试时间一周吧。算上最后的回归 7 天左右。
2，如果项目负责人压缩测试时间，你可以提供出 case 以及场景，验证了那些场景，还有那些场景没有验证，可以发出来，有哪些场景没有测完，那肯定不能完全压缩呀，还是要按实际情况来的。

测试要用 5 周么？感觉这个时间估出来要挨怼；虽然说开发 8 个人，2 周；但是一个需求或者一个项目是一个小团队来做的，肯定有负责核心逻辑的，也有稍简单的；不能太死板的套用公式；像有些功能或者接口，就是不占用工作量的，核心逻辑才占用测试时间。

上面说了，粗暴呀，而且也说了，要明确标准和流程 才行呀。

8 个开发 2 周，工作量得有多大？
在没有数据、流程支持下，测试时间是不是要最大化？（上线不只是单单 功能测试完就上线了吧，集成、系统测试、上线验收这些都不要时间嘛？）

为什么会被怼，只能说明没有证据证明为什么用这么长时间才是关键，当然这就又回归原点了，没有标准和流程 。

功能或者接口不占用工作量，这不应该是一个测试会说出来的话，这些要不要测试，既然要测试为什么不算工作量呢？

被人怼不可怕，这是催进成长的一部分，如果当有理由和证据说明就需要 5 周，谁来怼，就一句，质量出问题你负主责，我 ok

如果说测试工作效果的话，我们一般会有这几个度量指标：
1、用例完整度 、评审通过率
2、系统测试期间缺陷率
3、功能测试按时完成率
3、上线缺陷率

但这些指标的完成度，又和项目各个阶段又有关系，同时也会对项目其他阶段的一些内容进行管控：
1、需求变更次数（改动较大，或当出现需求歧义时，产品无法快速理清的，推动干掉）

在研发需求分析期间，允许需求变更可能性会大一些，但只要进入开发阶段后，需求变更通过率我们会控制的很低。

2、研发计划（所有的测试时间，都会根据研发计划进行，要求其所有功能全部迭代陆续进行提测）

我们同时也会控制研发计划的变更 ，开发同学只要产品找来说改东西，一般都会接受，但未考虑后续流程是否有影响 ，我们会拒绝所有开发自接的需求，所有需求必须走需求变更

3、功能提测（跟进并推进研发开发进度，确保研发能如期提测）

所有不能如期提测的功能，功能测试只能延后或者进行计划调整

4、缺陷修改周期（严格控制缺陷响应、修改时间，所有超出约定的时间后，测试会进行测试计划调整，项目计划变更）

5、风险控制（研发或测试进度出现严重风险）

周知项目，安排加班或砍需求，推进闭环。
加班可以加，但是项目需要知晓为什么加班解决了，

6、资源日历（人员工作量情况，人员分布 情况）
记录所有资源分布情况，当出现强加需求或者无法拒绝需求时，与大家一起调整资源日历

当然这样的话，测试做的事情会有些多，像以前团队就负责了需求管理、计划管理、进度管理、风险管理，最终上线日期其实也是测试根据各种计划给出的。（当然固定发版日项目，所有计划全部向上逆推）

多谢大佬答疑，学到了

哈哈，大哥硬气

研发评估工期，主要考虑功能难易程度和每个人研发人员的个人能力，测试其实也可以相似，从功能的复杂度、测试方法、个人能力等方面评估