QA，QC，软件测试，验证，确认，预防和检测之间的差异

#1 楼

为了进一步阐明User246的观点，我将在此处添加一些我发现在大多数组织中都是正确的一般要点。

质量保证

质量保证是质量保证过程。如果从项目的一开始就将其包括在内，则只有在最真实的意义上才能进行此过程。最真实的形式是与所有项目成员有关的过程。可以通过常见的“方法烘焙质量”来理想化。尽管许多公司将其视为测试过程，但如果要正确实施，则应由高级开发人员，高级测试员或在理想的环境中由质量保证团队负责，其职责不包括仅测试人员。有关质量保证过程的更多信息，我建议阅读Gerald Weinberg的一些著作，特别是为什么软件会遇到麻烦。项目的开始，但是以后再开始也可以。这是检查和检测的过程（即：需求审查，代码审查，软件测试）。与质量保证相比，此过程更适合传统软件测试人员。

软件测试

传统上，测试被认为是质量控制过程的子集，尽管许多组织和管理人员都将测试视为质量保证。软件测试是用于检测和识别软件中的故障和失败的过程。但是，随着越来越多的公司转向非传统形式的软件开发，软件测试过程似乎正在转变为一种更加上下文相关的模型，其中出现了诸如“我们的客户将理解如何使用它”之类的问题（非常高级，我知道）。可以在网上找到关于什么是软件测试以及什么不是软件测试的参考。我不会提供参考，因为我不确定您遵循哪种特定的软件测试过程。比彼得·K我可能要澄清的唯一方法是举两个例子。要获得更深入的答案，您可能需要在英语StackExchange网站上提出以下子问题：

我*数据。

我验证了数据。 （数据在那里）

我验证了数据。 （数据在上下文中是正确的）

预防

预防是防止错误或故障进入系统的行为。从传统意义上讲，这不是测试活动，因为它必须在开发软件时完成。这将包括确保要求正确并且编写软件以正确满足要求。就个人而言，作为一名测试人员，我花了很多时间与我们的业务分析师和开发人员一起处理我们不希望发生的事情。这种工作可以被认为是测试人员可以做的预防工作。

检测

检测与质量控制齐头并进。这是将故障和故障输入系统后对其进行检测的过程。在传统的软件测试过程中，这将是软件测试的传统行为（功能测试，自动测试，UAT等）。但是，可以在项目的需求阶段进行检测，然后也可以将其视为预防的一部分。

希望这会有所帮助。

#2 楼

对于您的某些术语，CMMI具有特定含义：

验证解决了以下问题：-我们是否正确构建产品？此过程将查看规范，标准和准则，以确保已正确应用它们。例如，如果同意（通常在质量计划中记录）标准IEEE xyz用于技术规范，则进行检查以验证给定标准确实已用于技术规范。
验证解决了以下问题：-我们是否在制造正确的产品？在SDLC期间可以随时问这个问题，但是问题的实质是，当该软件产品放置在适当的环境中时，它是否能够满足最终用户的目标和需求，如需求所示。 >

#3 楼

我假设您看到或听到了未定义使用的这些术语。这些术语的定义因行业，组织和个人而异。我可以给我我的定义，但是由于它们与别人的定义不一样，所以我会浪费您的时间。 Google搜索会显示一个人的定义。也许您可以阅读这些内容，然后，当它们看起来与您看到或听到的内容冲突时，您可以陈述这些定义，并询问说话者/作者是否具有相同的含义。

#4 楼

其中一些术语来自“质量”社区，并已被IT社区重用。
通过“质量”社区，我的意思是质量有素的人关心他们所处的部门（可能是制造，化学等）。 ）。
情况就是这样的：


质量保证
质量控制
验证
验证

在标准ISO 900x中，更具体地说在ISO 9000中，我们找到以下定义：

3.2.8质量管理
协调活动以指导和控制组织（3.3.1）关于质量
注意关于质量的方向和控制通常包括制定质量政策（3.2.4）和质量目标（3.2.5），质量计划（3.2.9），质量控制（3.2.10） ），质量保证（3.2.11）和质量改进（3.2.12）。

