Testing 与业务需求的数量相比，是否有估算UAT工作量的经验法则（比如脚本的数量）？

我试图估计测试项目所需的测试人员数量。一种方法是确定所需脚本的数量，并且想知道是否有一个经验法则来比较脚本的数量和需求的数量。 我估计是2-3

• 1用于晴天型式试验
• 1为阴性试验
• 1用于至少将一个需求测试与另一个需求测试相结合

但这只是我最初的猜测。如果有一些最佳实践，我洗耳恭听。

---

同样，这不是针对单元测试或系统测试，而是针对用户验收测试。

您将得到的最佳评估来自于进行测试的测试人员。除了测试人员的这种估计之外，您还可以计算出测试时间与开发时间的某种百分比

---

假设您有一个100小时的开发任务。你在设计上花了20个小时，在建造上花了80个小时。您可能会得出这样的结论：测试需要15个小时，或者15%的开发时间。然后，您可以将15%用于UAT测试的总体开发估算，知道有些需要更长的时间，有些需要更少的时间。

嘿，Shinyfish，我理解想要一个公式的冲动……我向您保证，任何通用公式在狭窄的环境之外都是错误的。考虑一个人告诉你每一个需求都应该有与它相关的N个测试。现在考虑几个样本要求，例如

用户名字段至少需要6个字母数字字符，而不是

剂量计算器将根据患者的年龄、性别、体重正确计算患者的危险药物剂量

两者都是可能的要求。第一个相对简单，风险相对较低。第二种方法有许多潜在的失败点，如果它在许多情况下成功，但在一些看似随机的情况下失败，它会杀死一些人。任何人告诉你数一数你的需求，然后乘以一些东西，都是在欺骗你或是在卖蛇油

类似地，说UAT将花费1/N的编码时间/可能/在某些商业环境中是一个有用的启发，但N的值在（比如）一家博客软件初创企业和开发下一个版本的Photoshop之间会有很大的差异。就这一点而言，UAT（以及单元和系统测试（未）涵盖的内容）的含义可能与建议您使用相同术语的人员的含义有很大不同

以下是我可以用来估算测试所需时间的经验法则：

首先，在可能的范围内，考虑组织内的类似项目。

• 他们得到了多少人/天的测试
• 利益相关者对产品测试的彻底程度是否满意
• 你认为这个新项目与以前的项目有什么相似/不同
• 与以前的项目相比，您将获得的测试人员的经验/技能如何
• 与以前的项目相比，他们一开始对该项目的理解程度如何

当然，有时你没有相关的以前的项目可以比较。如果你不知道你的估计会有更大的误差。我不能为你说话，但我工作过的98%的开发人员（测试人员、编码人员等）长期低估了我。如果这对你来说是真的，试着做出相应的补偿。也许最重要的是，试着理解你的估计有多准确（或不准确），然后相应地设定利益相关者的期望。提供确定性的幻觉很少能帮助任何人

---

祝你好运 1） 你的信封背面计算。。。每个需求2.5个测试用例（但Jeff Fry的观点完全正确，有时需要更多，有时需要更少）

2） 快速计算出1/n时间的答案。。。对于这种一般类型的项目，我们上次使用的总体开发时间和/或总体测试时间的百分比是多少？这足以把工作做好吗

3） 花一个小时将参数和值输入到测试设计工具（如Hexawise）中，并创建一组简单的双向（或成对）测试条件。这样做通常会给你一个最小的测试次数，超过这个次数你通常不想削减。使用测试设计工具的另一个好处是，您不仅可以确认所述要求（1:“使用Google Chrome浏览器时网站看起来正常”）和所述要求（2:“用户可以更改他们在交易结束时支付的信用卡”）将被测试，还可以确认/未声明/要求（没有人想到会包括“确保使用谷歌Chrome的用户能够更改他们的信用卡”也得到了测试。Expedia显然没有遵循这一方法，但我离题了。。。（相关旁注：如果您以前没有尝试过成对测试设计方法或像Hexawise这样的工具来帮助生成半自动测试用例，那么您应该期望在开始使用它时看到测试效率的显著提高；实现所有可能的成对测试所需的测试比您想象的要少有可能。举个例子：实现这种类型的完全两两覆盖只需要35个测试，而在谷歌地图的“获取方向”功能测试中，综合测试需要720亿个测试。您的大多数需求将很容易地融入测试设计工具。有些不会

4） 取三个估计值的平均值，如果类似项目被严重低估，则加上20%

贾斯汀

披露：我是