什么是好的启发式方法来生成测试时间估计值作为开发时间的百分比？

Question

我知道有不同的因素会使它更高或更低。我正在寻找一个基本百分比，用于评估软件的测试。

我需要这样做，因为测试人员/QA通常不会咨询用于为他们所要求的新项目向客户收费的估算:相反，我的雇主使用一个基本百分比来得出一个估计值，所以如果开发团队的工作量估计为500个小时，那么预期的测试/QA工作将被设定为开发工作量的20% (100小时)。

我需要一套广泛的指导方针，我的公司可以使用这些准则来生成围绕这些一般原则的测试估计：

• 作为起点的发展努力的基本百分比
• 任何增加测试工作量的因素，以及测试工作量的增加(如需要第三方认证，测试工作量增加50%)。
• 减少测试工作量和减少测试工作量的任何因素(例如集成无法被测试团队访问的嵌入式组件)

Answer 1

这取决于我们正在使用的SDLC方法，例如:如果它是敏捷开发，并且具有持续的集成，那么它应该需要30 %的开发时间。

就像sprint的15天开发一样，如果应用程序的关键特性是自动化的，那么测试所需的时间应该是4.5个工作日。

这还取决于参与测试的QA资源的数量。

Answer 2

简短的版本:如果可能的话，查看您的组织历史，查看每个项目的总测试时间和每个项目的总开发时间。由此可以计算出平均和典型的开发/测试比率。

长期版本:它取决于组织、正在使用的开发方法以及许多其他因素，包括组织维护和构建的应用程序(S)中包含了多少遗留代码。

尽管如此，有许多技术可以帮助为首次通过测试时间估计生成广泛的启发式：

• 历史时间-作为一种规则，组织中典型的开发/测试时间比率是相对稳定的。总会有超出规范范围的项目，但是如果您可以通过数据挖掘来检索每个项目的实际开发时间和实际测试时间，那么异常值就会变得很明显。
• 这是一个典型的项目吗?一个典型的组织项目的开发项目通常会有一个实际的开发时间和接近组织历史规范的测试时间比率(如果在您的组织中，测试所需的时间为开发时间的1/2左右是正常的，那么在开发或测试中不需要任何异常的新项目可能需要测试花费大约1/2的开发时间。
• 是否存在外部依赖--在我的经验中，项目团队控制之外的任何依赖项都会增加所需测试时间的数量，并增加所需测试时间的比例。这大部分时间将涉及到试图确定该bug是与第三方软件还是您的软件(同样，我的经验)。
• 潜在的回归影响--任何新特性都有可能导致回归，但在大型、复杂的应用程序中，特别是具有大量遗留代码的应用程序中，系统中的某些区域会比其他功能更脆弱。如果项目与这些项目交互，测试时间应至少增加50% (如果系统的该部分没有自动回归，则会增加更多)。在极端情况下，我看到测试时间估计高达开发时间的300-500%。
• 它的自动化程度有多高--通常情况下，应该在自动回归中添加新的特性，并且这个因素所需的时间会增加到估计值中(据我的经验，这可以使测试工作的开发时间达到100%，取决于自动化设计的程度-我已经为自动回归添加了新的特性支持，只需额外增加10%的开发人员工作，比如插入一个新的例程来处理新流程，更新几个案例语句，并向测试驱动程序文件和基线文件中添加一些数据)。我还必须构建全新的自动回归处理来弥补空白。前者花费的时间要少得多)。
• 组织是否包括自动化时间--这是一个很大的时间。如果组织不愿意包括更新测试自动化以覆盖新功能的时间，那么这一比率将更低，但未来的维护和手动回归时间将更长，而且技术债务问题会增加很大的风险。

Answer 3

我总是喜欢倡导敏捷软件开发的33%规则。

周期包含三个主要部分(如果可能的话，应该并行执行)

• 需求、设计、用户故事和其他文档
• 编码(使用实心图案 )
• 测试(包括单元测试、集成测试、端-2端测试和连续集成)

如果你不平均花费33%在这三组，你将创建技术债务，并应考虑长期的后果。