有没有用于估计 UAT 工作量的经验法则 - 例如脚本数量与业务需求数量的比较？
我正在尝试估计测试项目所需的测试人员数量。 一种方法是确定所需的脚本数量，并且想知道与需求数量相比是否存在脚本数量的经验法则。 我估计 2 - 3。
- 1 为晴天类型测试
- 1 为阴性测试
- 1 为至少将 1 项要求测试与至少一项其他测试结合起来。
但这只是我最初的猜测。 如果有一些最佳实践，我会洗耳恭听。 再次强调，这不是为了单元测试或系统测试，而是为了用户验收测试。
I'm attempting to estimate the number or testers required to test out a project. One method is to determine the number of scripts that will be required and was wondering if there was a rule of thumb for number of scripts as compare to number of requirements.
I'm estimating 2 - 3.
- 1 for a sunny day type test
- 1 for a negative test
- 1 for at least combining 1 requirement test with at least one other.
but that's just my initial guess. If there are some best practices, I'm all ears.
Again, this is not for unit testing or systems testing, this is for user acceptance testing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议从几个不同的角度来考虑，并在考虑以下因素后做出决定：
1）你的粗略计算...每个要求 2.5 个测试用例（但 Jeff Fry 的观点是正确的，有时会需要更多测试用例）需要，有时更少）
2) 快速计算 1/N 时间的答案...我们上次用于这种一般类型的项目占总体开发时间和/或总体测试时间的百分比是多少？ 做好工作就足够了吗？
3) 花一个小时将参数和值输入到 Hexawise 等测试设计工具中，并创建一组简单的双向（或成对）测试条件。 这样做通常会给您提供最少数量的测试，超出该数量您通常不想削减。 使用测试设计工具的额外好处是，您不仅可以确认规定的要求 1：“使用 Google Chrome 浏览器时网站看起来不错”和规定的要求 2：“用户能够更改他们所使用的信用卡”用于在交易结束时付款”将被测试，而且/未声明/要求（没有人想到要包含在内）“确保使用 Google Chrome 的用户能够更改其信用卡”也将被测试以及。 Expedia 显然没有遵循这种方法，但我离题了......（相关旁注：如果您之前没有尝试过成对测试设计方法或像 Hexawise 这样的工具来帮助半自动测试用例生成，那么您应该期待当您开始使用它时，您会看到测试效率显着提高；实现所有可能的对所需的测试将比您想象的要少：只需 35 次测试即可实现这种类型。与 Google 地图“获取路线”功能测试中的全面测试所需的 720 亿次测试相比，完全成对覆盖。 您的大部分需求都可以轻松地融入测试设计工具中。 有些不会。
4) 如果类似项目被严重低估，则取三个估算的平均值，并增加 20%。
Justin
披露：我是 Hexawise 的创始人，该公司在 www.hexawise.com/users/new 上提供免费版本的测试设计工具
I would recommend coming at it from a couple different angles and making your decision after you consider the following:
1) Your back of the envelope calculation... 2.5 test cases per requirement (but Jeff Fry's point is dead on, sometimes more will be required, sometimes less)
2) Quickly calculate a 1/Nth the time answer... What percent of overall development time and/or overall testing time did we use last time for a project of this general type? Was it enough to do the job well?
3) Spend an hour inputting the parameters and values into a test design tool like Hexawise and create a simple 2-way (or pairwise) set of test conditions. Doing so will generally give you a minimum number of tests, beyond which you wouldn't typically want to cut. The additional benefit of using a test design tool is that you will not only confirm that Stated Requirement #1: "the site looks OK when using the Google Chrome browser" and Stated Requirement #2: "users are able to change the credit card they are using to pay at the end of the transaction" will be tested, but also the /Unstated/ Requirement (that no one thought to include) "Make sure that a user using Google Chrome will be able to change their credit card" gets tested as well. Expedia apparently did not follow this approach, but I digress... (Relevant side note: If you haven't tried pair-wise test design methods or a tool like Hexawise to help with semi-automated test case generation before, you should expect to see a significant increase in your testing efficiency when you begin using it; there will be fewer tests required to achieve all the possible pairs than you would think would be possible. A case in point: only 35 tests are required to achieve this type of full pairwise coverage as compared to the 72 billion tests that would be required for comprehensive testing in a test of the "Get Directions" functionality of Google Maps). Most of your requirements will fit easily into the test design tool. Some won't.
4) Take an average of the three estimates and add 20% to it if similar projects have been significantly underestimated.
Justin
Disclosure: I'm the founder of Hexawise which offers a free version of our test design tool at www.hexawise.com/users/new
您将得到的最佳估计来自进行测试的测试人员。 除了测试人员的这种估计之外，您还可以得出测试时间与开发时间相比的某种百分比。
假设您有一个 100 小时的开发任务。 您花费 20 小时进行设计，80 小时进行构建。 您可能会得出这样的结论：测试需要 15 个小时，或者说开发时间的 15%。 然后，您可以将 15% 应用到 UAT 测试的总体开发估算中，因为您知道有些需要更长的时间，有些则需要更少的时间。
The best estimate you will get comes from the testers doing the testing. Outside of that type of estimate from the testers, you may be able to come up with some sort of percentage of testing time compared to development time.
Say that you had a 100 hour development task. You spend 20 hours on design, 80 hours on build. You might be able to come to the conclusion that it will take 15 hours to test, or 15% of development time. You could then apply 15% to your overall development estimate for UAT testing knowing that some will take longer, some less.
嘿，Shinyfish，我理解想要一个公式的冲动……我向你保证，在狭隘的背景之外，任何通用公式都将被证明是错误的。 考虑有人告诉您每个需求都应该有 N 个与之关联的测试。 现在考虑一些示例要求，例如，
两者都是可能的要求。 第一个相对简单且风险相当低。 第二种有很多潜在的失败点，如果它在很多情况下成功，但在一些看似随机的情况下失败，它就会杀死某人。 任何告诉你计算你的需求然后乘以某个数字的人都是受骗或卖万金油的。
同样，在某些业务环境中，说 UAT 将花费 1/N 的编码时间/可能/是一个有用的启发式方法，但 N 的值在制作博客软件和开发下一版本 Photoshop 的初创公司之间会有很大差异。 就此而言，UAT 的含义（以及您的单元和系统测试涵盖的内容）可能与建议您使用相同术语的人的含义有很大不同。
我可以使用以下经验法则来估计测试将花费多少时间：
首先，在可能的情况下，考虑组织内的类似项目。
当然，有时您没有相关的先前项目可供比较。 如果您不...知道您的估计会有更大的误差范围。 我无法代表您发言，但与我共事过的 98.% 的开发人员（测试人员、编码人员等）长期都低估了这一点。 如果你也是这样，请尝试做出相应的补偿。 也许最重要的是，尝试了解您的估计是否准确，然后相应地设定利益相关者的期望。 提供确定性的幻觉很少对任何人有帮助。
祝你好运！
Hey Shinyfish, I understand the impulse to want a formula...and I'll promise you that any general formula will be provably wrong outside of a narrow context. Consider someone who tells you that every requirement should have N tests associated with it. Now consider a few sample requirements, e.g.
Both are possible requirements. The first is relatively straightforward and fairly low stakes. The second has many potential points of failure, and if it succeeds in many cases but fails in a few seemingly random ones, it'll kill someone. Anyone who tells you to count your requirements and then multiply by something is deluded or selling snake oil.
Similarly, saying that UAT will take 1/Nth the coding time /may/ be a useful heuristic within some business context, but the value for N will vary wildly between, say, a startup making blogging software and developing the next version of Photoshop. For that matter, what /you/ mean by UAT (and what your unit and system testing does(n't) cover) likely varies dramatically from what the folks advising you mean by the same terms.
Here's rule of thumb that I might use to estimate how much time testing'll take:
First, to the extent that it's possible, consider similar projects within your organization.
Of course, sometimes you don't have relevant previous projects to compare to. If you don't...know that your estimate will have a much larger margin of error. I can't speak for you, but 98.% of the developers (testers, coders, etc.) that I've worked with chronically underestimate. If that's true for you, try to compensate accordingly. Perhaps most importantly, try to understand how accurate your estimate is (or isn't) and then set stakeholders' expectations accordingly. Providing an illusion of certainty rarely helps anyone.
Best of luck!