与业务需求的数量相比，任何用于评估UAT工作的经验规则--类似于脚本数量？

Question

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

• 1用于晴天类型测试，
• 1用于阴性测试，
• 1用于至少将1项需求测试与至少一项其他测试相结合。

但这只是我最初的猜测。如果有什么最好的做法，我会全神贯注的。同样，这不是用于单元测试或系统测试，而是用于用户验收测试。

Answer 1

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

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

Answer 2

嘿，新鱼，我理解你想要一个formula...and的冲动--我向你保证，任何一般的公式都会在狭窄的上下文之外被证明是错误的。假设有人告诉您，每个需求都应该有N个相关的测试。现在考虑几个示例需求，例如。

1. 用户名字段至少需要6个字母数字字符，而
2. 剂量计算器将根据患者的年龄、性别和体重正确计算出患者的危险药物剂量。

两者都是可能的要求。第一个是相对简单和相当低的利害关系。第二种方法有很多潜在的失败点，如果它在许多情况下成功，但在一些看似随机的情况下失败，它会杀死一个人。任何人告诉你数你的需求，然后乘以某物是欺骗或出售蛇油。

同样，说UAT将花费1/N的编码时间/可能/在某些业务上下文中是一个有用的启发式，但是N的值在创建博客软件的初创公司和开发下一个版本Photoshop之间会有很大的不同。因此，UAT的/ you /含义(以及您的单元和系统测试所做的(不包括))可能与建议您使用相同术语的人员的含义有很大的不同。

下面是我可能用来估计测试所需时间的经验法则：

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

projects?

• How

• 他们得到了多少人/天的测试？

• 对产品测试的彻底程度感到满意吗？

• ，您认为这个新项目与以前的测试相似/不同吗?与以前的测试人员相比，

• 测试人员有多有经验/技能?与以前的项目相比，他们在一开始就了解这个项目吗？

F 217

当然，有时您没有相关的项目可供比较。如果你不.知道你的估计会有更大的误差。我不能代表您说话，但是98%的开发人员(测试人员、程序员等)我长期被低估了。如果这对你来说是真的，试着相应地补偿。也许最重要的是，试着理解你的估计有多准确(或不准确)，然后相应地设定利益相关者的期望。提供确定性的假象对任何人都没有帮助。

祝你好运！

Answer 3

我建议从几个不同的角度来讨论，并在考虑了以下几点之后做出决定：

1)你后面的信封计算..。2.5每个需求的测试用例(但Jeff Fry的观点已经过时，有时需要更多，有时更少)

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

3)花一个小时将参数和值输入到像Hexawise这样的测试设计工具中，并创建一个简单的双向(或成对)测试条件集。这样做通常会为您提供最小数量的测试，超过这些测试，您通常不会想要削减测试。使用测试设计工具的额外好处是，您不仅将确认声明的要求#1：“当使用Google Chrome浏览器时，站点看起来不错”和声明的要求#2：“用户能够在交易结束时更改他们正在支付的信用卡”，还将测试/未声明/要求(没有人认为包括)“确保使用Google Chrome的用户能够更改他们的信用卡”也将接受测试。Expedia显然没有遵循这个方法，但我偏离了.(相关的边注:如果你以前没有尝试过成对的测试设计方法或者像Hexawise这样的工具来帮助半自动测试用例的生成，那么当您开始使用它时，您应该会看到您的测试效率有了显著的提高；实现所有可能的测试对所需的测试将比您想象的更少。)一个很好的例子是:只需要35个测试就能实现这种类型的完全成对覆盖，而在测试Google的"Get方向“功能时，需要进行720亿次全面测试。您的大部分需求将很容易地融入测试设计工具中。有些人不会。

4)以这3项估计中的平均数字为例，如果类似的项目被严重低估，则增加20%。

贾斯汀

披露:我是Hexawise的创始人，该公司提供我们测试设计工具的免费版本，网址是www.heawise.com/user/new