有一系列关于测试估计的优秀文章，参与产生或使用测试估计的每个人都应该阅读：

• 项目估算和黑天鹅（第 1 部分）
• 项目估算和黑天鹅（第 2 部分）
• 项目估算和黑天鹅（第 3 部分）
• 项目估算和黑天鹅（第 4 部分）
• 项目估算和黑天鹅（第 5 部分）：测试估算

它首先探索项目的蒙特卡洛模拟，展示相对少量的意外如何产生巨大影响，然后讨论管理这种影响的策略，最后特别关注测试。

很多时候，您没有时间制定测试计划，我有时会参加项目规划会议，其中已经给出了一个宏大的范围，然后当场询问工程 - 给出一个估计。基本上它是一种猜谜游戏，这就是估计，如果你被要求给出一个，你可以确定它是错误的。这就是估计。尽管这完全取决于您使用的是哪种流程，但如果这是一个完整的项目，从一开始就开发和测试并行工作，我会想到以下几点：

• 这是新技术吗？开发团队需要学习它，延长他们的时间，所以你需要学习它来测试
• 构建多久来一次？有里程碑吗？是否需要实施新的构建过程？考虑到要测试的代码及其稳定性以及错误修复版本
• 这是否需要新的工具来测试？您需要时间来获取/构建以及设置/训练工具......然后进行一些试运行，看看事情是否按预期工作
• 您将被允许拥有多少资源？它们会被共享吗？这意味着上下文切换和资源损失（紧急情况、假期、人员离职、新员工），您需要正确计划

除了 Glowcoder 提到的内容之外，我还会想到这些，它们将成为任何项目的一部分，并且您必须提供的文档越多，所需的时间也就越长。

首先要看的是发生的类似测试工作。对于类似的更改，在提供的时间下，测试工作的效果如何？历史是寻找所有领域估计的最佳场所。

在进行时间估算之前，测试项目应该有一个测试计划。测试计划中的每个元素都应该有一个估计的完成时间。项目的估计只是每个元素的时间总和，加上与测试不直接相关的一些开销：

• 项目管理
• 讨论，反馈给开发者
• 准备结果
• 技术难点

如果您在没有测试计划的情况下进行估算，那么您就是在设置自己的估算错误。

我同意以上几点：

我在项目中遇到的一些需要考虑的事情是：

• QA 和 DEV 团队在现场、技术等方面的经验
• 识别风险
• 明确哪些将被测试，哪些不会被测试，否则，人们可以假设某些功能已经过测试，并且在最后一分钟团队必须做额外的工作以验证早期未测试的功能游戏
• 此外，在可能的情况下，在估计过程中需要考虑最坏的情况（如果发现问题，如果需要进行研究以了解该功能，可能会有一些阻塞器）