模块测试：目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现模块内部可能存在的各种错误。
需要从程序内部结构出发设计测试用例，多个模块可平行进性。
集成测试：在单元测试的基础上，将所有的程序模块进性有序的、递增的测试。
组装测试，集成测试是验证程序单元或组建的接口关系，逐步即成为符合概要设计要求的程序部件或整个系统。
冒烟测试：也称版本测试、提交测试。
确认测试：通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。
检测与证实软件是否满足软件需求说明书中规定的要求。
系统测试：验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进性的测试。是在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台）正确配置、连接，并满足用户需求。
验收测试：按照项目任务书和合同、供需双方约定的验收依据文档进性的对整个系统的测试和评审，决定是否接受或拒收系统。
开发方测试 验收测试 α测试
开发方通过检验和提供客观证据，证实软件的实现是满足了规定的需求。是在开发环境下，由开发者检测与证实软件的实现是否满足设计说明或软件需求说明的要求。
主要是在软件开发完成之后，开发方进性全面的自我检查和验证。
可以和系统测试一起进行。
用户测试：在用户环境下，用户通过运行和使用软件，检查与合适软件实现是否符合自己的预期的要求。
通常情况下不是指用户的“验收测试”，而是指用户的使用性测试。
由用户找出软件的应用过程中发现软件的缺陷与问题，并对使用质量进性评价。
β测试：主要是把软件产品有计划地免费分到目标市场，让用户大量使用并评价、检查软件。
通过用户各种方式大量使用，来发现软件存在的问题和错误，把信息反馈给开发者修改。有助于厂商软件产品的成功发布。
第三方测试：由技术、管理和财务上与开发方和用户相对独立的组织的进行的测试。
一般情况是在模拟用户真实环境下，进行软件测试。
价值：公正诉求决定、发现错误，提高软件品质、给出评价，有助于开发商认清自己产品的定位、帮助用户选择软件产品，避免豆腐渣工程。
静态测试：指不允许程序，通过人工对程序和文档进行分析与检查。
静态分析技术是对需求说明书、设计说明书、程序源代码等进行非运行的检查。
静态测试包括：走查、符合执行、需求确认。
动态测试：通过对人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
白盒测试：结构测试 对程序内部结构的分析、检测来寻找问题。
黑盒测试：功能测试 通过软件外部表现来发现其缺陷和错误。
灰盒测试：介于白盒测试与黑盒测试之间的测试。
V模型
特点：底层测试 源代码的正确性； 高层测试 整个系统满足用户的需求。
单元测试和集成测试是验证的程序设计。
系统测试是验证系统设计，检测系统功能，性能的质量特性是否达到系统设计的标准。
确认和验证测试：追溯软件需求说明书进行测试，已确定软件的实现是否满足用户需求或合同的要求。
局限性：仅把测试过程作为需求分析、概要分析、详细设计及编码之后的一个阶段；容易理解为，测试是软件开发的最后一个阶段，主要针对程序进行测试寻找错误；需求分析阶段隐藏的问题一致到后期的验收才被发现。
W模型
有利于尽早地发现问题
相应的开发活动完成即可开始执行测试
减少总体测试世纪，加快项目进度。
可以尽早可能的找出软件缺陷所在，帮助改进项目内部质量。
局限性：无法支持迭代、自发性以及变更调整；如果当前没有文档就会出现问题；无法测试流程的完整性。
H模型
特点：软件测试模型是一个独立的模型，贯穿于整个产品周期，与其他流程并发的进行，当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
X模型
定位了探索性测试
左边描述的时针对单独程序片段所进行的相互分离的编码和测试，以后，将进行频繁的交接，通过集成最终合成为执行的程序。
可执行程序还需要进行测试，可通过集成测试的成品进行封装并提交给用户，也可以更大模型和规范内集成的一部分。
前置测试模型：
开发和测试相结合：对没有给交付内容进行测试；在设计阶段测试和测试设计；测试和开发在一起；让验收测试和技术测试保持相对独立。
软件是生命周期的软件测试策略
软件计划阶段：作用域
单元测试——集成测试《设计信息》——确认测试《软件需求》——系统测试《系统其他元素》
测试信息流
三类输入
软件配置：需求规格说明；设计规格说明；源代码
测试配置：测试计划；测试用例；测试驱动程序【测试配置在整个软件配置的一个子集】
测试工具：为测试某种实施提供服务，以减轻测试任务中的手工劳作。提高软件测试效率。
测试——测试结果【预期结果与实际结果对比】——排错【最不可预知的，花费时间解决问题】——回归测试——测试
测试——测试结果分析——测试报告【出错覆盖率】可靠性分析，预测可靠性。