3.2.9质量计划
质量管理（3.2.8）的一部分集中于设定质量目标（3.2.5）和指定必要的操作流程（3.4.1）和相关资源实现质量目标

§3.2.11质量控制
质量管理（3.2.8）的一部分，重点是满足质量要求（3.1.2）

§3.2.11质量保证
质量管理（3.2.8）的一部分集中在提供对将满足质量要求（3.1.2）的信心上。完整含义：想法是给一定的保证=一定的信心。
这转化为收集实际活动的痕迹，例如书面测试报告或测试自动化的痕迹。您不会相信一个人会说：“我刚刚测试过，一切都很好”（那就是没有质量保证的质量控制）。

§3.8.1客观证据
数据支持某物的存在或真实性
注意可以通过观察，测量，测试（3.8.3）或其他方式获得客观证据。

§3.8.3测试
根据程序（3.4.5）确定一个或多个特征（3.5.1）

§3.8.4验证
通过提供客观证据（3.8.1），表明已通过提供客观证据（3.8.1）满足了特定要求（3.1.2）
§3.8.5确认
确认。 ），已满足特定预期用途或应用程序的要求（3.1.2）
这是验证之外的一步：好的，您满足要求，但是如果忘记了要求以正确转换需求又该怎么办？ />验证不一定总是可行的，因为某些原因，客户可能不想透露其预期用途。

您可以看到Validation and Verification与CMMI中的定义几乎相同。
我认为尊重这些定义还有附加值，尤其是当涉及合同纠纷时客户/提供者之间。

关于预防：
您可以阅读有关“质量”历史的完整书籍。
总之：
最初，质量仅限于检查质量生产线的末端。这是纯粹的质量控制/质量保证。
这会带来非质量成本：返工，刮削和其他一些变化。
因此，质量从关注焦点到控制最终产品，再到关注质量，都发生了革命。生产过程中为了避免不合格。因此，引入了质量管理（由ISO 9001版本2001引入）。

我仍然在思考软件的正确性：可以在“软件”领域中完成，并避免在这些验证/验证阶段花太多钱（但有一些进展）
希望西南软件有同样的革命是无意义的。 SW中的脑部工具过多。质量主题在“生产领域”和“软件/项目领域”本质上是不同的

回到预防：它与质量计划有关，并且所说的建立质量过程的必要性允许实现质量目标。我们可以这样做吗：是的，当我们包括测试阶段时，当我们监视通过的测试百分比时，等等……；但这远非避免非质量的过程。它是软件工程无法建立“ 0缺陷sw工厂”（这是上面选项1的梦想）的一种管理后备解决方案。

关于检测：通常被认为是显而易见的可检测性。
并非如此。
检测可能是测试团队的事，但可检测性对于开发团队以及体系结构（例如，出于纯粹的测试目的而公开一些接口）都是问题。 >

#5 楼

从历史上讲，质量控制是1970年代的术语，其含义是控制最终产品的质量。在1980年代，当人们意识到他们也应该控制中间产品的质量时，该术语有了新的含义。

十年后，出现了软件质量保证，这不仅是对产品质量的关注，而且还对软件工程过程的监视的关注（普遍的ISO 9000证书只涉及过程质量，而不是最终产品） 。软件质量保证背后的想法是，如果您提供高质量的软件开发，您将获得高质量的产品。 （在这种情况下，Prince2是一种有趣的方法：一方面，它强调了对产品的关注，另一方面，它提供了详细描述的过程，这些都是获得高质量最终产品的手段。）

最近，出现了另一个概念，称为全面质量管理，该概念强调持续改进产品和过程的质量。

#6 楼

在受监管的环境（例如FDA）中，您可以验证需求，但可以验证用户需求。该过程从用户需求开始，从用户需求中得出需求，从需求中实现哪些功能，对这些功能进行测试以验证是否满足要求，然后最后进行测试以验证用户需求已得到实现。

#7 楼

质量保证-确保要求满足开发的产品。

QC-为评估已开发产品而开发的活动集

测试-这是评估已开发产品并发现错误的过程。

验证-检查开发中的产品（不是最终产品）是否符合要求的过程，验证从开发中开始

验证-检查开发的产品是否合格（最终产品）满足所有要求

检测-在已开发系统中查找错误。