软件测试技术

软件测试技术是根据业务收集的功能或非功能需求测试被测应用程序的方法。每种测试技术都有助于找到特定类型的缺陷。例如，可能发现结构缺陷的技术可能无法针对端到端业务流来发现缺陷。因此，在测试项目中应用了多种测试技术以得出可接受的质量。

测试原理

以下是软件测试的原理：

1. 所有测试应符合客户要求。
2. 为了使我们的软件测试应由第三方执行
3. 不可能进行详尽的测试。因为我们需要根据应用程序的风险评估来确定最佳的测试量。
4. 在实施之前，应计划所有要进行的测试
5. 它遵循帕累托规则(80/20规则)，该规则指出80％的错误来自程序组件的20％。
6. 从小零件开始测试，然后将其扩展到大零件。

软件测试技术的类型

软件测试技术主要分为两类：

1. 静态测试技术是用于在不进行测试的情况下查找被测应用程序中的缺陷的测试技术。 执行代码。进行静态测试是为了避免在开发周期的早期出现错误，从而降低了修复错误的成本。
2. 动态测试技术是用于测试被测应用程序(即通过执行代码库)的动态行为的测试技术。动态测试的主要目的是使用动态输入来测试应用程序-根据要求可以允许某些输入(正测试)，而不允许进行某些输入(负测试)。

每种测试技术都有其他类型，如下图所示。下面将通过示例详细说明其中的每一个。

测试技术

静态测试技术

如前所述，静态测试技术是不需要执行代码库的测试技术。静态测试技术分为两大类：

1. 评审：范围可以从两个开发人员/测试人员之间对工件(代码/测试用例/测试数据)进行的纯粹的非正式同行评审，到由组织内部/外部的主持人领导的完全正式的检查。
   1. 同行评审：非正式评审通常在没有任何正式设置的情况下进行。它是在同伴之间。例如，两个开发人员/测试人员检查彼此的工件，例如代码/测试用例。
   2. 演练：演练是工作的作者(代码或测试用例或正在审阅的文档)将其所做的工作及其背后的逻辑介绍给涉众的类别，以达成共识或达成反馈意图。
   3. 技术审查：这是一个审查会议，仅着眼于要达成共识的受审查文件的技术方面。它很少或根本没有关注基于参考文档的缺陷识别。进行审核需要建筑师/首席设计师等技术专家。它可以从非正式到正式不等。
   4. 检查：检查是最正式的审查类别。在检查之前，要检查的文件在进行检查之前已经做好了充分的准备。在检查会议中确定的缺陷将记录在缺陷管理工具中，并进行跟踪直至关闭。避免了关于缺陷的讨论，并且将单独的讨论阶段用于讨论，这使检查成为一种非常有效的审查形式。
2. 静态分析：静态分析是对需求/代码或设计的检查，目的是识别可能会或可能不会导致故障的缺陷。例如-查看以下标准的代码。不遵循标准是可能导致或可能不会导致失败的缺陷。有许多用于静态分析的工具，主要在组件或集成测试之前或期间由开发人员使用。甚至Compiler也是一个静态分析工具，因为它指出了语法的不正确使用，并且它本身也不执行代码。代码结构涉及多个方面–即数据流，控制流和数据结构。
   1. 数据流：这意味着如何在给定程序中遵循数据跟踪–根据程序中的指令如何访问和修改数据。通过数据流分析，您可以识别从未使用过的缺陷，例如变量定义。
   2. 控制流：它是程序指令如何执行(即条件，迭代或循环)的结构。控制流分析有助于识别缺陷，例如死代码，即在任何情况下都不会使用的代码。
   3. 数据结构：它是指与代码无关的数据组织。数据结构的复杂性增加了代码的复杂性。因此，它提供了有关如何在给定代码中测试控制流和数据流的信息。

动态测试技术

动态技术可分为三类：

1.基于结构的测试：

这些也称为白盒技术。基于结构的测试技术专注于代码结构的工作方式并进行相应的测试。要了解基于结构的技术，我们首先需要了解代码覆盖率的概念。

