软件的测试估算技术指南（软件测试估算教程）
对于任何项目的完成，测试和正确执行的估计与开发周期同样重要。为了在客户中获得良好的声誉，坚持估算经验在估算“软件测试工作量”中起着重要作用。在不同的项目上工作有助于我们准备对测试周期的准确估计。
显然，不能简单地为任何测试活动输入几天。测试估计应该既实用又精确。
本文将介绍一些关键提示，这些提示对于以非常简单的方法准备正确的测试估计非常有用。
测试估算过程
这是找出估计值或近似值的过程，即使输入数据不完整、不明确或不稳定，估计值或近似值也可能用于某些目的。[来源：维基百科]
作为专业人士，我们都会遇到各种各样的工作、义务和截止日期；今天，有两种方法可以找到解决问题的方法。
第一种方法是反应式策略，我们仅在问题发生后才尝试找到解决方案。
在第二种方法中，称为主动方法，我们首先在问题出现之前很久就用我们以前的经验为自己做好准备，然后我们利用过去的经验试图在出现困难时找到解决方案。
因此，估计可以被视为我们对问题采取主动方法时使用的一种方法。
因此，估计可用于估计完成某项工作所需的时间和金钱方面的努力。一旦测试团队掌握了手头问题的近似值，他们就可以更轻松地提出最适合手头情况的解决方案。
因此，估计可以更正式地定义为一项劳动力的可能成本的近似值
先决条件 基础知识
下面列出了测试估计过程的基本要素。
从以前的经验中获得的见解：花一些时间反思以前的举措，这些举措提出了与当前举措相当的困难，这通常是一个好主意。
可访问的论文或工件：在这些情况下，测试管理存储库解决方案非常有用，因为它们包含需求和说明文档。测试团队可以参考这些文件来正确描述项目的范围。
关于工作性质的假设：以前的工作经验有助于建立项目假设。在这种情况下，聘请有经验的专家至关重要。测试经理可以选择这些人的大脑来产生所需的结果。
潜在危险和威胁的计算：测试团队还必须预见团队未来可能面临的潜在风险、威胁和陷阱。
确定文件是否已经基线化：测试团队还必须评估需求是否已经基线化。如果文件尚未建立基线，则确定更改频率至关重要。
必须明确定义所有职责和依赖关系 - 组织必须确定将进行估算过程的所有个人的角色和职责。
评估记录的文件和以下内容： 应写下与评估过程相关的所有信息。
在整个测试评估过程中要完成的任务 -
创建一个团队来进行估算。
将项目分解为项目阶段和组件活动。
根据先前的项目和专业知识进行估算。
优先考虑潜在危害并制定策略以最大限度地减少这些风险。
检查并记录工作的相关部分。
将工作发送给适当的利益相关者。
最流行的测试估计技术
一些最重要的测试估计方法是 -
测试点的估计
基于工作阶段的估算
利用案例点估计
我们在哪里以及如何使用这些技术？
测试点估计是一种基本且易于理解的估计方法，广泛用于软件测试行业。这种方法最显着的特点是它的迭代阶段和简单性。
基于工作阶段的估计是一种估计方法，其中对某个阶段（通常是最短和最简单的阶段）进行猜测估计，然后测试团队逐步将附加阶段添加到原始估计中以达到可接受的估计。
用例点估计方法用于使用未调整的参与者权重和未调整的用例权重来估计对用例的软件测试。
测试估计示例
让我们尝试在另一个上下文中使用上述概念。
假设我们有一个测试需求，需要测试五个测试场景。
假设测试场景1有5个测试预期结果，测试场景2有6个测试预期结果，测试场景3只有2个测试预期结果，测试场景4有9个测试预期结果，测试场景5同样有9个测试预期结果。
我们将测试场景分为三类：困难、简单和中等，具体取决于每个场景中预期结果的总数。
复杂类的预期结果会超过 7 个，而基础类的预期结果会少于 5 个，中间情况会有 4 到 7 个预期的结果。
因此，我们将测试场景 1 和 2 归类为中级，场景 5 和 6 为困难，测试场景 3 为基本。
所有这些情况现在都将受到测试点的影响。我们为复杂类使用了五个测试点，为中级类使用了三个测试点，为基本情况使用了两个测试点。
在每种测试情况下，我们将假设的测试点乘以预期结果的总数。因此，我们得出以下近似值 -
场景 1：3 个测试点 * 5 个预期测试结果 = 25 个调整后的测试点
场景2：有3个考试点。* 6 个预期测试结果 = 30 个调整后的测试点
场景3：有两个测试点。* 2 个预期测试结果 = 4 个调整后的测试点
场景 4：有五个考试点。* 9 个预期测试结果 = 45 个调整后的测试点
场景 5：有五个考试点。* 9 个预期测试结果 = 45 个调整后的测试点
因此，假设我们需要为每个修改后的测试点申请 5 人时，我们得到以下近似值。
测试场景1：25个修改测试点乘以5人时为125人时。
场景 2：30 个修改测试点乘以 5 人时等于 150 人时。
场景三：四个修改测试点*5工时等于20工时
场景4：45个调整后的测试点乘以5人时为225人时。
场景5：45个调整后的测试点乘以5人时为225人时。
因此，总估计人时为：745 人时
用例点估计方法
这里给出了用例点估计程序的详细过程 -
将通用需求分解为用例，更准确地分解为参与者
计算所有用例的用例参与者总数
根据使用参与者数量将需求分类为负面正面和例外
根据他们的类为每个用例演员分配一个未处理的演员权重
重复这个过程，直到我们收到所有演员的未经处理的演员权重
使用未调整的用例权重和未调整的参与者权重获取未处理的用例点
将未处理的用例点与预定义的常量相乘以获得真实的用例点估计
举个例子，在某个需求下，我们有5个用例，用例1，用例2，用例5。考虑用例1有6个actor，用例2有15个，用例3、4，和 5 分别有 3、4 和 5 个演员。
任何参与者总数小于 5 的用例被认为是负面的，任何参与者总数等于或大于 5 且小于或等于 10 的用例被认为是正面的，任何用例超过10名演员被认为是非凡的。
我们选择为特殊用例奖励两分，对良好用例奖励一分，对负面用例奖励一分。
根据我们的假设，我们将用例 1 和 5 分类为正面，用例 2 为特殊，用例 3 和 4 为负面。
结果，Unprocessed actor weights = Use case 1 = (actor total number) 5 * 1 (assigned point) = 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 人时。
结论
软件测试评估需要熟练专家的参与以及行业范围内最佳实践的使用，例如测试用例点和用例点技术。
在定制必要的程序时保持开放的心态也很重要。这些程序的有效应用导致整个测试过程的改进。