验证和确认是测试过程的一部分吗？

基于许多资​​料，我不认为测试的简单定义是找到尽可能多的错误-我们进行测试以确保其有效或无效。例如followint是测试ISTQB的目标：

1. 确定（软件产品）满足指定要求（我认为其验证）

2. 证明（软件产品）适合目的（我认为这是验证）

3. 检测缺陷

   我同意测试就是验证，确认和缺陷检测。那是对的吗？

我认为您完全正确。

1. 验证和确认是不同的东西，实际上定义得很好。尽管我不太喜欢该文档，但ISO 9000ff与质量检查高度相关，并且将“验证”定义为将产品与其要求进行比较，并将“验证”定义为检查产品是否确实满足客户/用户的需求，我们都知道这可能会有所不同。

2. 两者都可以通过测试来完成。验证将导致测试生成表格要求。验证导致测试无法直接参考要求进行测试。我认为这通常称为探索性测试。显然，必须由真正了解用户实际需求的人员来完成，因此，实际用户进行alpha和beta测试是显而易见的选择。

3. 从理论上讲，我猜一个人可能会争辩到前两个涵盖的内容都不是错误，因此将错误作为单独的目标来查找是没有意义的。但我认为有些事情您无法真正验证或确认。例如安全性：如何验证或验证软件系统对攻击没有危害？相反，您尝试查找漏洞。如果未能找到问题，此搜索不会验证或验证任何内容，但如果成功，它将发现错误。

摘自Wikipedia：“ ...换句话说，验证可确保产品确实满足用户的需求，并且首先确保规格正确，而验证可确保根据要求和设计规格制造产品。 。验证确保“您建造了正确的东西”。验证确保“您建造了正确的东西”。验证确认所提供的产品将满足其预期用途。

您无法测试用户的需求，无法通过代码检查规格是否正确。因此，验证不是通过测试来完成的。

验证假设您的要求和设计正确，因此您可以通过编写代码（测试）进行测试。

在现实世界中，测试是对符合软件要求（业务/功能/非功能）的软件进行验证和确认。这些目的是确定软件是否适合目标用途。任何不符合应用程序要求的行为都是缺陷-在确定软件是否适合目的之前，必须权衡其严重性。

低严重度缺陷可能不会阻止将软件传递到生产类型使用；高严重度缺陷可能需要产生修复程序。在现实世界中，所有软件都存在缺陷，有些是编码问题，而另一些则是由于缺少需求-可能无法测试，因为您无法测试未知需求。

验证和确认的定义很多。许多人甚至使用V＆V标签将两个活动分组。目的是确保软件能够正确地解决问题。在这个级别上，是否要检查是否符合要求或尝试查找错误都不是必需的。

测试是多种验证和确认技术中的一种，而不是另一种方法。代码审查是另一种形式，而形式验证则是带有数学证明的另一种形式。

尽管如此，执行测试的目的应该是发现错误，而不是检查是否符合要求。

主要区别在于测试人员的想法。建立一个表明软件能够按预期工作（检查合规性）的测试用例要比建立一个表明软件失败（发现错误）的测试用例要容易得多。

优秀的测试人员热衷于破坏软件，而不是希望以安全的方式执行软件。

让我们从实际的角度来看。对于测试，您需要定义测试用例。通常，您要根据指定的需求定义测试用例，并且这些测试用例应涵盖“欢乐时光”用例以及“边缘用例”-尤其是后者，其定义通常旨在破坏软件。当您的某些测试失败时，它们会显示错误/缺陷。如果您对每个需求都有合理数量的测试用例，并且所有测试都通过了，则您可能还没有完全证明所有需求都得到满足，但是您提高了实现的可能性，因此进行了一些验证。

因此对于问题的那一部分，发现错误和验证可能只是同一过程的两个方面：

• 测试失败：发现缺陷

• 测试通过：已完成验证（至少在某种程度上，如果您提供了足够且正确的测试）

关于验证：正如@Mert所指出的，验证可以通过验收测试来完成，而不能通过其他形式的测试来完成。因此，测试通常不会引起某些潜在用户的验证，只有当做验收测试时才进行验证。

这完全取决于您对“验证”的定义。例如，正式的验证通常不是质量检查团队完成的工作，而是开发人员的责任。由于与之相关的高昂成本（知识差距和所需资源），几乎没有人进行正式验证。

软件测试与质量检查不同。你说对了。整个软件测试本身包括许多阶段（烟熏，单元，回归，集成，用户接受等）。

因此，确保软件能够按照要求工作是QA的目标（质量保证专家，又名几年前简称为测试人员）。但是，这不仅仅是测试。质量检查确保适当的过程集可以执行相关产品的质量检查，或者至少已进入项目的设计阶段。

因此，理想情况下，您希望QA能够根据一组要求验证应用程序，而不仅仅是尝试通过破坏软件和发现缺陷来对其进行测试。