代码覆盖率通常在组件和集成测试中完成。它确定了所编写的全部代码中结构测试技术所涵盖的代码。代码覆盖率的一个缺点是-它根本不谈论尚未编写的代码(缺少需求)。市场上有一些工具可以帮助测量代码覆盖率。

有多种方法可以测试代码覆盖率：

1.语句覆盖范围：所执行代码的语句数/语句总数。例如，如果一个代码段有10行，而您设计的测试仅覆盖其中的5行，那么我们可以说该测试给出的语句覆盖率为50％。

2.决策范围：执行的决策结果数/决策总数。例如，如果一个代码段有4个决策(如果条件)并且您的测试仅执行1个，则决策覆盖率为25％

3.有条件/多条件覆盖：其目的是确定程序中每个逻辑条件的每个结果都已得到执行。

2.基于经验的技术：

这些是借助多年积累的经验来执行测试活动的技术。领域技能和背景是此类测试的主要贡献者。这些技术主要用于UAT /业务用户测试。这些是在诸如基于规范和基于结构的结构化技术之上工作的，并且对它们进行了补充。以下是基于经验的技术的类型：

1.错误猜测：由在测试中或在被测应用程序方面具有非常丰富经验的测试人员使用，因此他们可能知道系统可能存在缺陷的地方。当单独使用它时，它不是一种有效的技术，但与结构化技术一起使用时，确实很有帮助。

2.探索性测试：它是动手测试，旨在以最小的计划获得最大的执行覆盖率。测试设计和执行是并行进行的，无需记录测试设计步骤。这类测试的关键方面是测试人员对被测应用程序的优缺点的了解。与错误猜测相似，它与其他形式技术一起使用很有用。

3.基于规范的技术：

这包括功能性和非功能性技术(即质量特征)。从根本上讲，这意味着根据业务的功能或非功能规范创建和执行测试。它的重点是识别与给定规格相对应的缺陷。以下是基于规范的技术的类型：

1.等效分区：它通常一起使用，并且可以应用于任何级别的测试。这个想法是将数据的输入范围划分为有效部分和无效部分，以便将一个分区视为“等效”部分。一旦确定了分区，就只需要假设给定分区中的所有值都表现相同，就可以对给定分区中的任何值进行测试。例如，如果输入字段的值介于1-999之间，则1-999之间的值将产生相似的结果，因此我们无需对每个值进行测试即可调用测试完成。

2.边界值分析(BVA) ：此分析测试有效和无效范围的边界。在上面的示例中，0,1,999和1000是可以测试的边界。这种测试背后的原因是，通常情况下，代码中的边界没有得到很好的处理。

3.决策表：这是测试输入组合的好方法。它也称为因果表。用外行的语言，可以将适用于被测应用程序段的条件构建为表格，并针对每个条件确定结果以达成有效的测试。

1. 应该考虑的是，组合不太多，因此表太大而无法生效。
2. 以一个信用卡示例为例，如果同时满足信用评分和薪金限制，则该信用卡被发行。可以在下面的决策表中说明：

决策表

4.基于用例的测试：这项技术可帮助我们识别逐个事务地整体执行系统的测试用例，就像实际用户(演员)一样。用例是描述Actor与系统之间交互作用的一系列步骤。它们始终是用Actor的语言而不是系统的语言定义的。此测试对于识别集成缺陷最有效。用例还定义了流程的任何先决条件和后置条件。 ATM机器示例可以通过用例进行测试：

基于用例的测试

5.状态转换测试：在被测应用程序或其一部分可以被视为FSM或有限状态机的情况下使用。继续上面的简化ATM示例，我们可以说ATM流具有有限状态，因此可以使用状态转换技术进行测试。有4个基本要考虑的事项–

1. 系统可以达到的状态
2. 导致状态改变的事件
3. 从一种状态过渡到另一种状态
4. 状态改变的结果

可以创建一个状态事件对表来导出测试条件-正和负。

国家过渡