测试 - 估算技术

软件测试 - 估算技术

估算软件测试所需的工作量是项目规划中的一项关键任务。准确的估算有助于资源分配、时间线管理和预算控制，最终有助于实现有效的测试覆盖率和软件质量。本节描述了各种测试估算技术，从传统方法到现代敏捷方法。

重要的是要记住，估算不是一门精确科学，应在整个项目生命周期中进行回顾和细化。

传统估算技术

功能点分析 (Function Point Analysis - FPA)

功能点分析是一种结构化技术，用于从用户视角基于软件的功能衡量其规模。它将系统功能分为以下类型：

• 外部输入 (EIs)：进入系统的数据。
• 外部输出 (EOs)：离开系统的数据（报告、屏幕）。
• 外部查询 (EQs)：用户对特定信息的请求。
• 内部逻辑文件 (ILFs)：在系统内部维护的数据。
• 外部接口文件 (EIFs)：系统引用但在别处维护的数据。

每种功能类型都被分配一个复杂度评级（低、中、高）并进行加权。加权功能点的总和给出了软件规模的度量，然后可以将其与历史生产力数据一起用于估算测试工作量。IFPUG (国际功能点用户组) 提供了 FPA 的标准化指南。

测试点分析 (Test Point Analysis - TPA)

测试点分析是 FPA 的一个扩展，专门用于估算黑盒或验收测试工作量。它考虑的因素包括规模（源自功能点）、功能的复杂度、系统接口、功能的一致性以及所选的测试策略。与测试级别和类型相关的动态点也被纳入计算测试点，然后转化为工作量。

Mark-II 方法

Mark-II (或 MkII) FPA 方法是功能点分析的另一种变体，它也从功能视角估算软件规模。该过程包括：

• 定义估算视角、目的和范围（边界）。
• 识别逻辑事务（由事件触发的过程）。
• 识别并分类事务涉及的数据实体类型。
• 计算每个事务的输入数据元素类型。
• 基于这些组件计算功能规模。

与 FPA 一样，得到的规模估算与生产力因子一起用于推导工作量。

基于经验及其他技术

类比估算 (Analogy-Based Estimation)

此技术涉及根据过去类似项目或任务的实际工作量来估算工作量。准确性取决于当前项目与过去项目的相似性以及可靠历史数据的可用性。它需要仔细判断以调整差异。

专家判断 (Expert Judgment)（例如 Delphi 技术）

专家判断依赖于一位或多位专家的直觉和经验。Delphi 技术是一种更结构化的形式，多位专家匿名提供估算。引导者整理这些估算，分享总结，然后专家修订他们的估算。这种迭代过程持续进行，直到达成共识或稳定范围，从而减少个人偏见。

基于测试用例枚举的估算 (Test Case Enumeration Based Estimation)

此方法估算需要设计和执行的测试用例总数。然后，基于历史数据或专家判断，应用每个测试用例的平均工作量（用于设计、执行、报告），以计算总测试工作量。

工作分解结构 (WBS) / 基于任务的估算 (Task-Based Estimation)

将测试项目分解为更小、更易于管理的任务（例如，测试计划、测试设计、测试环境搭建、按模块执行测试、报告）。然后估算每个单独任务的工作量，并将这些估算值相加得到总项目工作量。这是一种自底向上方法。

三点估算 (Three-Point Estimation)（类似 PERT）

对于每个任务，提供三个估算值：乐观值 (O)、最可能值 (M) 和悲观值 (P)。最终估算值 (E) 可以使用加权平均计算，通常 E = (O + 4M + P) / 6。此技术承认不确定性并提供更现实的范围。

测试估算最佳实践

• 让整个团队（包括测试人员、开发者和产品负责人）参与估算过程。
• 将大型任务分解为更小、更易于管理的单元。
• 尽可能使用历史数据和过去项目的指标。
• 清晰记录估算过程中做出的假设。
• 考虑不明显的任务，例如测试环境搭建、测试数据创建、会议和缺陷再测试。
• 随着更多信息的可用或项目范围的变化，定期重新审视和细化估算。
• 考虑风险和意外情况；复杂或不确定的任务可能需要缓冲/储备。
• 选择适合项目背景、方法论和可用信息的估算技术。