数据结构
网络
关系数据库管理系统（RDBMS）
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究估算技术指南（软件测试）
对于任何项目的完成，测试的估算和正确的执行与开发周期一样重要。为了与客户建立良好的声誉，坚持估算经验在估算“软件测试工作量”方面起着重要作用。参与各种项目有助于我们对测试周期进行准确的估算。
显然，人们不能简单地为任何测试活动输入几天的时间。测试估算应该既实用又精确。
本文将介绍一些重要的提示，这些提示对于以非常直接的方法准备适当的测试估算非常有用。
测试估算的过程
它是找出估计值或近似值的过程，这是一个可能用于某些目的的数字，即使输入数据不完整、模糊或不稳定。[来源：维基百科]
作为专业人士，我们都会遇到各种工作、义务和截止日期；如今，有两种方法可以解决问题。
第一种方法是反应性策略，在这种策略中，我们只在问题发生后才尝试寻找解决方案。
在第二种方法中，称为主动方法，我们首先在问题出现之前很久就利用我们以前的经验做好准备，然后我们利用过去的经验来尝试在问题出现时找到解决方案。
因此，可以将估算视为在对问题采取主动方法时使用的一种方法。
因此，可以使用估算来估算完成特定工作需要多少时间和金钱方面的努力。一旦测试团队对眼前的问题有了近似了解，他们就能更容易地提出一个最适合当前情况的解决方案。
因此，可以更正式地将估算定义为对劳动成本的可能近似值
先决条件基础
以下是测试估算过程的基本要素。
从以往经验中获得的见解：通常最好花一些时间反思以前遇到过类似于当前问题的困难的项目。
可访问的文档或工件：在这种情况下，测试管理存储库解决方案很有用，因为它们保存了需求和澄清文档。测试团队可以参考这些文档来正确描述项目的范围。
关于工作性质的假设：以前的工作经验有助于建立项目假设。在这种情况下，聘用经验丰富的专家至关重要。测试经理可以选择这些人来进行头脑风暴，以产生所需的结果。
潜在危险和威胁的计算：测试团队还必须设想团队将来可能面临的潜在风险、威胁和陷阱。
确定文档是否已建立基线：测试团队还必须评估需求是否已建立基线。如果文档尚未建立基线，则必须确定更改的频率。
所有职责和依赖关系都必须明确定义 - 组织必须确定所有将进行估算过程的人员的角色和责任。
评估记录的文档并遵循：所有与估算过程相关的信息都应记录下来。
在测试估算过程中要完成的任务 -
组建一个团队来进行估算。
将项目分解为项目阶段和组成活动。
根据以前的项目和专业知识进行估算。
确定潜在的风险并制定策略来最大程度地降低这些风险。
检查并记录工作的相关部分。
将工作发送给相应的利益相关者。
最流行的测试估算技术
一些最重要的测试估算方法包括 -
- 测试点的估算
- 基于工作阶段的估算
- 利用用例点估算
我们在哪里以及如何使用这些技术？
测试点估算是一种基本且易于理解的估算方法，广泛应用于软件测试行业。这种方法最重要的特征是其迭代阶段和简单性。
基于工作阶段的估算是一种估算方法，在这种方法中，对某个阶段（通常是最短和最简单的阶段）进行粗略估算，然后测试团队逐渐将其他阶段添加到原始估算中，以达到可接受的估算。
用例点估算方法用于使用未调整的参与者权重和未调整的用例权重来估算用例上的软件测试。
测试估算示例
让我们尝试在另一种情况下使用上述概念。
假设我们有一个测试需求，需要测试五个测试场景。
假设测试场景 1 有 5 个预期结果，测试场景 2 有 6 个测试预期结果，测试场景 3 只有 2 个测试预期结果，测试场景 4 有 9 个测试预期结果，测试场景 5 同样有 9 个测试预期结果。
根据每个场景中预期结果的总数，我们将测试场景分为三个类别：困难、简单和中等。
复杂类将具有超过 7 个预期结果，而基本类将具有少于 5 个预期结果，中间情况将具有 4 到 7 个预期结果。
因此，我们将测试场景 1 和 2 分类为中等，场景 5 和 6 分类为困难，测试场景 3 分类为基本。
现在所有这些场景都将进行测试点估算。我们对复杂类使用了 5 个测试点，对中等类使用了 3 个测试点，对基本情况使用了 2 个测试点。
在每个测试场景中，我们将假设的测试点乘以预期结果的总数。因此，我们得出以下近似值 -
场景 1：3 个测试点 * 5 个预期测试结果 = 25 个调整后的测试点
场景 2：3 个测试点 * 6 个预期测试结果 = 30 个调整后的测试点
场景 3：2 个测试点 * 2 个预期测试结果 = 4 个调整后的测试点
场景 4：5 个测试点 * 9 个预期测试结果 = 45 个调整后的测试点
场景 5：5 个测试点 * 9 个预期测试结果 = 45 个调整后的测试点
因此，假设我们需要为每个修改后的测试点申请 5 个工时，我们得到以下近似值。
测试场景 1：25 个修改后的测试点乘以 5 个工时为 125 个工时。
场景 2：30 个修改后的测试点乘以 5 个工时等于 150 个工时。
场景 3：4 个修改后的测试点 * 5 个工时等于 20 个工时
场景 4：45 个调整后的测试点乘以 5 个工时为 225 个工时。
场景 5：45 个调整后的测试点乘以 5 个工时为 225 个工时。
因此，估计的总工时为：745 个工时
用例点估算方法
这里给出了用例点估算过程的详细过程 -
将通用需求分解为用例，更准确地说是分解为参与者
计算所有用例中使用的用例参与者的总数
根据用例参与者数量将需求分类为负面、正面和例外
根据每个用例参与者的类别为每个用例参与者分配一个未处理的参与者权重
重复此过程，直到我们获得所有参与者的未处理参与者权重
使用未调整的用例权重和未调整的参与者权重获得未处理的用例点
将未处理的用例点乘以预定义的常数以获得真实的用例点估算
例如，在某个需求中，我们有 5 个用例，用例 1、用例 2 和用例 5。假设用例 1 有 6 个参与者，用例 2 有 15 个参与者，用例 3、4 和 5 分别有 3 个、4 个和 5 个参与者。
任何参与者总数少于 5 的用例都被视为负面用例，任何参与者总数等于或大于 5 且小于或等于 10 的用例都被视为正面用例，任何参与者总数超过 10 的用例都被视为例外用例。
我们选择为例外用例分配 2 分，为正面用例分配 1 分，为负面用例分配 1 分。
根据我们的假设，我们将用例 1 和 5 分类为正面，用例 2 分类为例外，用例 3 和 4 分类为负面。
因此，未处理的参与者权重 = 用例 1 =（参与者总数）5 * 1（分配的点数）= 5。类似地
案例 2 = 15 * 2 = 30。
对其余用例重复此过程，得到未处理的参与者权重 = 33。
未处理的用例权重 = 用例总数乘以 5
未处理的用例点数 = 未调整的参与者权重加上未调整的用例权重 = 33 + 5 = 38
处理后的用例点数 = 38 * [0.65 + (0.01 * 50] = 26.7 或大约 28 人时
工作阶段分解法
工作阶段分解法在以下阶段进行解释。
将整个项目划分为多个阶段。
从最简单的步骤开始，并为其提供一个估算值。
然后，在完成此阶段后，确定可能开始的下一个潜在步骤。
确定可能应用于此阶段的一组潜在近似值，并从近似值列表中选择最大值。
将当前阶段的工时估算值添加到先前存在的估算值中，以获得近似估算值。
重复步骤 3-5，直到第一步中指示的所有阶段都已完成。
接受最终的近似估算值作为最终结果。
假设一个需求中有五个必要的阶段。在第一阶段，我们假设所需的总工作量为 35 人时，然后我们继续进入第二阶段，在第二阶段我们有四个比较假设分别为 35、45、55 和 65。
这里我们考虑最大值 65 人时。阶段 3 和 4 的估算分别为 (12, 33, 43, 54)、(15, 10, 7, 8) 和 (2, 16, 5, 13)。使用上述概念，我们得到 185 人时。
结论
软件测试估算需要熟练专家的参与，以及使用行业最佳实践，例如测试用例点数和用例点数技术。
在定制必要的程序时，保持开放的心态也至关重要。有效地应用这些程序可以提高整个测试过程。
160 次查看
