你这个不看具体业务肯定不行啊，有些你前置条件就要准备半天或者 dfx 案例要持续观察的，不可能跟点点点的效率一样

开发测试比

每个人写测试用例的粗细粒度不一样，一个查询功能，能多写也能少写，怎么能按照条数来要求。同理每天执行用例的条数，如果一条场景用例需要外部银行客户的对接，人家配合度好一天能走完几条算不错了，而负责简单功能的人一天执行上百条。测试报告的编写感觉不需要，感觉排期还是得按需求的大小难易程度，对应测试的上手熟悉程度，测试人力等来考虑。

大概用时 +40 % 的预留时间

没有统一标准，只能说凭借测试组内成员的平均数据为基准。

2 楼说得不错，如果你想抛开具体业务，来判断测试工时估的是否合理，就看 开发评估工时 除以 测试评估工时

非特殊业务，只谈基础功能，不考虑数据构造，特殊场景。
单条编写和执行按照 7min 的平均值估算。
缺陷验证和需求澄清保留 1*0.3 时效，其次预留 15-20% 作为紧急插入的风险规避。

不如把问题改成，给你多少时间，你有信心保障项目的质量。
单纯评估人在单位时间设计\执行的数量，意义不大。
量化是件很难的事，表面上好看的数据，可能隐藏了大量电子垃圾。

我的直觉会告诉我需要几天

1:4？

现在有些成员测试的效率很慢，我想的是给一个大概的标准来。这样的人我应该怎么去沟通或者去给他设定目标呢？

这样的话，他多多益善。
现在就是因为有个别成员设计和执行效率很慢，之前甚至一天就执行 10 条。

是个中肯的建议，感谢

也有道理，如果只看点点点呢

我的直觉也会告诉我需要几天

那就看是啥原因了。。。业务不熟 or 杂事很多 or 测试受阻 or 摸鱼划水 or 闪电？建议任务结果驱动，重过程容易导致执行过程变形

结果驱动没问题，关键一个项目测试，别人用 3 天，他要用双倍的时间，最后都是发布上线

用了双倍的时间，有没有高质量的产出呢，如果没有，那帮他找下效率远低于别人的原因啊（没准是别人太 NB 了）。

其实看你的回复，基本心里已经知道他效率有点问题了，你是想帮他解决问题，还是想解决他呢？

直接解决了他吧，这种都不是效率问题，就是态度问题，而且是很严重的态度问题才能到达双倍的比例
和他聊聊，躺平可以但别躺的这么明显，不然都不好办

我一般会问开发需要几天。。然后测试打个五折。。再看看与直觉符不符合。

起初是想帮他解决问题的，可惜一段时间过去了，效率还是很低。另外他工时在团队算高的，也就是说花了很多时间，但是效率还是很低。

工时很多，但是可能有时候对着电脑在发呆

考虑问题不能既要又要也要，很明显，当一个人严重拖了团队的后腿（表现在效率、成果等方面），那么优化掉这个人往往是最优解，不然后面整个团队都会为这个人付出一定的代价，或多或少。

如果是历史业务的优化改动，基于自己对业务的熟悉程度评估。
如果是新的项目，毛估是按照开发与测试 2：1 的工时计算。如果有具体的技术实现方案评审，可以酌情加减时间。（假设开发测试处于同等技术水平下。）
题主所述的情况，建议就是解决带来问题的人是最好的解决方案，虽然看起来有点残忍。

开发的工时是前后端的工时加起来吗？

是的吧。。。你们的开发测试比有时候就一定程度上代表了工作时间比例的评估了，因为人力配比是工作量长期动态平衡的结果。

测试评估?没听说过,一般都是被通知.版本迭代就两天,多一分钟都不行