本文包括软件测试模型、测试技术和测试管理。

一、测试基础

1、软件测试模型

所谓测试模型（Test Model），是测试和测试对象的基本特征、基本关系的抽象。

1）V模型

V模型实际是软件开发瀑布模型的变种，它反映了测试活动与分析、设计的关系。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别。
在这里插入图片描述

如图所示，左边为开发过程各阶段，右边为对应的测试阶段。V模型，优点是在开发阶段，测试工程师就可以介入，准备相应的测试工作，比如审查需求分析、编写测试计划等；缺点是仍然要在开发完成后才进入测试阶段，导致问题一直拖到后期才被发现。

V模型失败的原因是把系统开发过程划分为具有固定边界的不同阶段，导致测试人员很难及时采集测试所需信息，以及综合不同阶段信息加以总体考虑。

2）W模型

W模型是为了解决V模型的缺陷而演化出来的模型。解决V模型在软件开发编码完成后才介入测试工作，导致一些在需求和设计中的问题在后期验收测试中才被发现，不能体现“尽早地和不断地进行软件测试”的基本原则的问题。

W模型认为，测试工作应对应软件各开发阶段同步进行，由两个V字型模型组成，分别代表测试与开发过程，即一个测试V，一个开发V。
在这里插入图片描述
W模型强调测试阶段和开发阶段是同步进行的，而且测试的对象不仅仅是程序，还包括需求分析、概要设计和详细设计，测试伴随着整个软件开发周期。W模型有利于尽早地全面发现问题，减少总体测试时间，加快项目进度。

W模型的局限性，是与V模型一样，将软件的开发视为需求、设计、编码等一系列串行的活动，测试和开发仍然保持一种线性的前后关系，严格遵守先后顺序，无法支持迭代的开发模型，未能应付复杂多变的情况。对于开发过程中，需要事后补充文档，或者根本没有文档的情况，W模型中的开发和测试人员面临同样的困扰。

3）H模型

V模型和W模型都存在一定的局限性，它们都把软件的开发过程视为需求、设计、编码等一系列串行的活动，但实际上这些活动之间存在相互牵制的关系，并且大部分时间内都可以交叉进行。严格的阶段划分只是一种理想的状态。事实上，软件项目不可能等需求非常明确才开始进行，一般最初需求评审通过后，开发工作随即进行，边做边改。相应地，测试也不存在严格的次序关系，还会有反复触发、迭代和增量的关系。这一点，V模型和W模型都没有很好地体现出来。

倚天不出，谁与争锋？有专家提出了H模型。H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
在这里插入图片描述
H模型揭示了软件测试模型是一个独立的流程，贯穿于整个软件产品的周期，与其他流程并发地进行。优点是将测试从开发中独立出来，有利于研究更新的测试技术，可同时对多个项目进行测试，与项目的耦合程度较低，独立性强；但也因此对系统认识不够深入，影响测试质量和效率。

4）X模型

X模型诟病V模型无法引导项目的全部过程，认为一个模型不应该与实际脱节，是对V模型的纠正和改进。X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成可执行的程序。
在这里插入图片描述
左边：针对单独程序片段进行相互分离的编码和测试，然后频繁交接，最终集成为可执行程序，之后又是一轮测试（系统测试？），通过后封装，提交给用户，或者作为更大规模和范围内集成的一部分。多根曲线表示变更可以在各个部分发生。

优点，强调单元测试及集成测试，测试更贴近实际，修复缺陷不受项目组人员限制（就是有一定的独立性？）；
缺点，测试不够全面，没有需求测试、验收测试。

5）前置测试模型

将测试和开发紧密结合，提供一种轻松的方式，可以使项目加快速度。
在这里插入图片描述
前置测试将测试执行和开发结合在一起，并在开发阶段以”编码-测试-编码-测试“的方式来体现。当程序片段一旦编写完成，就会立即进行测试。一般是单元测试，也有可能是集成测试或其他测试。这是发现错误最经济的方式。

前置测试将测试分为技术测试和验收测试两个独立的进程。技术测试针对代码的正确性，验收测试验证需求的满足性，另外还可能包括负载测试、安全性测试、可用性测试等。

6）各测试模型比较

这是我根据个人理解的总结，可能有误。

V模型、W模型、H模型、X模型、前置模型，都以V模型作为参照，作出各自的改进。V模型在测试种的地位，就相当于开发模型中的瀑布模型，绕不过去，是基础。

V模型的特点，是开发在先，测试在后，阶段分明，缺点显而易见，开发与测试脱节；
W模型，是开发一段，测试一段，如影随形。但仍然是阶段分明。
H模型，将测试完全独立出来，按照自己的节奏，想测就测，但测试跟系统关系不够密切，有点貌合神离的味道。
X模型，针对开发阶段进一步划分，划分成一个个片段，加大测试的频率，最后再集成测试、封装成完整系统进行交付。貌似太琐碎了，并且只侧重测试开发，对需求分析、系统验收的测试不够，缺乏总体性。真是明察秋毫，不见舆薪。
前置模型，将测试分为技术测试和验收测试，各自独立，完美。

2、软件测试类型

1）分类

1、按开发阶段：单元测试、集成测试、系统测试、验收测试
2、按测试实施组织：α测试（开发方）、β测试（用户方）、第三方测试
3、按测试执行方式：静态测试、动态测试
4、按是否查看代码（或测试技术）：黑盒测试、白盒测试、灰盒测试
5、按是否手工执行划分：手工测试、自动化测试
6、按测试对象划分：性能测试、安全测试、兼容性测试、文档测试、易用性测试（用户体验测试）、业务测试、界面测试、安装测试
或进一步细分，其中质量属性测试有：容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、可移植性测试、易用性测试。
7、按测试地域划分：本地化测试、国际化测试

负载测试压力测试强度测试稳定性测试

2）名词解释

（1）集成测试
又称为组装测试、联合测试、子系统测试或部件测试。

分为
非增值式：先分别测试每个模块，然后结合在一起测试；
增值式：又称为渐增式组装，首先一个个模块测试，然后逐步组装，边组装边测试

非增值式简单，资源利用率高，缺点是成本高，难以定位错误；增值式能较早发现和定位问题，缺点是测试周期长，资源利用不够充分。

（2）系统测试
对已集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要素。

（3）验收测试
完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。

【验收测试标准】
完全执行了验收测试计划中的每个测试用例
在验收测试中发现的错误已经得到修改并且通过了测试
完成软件验收测试报告

【注意事项】
必须编写正式的、单独的验收测试计划
验收测试必须在实际的用户运行环境中运行
由用户和测试部门共同执行比较好。如果是公司自我开发产品，由测试部门联合多个部门共同进行。

（4）灰盒测试
介乎于白盒测试和黑盒测试之间。既关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征、事件、标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序，并采集程序路径执行信息，和外部用户接口结果的测试技术。

黑盒测试只需关心整个软件系统的边界，灰盒测试需要关心模块之间的交互，白盒测试需要了解模块内部的实现细节。