质量保证QA关注在软件产品生成的整个过程，主要验证软件产品开发过程中相关实施过程的完整性、一致性和有效性，确保开发活动和测试活动等遵循正确的过程，为软件产品达到合适的质量级别提供信心。为了实现过程的可重用性和持续改进，组织往往会把过程进行标准化，例如：定义子过程、过程的里程碑点、过程的阶段输入和输出、每个时间点需要完成的工作等。软件产品随着生命周期不断增加和成型，想要修复其在早期引入的缺陷，时间和成本都将成倍增加。而质量保证QA的基本假设是过程质量决定了软件产品质量。当过程正确开展时，确保过程的每个阶段得到了良好的遵循，每个阶段引入的缺陷尽量在本阶段得到发现和修复，最大程度的实现缺陷的阶段遏制能力。同时，在当前阶段发现和修复的缺陷，有助于后续阶段的缺陷预防。另外，通过根本原因分析等技术消除在软件工作产品中引入缺陷的根本原因，或者在适当时候开展回顾会议以总结经验和教训，都有助于过程改进，从而可以在将来更好的实现质量保证。
对于软件开发项目而言，控制是十分重要的管理活动。软件质量保证(Software Quality Insurance，SQA)是在软件过程中的每一步都进行的“保护性活动”。SQA主要由基于非执行的测试(也称为评审)、基于执行的测试(即通常所说的测试)和程序正确性证明。软件评审是最为重要的SQA活动之一。它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。审查过程不仅步数比走审多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。
软件质量保证渗透到需求、设计、编码、发布、维护、配置管理、文档的各个环节，每一个环节工作做到位，都会减少软件质量风险。
如果公司比较大，那么QA是一个专门的岗位，是区别于测试的，测试的重点是在找软件BUG，而QA的重点是发现过程中的质量问题，寻求改进方法和优化流程，避免以后犯同类错误。好的QA一定是一个资深的设计高手，否则只能做到文档稽核、走走流程、意义不大。
软件质量保证技术,主要包括两类方法:一是事后控制,以调试、测试、技术复审等以不出质量缺陷为目的技术方法,其主要形式是找出缺陷所在;一种是事前控制,主要形似是以预防为主,通过标准化、过程管理等如CMM,ISO以控制质量缺陷为目的的管理方法。以技术方法解决问题有一定的局限性,而标准化的指定只能告诉做什么,而不是告诉怎么做,而相对于“事后活动”,质量保证中更重要的是“事先预防”。因此,软件的质量保证也应该构筑以用户满意为中心,能防患于未然的质量保证体系。 尽管软件质量越来越受重视,也出现了不少旨在保证质量、指导软件开发的标准和过程模型(如瀑布模型、RUP模型、CMM等),但这些标准、方法在软件质量保证上只提供了原则性的指导,人们在展开软件开发时普遍感到缺乏得心应手的工具。因此,顺沿着软件工程提出的思路和SCOR模型给我们的启示,我们借用在生产质量领域中成熟的质量控制保证技术和管理观念如QFD、FMEA等方法应用到软件产品中去。
软件质量保证(SQA)是一种应用于整个软件过程的活动，SQA小组的职责是辅助软件团队实现高质量的软件产品。其活动内容包括以下几个方面。
①为项目准备SQA计划。
②参与开发项目的软件过程描述，而非负责开发项目的软件过程描述。
③评审各项软件工程活动，以验证其是否符合定义的软件过程。
④审核指定的软件工作产品，以验证是否符合定义的软件过程中的相应部分。
⑤确保软件工作及工作产品中出现的偏差已文档化，并且按照文档化的规程进行了处理。
⑥记录所有不符合规范的部分，并报告给高层管理者。
⑦协调变更控制和变更管理，并帮助收集和分析软件度量信息。
软件质量不是SQA完全负责，软件开发中有许多参与者负有保证软件质量的责任，包括软件工程师、项目管理者、客户、销售人员和SQA的成员。SQA小组充当客户在公司内部的代表，必须以客户的观点来看待软件。SQA小组的职责是辅助软件工程小组得到高质量的最终产品，为此制定了一组有关质量保证中的计划、监督、记录、分析及报告的SQA活动，这些活动由一个独立的SQA小组执行(或推动)。软件工程师采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，这不是SQA的工作。
软件测试与软件质量（QA）的区别
质量保证（QA）：主要工作是通过预防，检查与改进来保证软件质量。它所关注的是软件质量的检查与测量。着眼软件开发活动中的过程、步骤及产物，而不是对软件进行剖析进而找出问题。
软件测试：测试关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物——开发文档和源代码进行走查，运行，以找出问题，报告质量。测试人员也必须假设软件存在问题，所以所做的操作都是为了找出更多的问题，而不仅仅验证每一件事是正确的。
通过质量控制和质量保证活动，发现质量工作中的薄弱环节和存在问题，再采取针对性的质量改进措施，进入新一轮的质量管理PDCA循环，以不断获得质量管理的成效。
软件测试模型是什么？
0)瀑布模型
What is the Waterfall Model?
Waterfall model is a sequential model divided into different phases of software development activity. Each stage is designed for performing the specific activity during the SDLC phase. Testing phase in waterfall model starts only after implementation of the system is done.
Testing is done within the SDLC.
1) V模型
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段 ；
忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。（缺陷）
What is V- Model?
V- model is an extension of the waterfall model. It is pronounced as the "vee" model. Unlike the waterfall model, In V-model, there is a corresponding testing phase for each software development phase. Testing in V-model is done in parallel to SDLC stage.
Testing is done as a subproject of SDLC.
2) W模型
测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。（缺陷）
测试的活动与软件开发同步进行；测试的对象不仅仅是程序，还包括需求和设计； 尽早发现软件缺陷可降低软件开发的成本。（优点）
Paul Herzlich introduced the W-Model. In W Model, those testing activities are covered which are skipped in V Model.
The ‘W’ model illustrates that the Testing starts from day one of the of the project initiation.
If you see the below picture, 1st “V” shows all the phases of SDLC and 2nd “V” validates the each phase. In 1st “V”, every activity is shadowed by a test activity. The purpose of the test activity specifically is to determine whether the objectives of that activity have been met and the deliverable meets its requirements. W-Model presents a standard development life-cycle with every development stage mirrored by a test activity. On the left hand side, typically, the deliverable of a development activity (for example, write requirements) is accompanied by a test activity test the requirements and so on.
Conclusion– V model only shows dynamic test cycles, but W models gives a broader view of testing. the connection between the various test stages and the basis for the test is clear with W Model (which is not clear in V model).
3) X模型
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执 行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但 这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
4) H模型
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。
H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展
H模型示意图
H模型的优点：
>开发的H模型揭示了软件测试除测试执行外，还有很多工作；
>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
H模型的缺点：
>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
软件质量保证过程通过计划制订、实施和完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符合其规定的需求。 软件质量保证计划定义了用于保证为特定产品开发的软件满足用户需求并在项目的约束内具有最高的质量的手段。
验证与确认过程使用能够定位缺陷并便于以后改正的测试技术直接处理软件产品质量问题。 验证与确认过程确定某一开发和维护括动的产品是否符合活动的需求，尾终的软件产品是否达到其意图并满足用户需求。验证过程试图确保活动的输出产品已经被正确制造，即活动的输出产品满足前面活动施加的规范说明；确认过程则试图确保建造了正确的产品，即产品满足其特定的目的。
评审与审计过程包括：管理评审、技术评审、检查、走查、审计等。管理评审的目的是监控进展，决定计划和进度的状态，确认需求及其系统分配，或评价用于达到目标适应性的管理方法的有效性。它们支持有关软件项目期间需求的变更和其他变更活动。
技术评审的目的是评价软件产品。以确定其对使用意图的适合性，目标是识别规范说明和标准的差异，并向管理提供证据，以表明产品是否满足规范说明并遵从标准，而且可以控制变更。检查的目的是检测和识别软件产品异常。一次检查通常针对产品的一个相对小的部分。发现的任何异常都要记录到文档中，并提交。软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动，识别违例情况，并产生一个报告，采取更正性行动。
相关资料：
郑文强Tester：质量保证QA与质量控制QCzhuanlan.zhihu.com
