软件测试定义
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试对象
软件测试，就是测试软件。测试所有与交付软件相关的内容。包括代码（程序）、文档（安装文档、帮助手册、程序配套关系、软件说明书、工具说明书等）、适配工具（各种使程序运行的适配包）等。除了软件版本测试之外，不同的项目组可能还会有一些工具、脚本等的测试。在这里说明软件测试对象这一点，主要是让大家清楚软件测试不仅仅是测试版本软件测试。软件测试是测试所有从你们测试组出去的交付件。
软件测试基本流程
测试需求分析 --> 测试设计（测试方案设计、测试用例设计）--> 测试执行 --> 测试报告 --> 测试总结（经验总结、漏测分析）
1、测试分析
这里的测试分析主要是指基于需求的测试分析，分析对象是需求规格说明书。即对需求进行分解，考虑需求本身，以及需求所影响的功能模块，从而得出测试范围。测试分析需要建立在对需求本身及对应的系统架构和实现细节的充分了解上，通过对数据流、状态变化、逻辑时序、功能、性能、兼容性等方面进行分析，得出详细的测试关注点的过程。
对需求分析的基础：
（1）熟悉业务。熟悉产品的组网、业务是测试需求分析的基础。如果业务不熟悉就无法做好测试分析。
（2）对用户使用场景的了解（客户化视角）。
（3）产品功能（特性）矩阵。可以理解为交付产品的所有基础特性。只有清楚所有的特性，才能尽可能分析出新增需求对基础特性的影响。但是从个人经历过的几个产品来看，还没看到有专门去维护产品的功能矩阵。通常只有一些比较大的特性框架。
需求分析的方法：
业务流程分析：描述业务的正向流程。
业务状态分析：描述业务对象的状态转换。
测试范围分析：需求本身的功能模块，受影响的模块。
当然还有基于开发实现的测试分析。通常来说，这个都是开发给出影响分析。但是记住，开发给出的影响范围有一定的参考价值，但是测试一定不能完全依赖开发的测试分析。测试一定要从测试的角度、客户的角度给出测试的分析。
2、测试设计
测试设计，主要是指测试方案设计和测试用例设计。测试需求分析是测试方案和测试设计的基础，根据需求内容使用相应的软件测试方法、测试模板最终获取测试人员可执行的场景。
测试方案设计，通常就是测试点或者叫测试标题的集合。不同的项目组会有相应的测试方案设计模板，模板中通常会包括设计测试方案时需要考虑的测试设计维度，包括需求测试内容、需求约束条件、测试组网、性能、兼容性、安全性、可靠性、可服务性、测试经验等等内容。使用模板可以最大化的避免方案设计维度遗漏。测试方案设计完成之后需要需求相关人员（SE、开发、测试执行人员等）进行评审。并最终基线定稿。需要注意的是做测试方案设计时同时也是对需求规格说明书的一次详细评审。针对规格说明书的问题需要尽快找SE确认、澄清，并跟踪规格刷新。规格评审也是测试人员的一个责任。要记住测试设计的依据就只有规格说明书，有问题就必须让SE刷新规格。
测试用例设计，测试方案设计完成之后就可以进行测试用例设计。测试用例设计通常也有相应测试用例设计模板。模板中包含的主要要素为测试用例编号、测试用例标题、预置条件、测试步骤、测试预期结果、用例等级（level1/2/3）、是否自动化用例、测试执行人员等。确保设计出的测试用例要能够指导测试执行人员甚至不熟悉相关需求背景的人员进行测试执行。
3、测试执行
测试执行主要是指测试用例执行。过程中包括测试环境搭建、测试用例执行、修改或补充测试用例等内容。测试用例执行不能按序就班的按照测试用例逐一执行。测试执行要先了解全部测试用例。根据测试用例优先级、测试用例对测试环境依赖、测试风险等因素判断测试执行优先级。比如测试用例对测试资源的依赖。A用例需要使用测试组网A，B用例使用测试组网B，C用例使用测试组网A。如果按顺序执行可能会出现重复搭建组网A的环境，导致时间浪费，甚至可能影响测试进度。
4、测试报告
撰写测试报告的角色通常是测试经理或者版本测试负责人。测试报告是在版本测试结束，测试范围内的所有内容测试结束后输出。测试报告内容主要包括测试过程和测试质量的度量数据。包括测试执行人员、测试执行周期、测试环境和工具、测试组网、测试用例执行个数、测试发现缺陷个数和缺陷值等等。
5、测试总结
版本经验总结，版本过程中值的提倡内容以及版本测试过程中需要改进的内容。以及漏测分析等。个人理解这一块内容非常重要，但是实际上由于项目周期、个人主观能动性、测试管理等等的问题，做的并不是很好。只有不断输出测试总结，输出相关特性、工具、FAQ、测试方案等文档。不断的积累，一个产品的测试能力、测试效率和测试质量才能不断迭代改进。所有的经验不应该只存在每个人的大脑里甚至是电脑里，而是应该进行分享或者是统一管理。不然组内每个成员的离职就可能造成某种特性、工具测试能力的流失，一切从0开始。是非常可惜的。这就需要测试管理者做好组内知识体系的建设、测试经验的积累，确保技能、经验、解决问题的能力是在一个良性循环中。
白盒测试和黑盒测试
1、白盒测试
知道产品内部工作过程，可通过测试来检测产品内容动作是否按照规格说明书的规定正常运行，按照程序内部的结构测试程序，检查程序汇总额每条路径是否都能按预定要求正确工作。白盒测试主要方法有：
语句覆盖：程序中的每一条语句执行被执行一次。
分支覆盖或判断覆盖：程序中的每一个分支至少走一次，即每一条语句的真值执行一次、假值也执行一次。
条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验。
判断/条件覆盖：同时考虑条件的组合和判定结果的检验。
路径覆盖：使程序沿所有可能的路径执行。
2、黑盒测试
在测试时，把程序看做一个不能打开的盒子，在完全不考虑程序的内部结构和内部特性情况下，检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息的完整性。黑盒测试的主要方法有等价类、边界值、因果图、判定表、错误推测、正交试验设计、功能图等。
白盒测试的优势在于对程序内部实现的了解，黑盒测试的优势在于对用户场景的把握。
软件测试模型
软件测试模型则是软件测试的工作框架,用于指导软件测试过程。下面我们就介绍常用的基本测试模型。
1、传统瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落（百度百科）。
从定义和核心思想可以看出，瀑布模型是一个有序的软件开发活动。下一个环节的开展依赖于上一个环节。当前环节发现的问题如果是上一个环节造成的就刷新上一环节的工作。甚至可能需要层层向上反推。举个栗子，假如在测试阶段发现了一个规格设计的问题，需要怎么处理？就需要重新刷新规格、重新设计、编码、测试。那么如何解决这个问题？一个是测试尽可能提早的介入，一个是更适合的软件开发模型，敏捷。这是另外一个话题。本文里描述的主要还是围绕尽可能提前介入测试这一原则来说。这里不是说瀑布模型就没有价值，在某种背景下，任何新方法提出并能被广泛接受一定有其价值。存在即合理嘛。
2、V模型
V模型是瀑布模型的一个演进，或者是叫优化。V模型是一个著名的、以测试为驱动的开发模型。在V模型中明确了明确测试分层的概念，如图中给出的单元测试、集成测试、系统测试、验收测试等，分层中的测试类别的测试主体、测试依据、测试对象和测试目标有所不同。比如单元测试的测试主体主要是开发、测试依据主要是系统详细设计说明书、测试对象主要是代码中的函数、类等内容，确保其符合测试详细设计，确保代码中的函数、类是可靠、稳固的。
V模型中有一定的不足，就是它没有明确体现测试需"尽早地和不断地进行软件测试"的原则（这是找了一些资料参考的，个人理解，不一定准确）。
3、W模型
在W模型中，测试与开发同时进行，增加了在开发阶段输出交付件的同步测试。与V模型对比，W模型明确体现"尽早地和不断地进行软件测试"的原则。测试提前介入，尽早发现问题。但不足的是W模型仍然不支持迭代，仍需按照流水线进行设计、编码和测试。
W模型也是我见过最主流的一个软件开发模型。也就是在系统规格说明书基线之后。开发和测试就开始并行完成各自的工作。通常测试和开发工作环节如下
开发：系统规格评审 -> 写需求规格说明书 --> 概要设计、详细设计 -> 编码 -- > 测试（Code Revview/UT/ST/IT）--> 转测试 -->修改bug
测试: 系统规格评审 --> 测试需求分析 --> 测试需求串讲--> 测试方案设计&评审 --> 测试用例设计&评审--> [版本转测试] --> 测试执行 （包括回归测试）--> 版本发布
测试需要在版本转测试前完成测试用例基线。通过上述一个过程，可以确保规格、需求问题最大程度的提前暴露，在版本转测试前确保需求尽可能是清晰的。其实流程中还包括开工会、工作量评估等内容。
4、H模型
这个有点不太理解，抄个概念放这。方便各位自行理解。
开发与测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行。
软件测试分层
按照上述软件测试模型，产生了软件测试分层概念。下面分别介绍软件测试分层中的UT、IT、ST、BBIT、SDV、SIT、SVT的概念和区别。阅读下述内容时，最主要的还是上文中提到的几个关键内容。也就是每一个分层测试的概念、测试依据、测试对象和测试出口准则。至于测试主体，个人认为并不是那么重要。比如UT测试场景的测试主体是开发，但测试做UT也见过。根据各自产品的形态、团队的人员技能去评估。
1、UT（Unit Test，单元测试）
UT是指单元测试，测试对象是LLD文档中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。
UT的测试目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块。
从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。
单元测试比较适合开发人员做。
2、IT（Intergration Test，集成测试）
IT是指把若干个经过单元测试的单元组装到一起而进行的测试，IT测试对象主要为HLD文档，主要发现开发接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。
IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。
IT可以由开发人员做，也可以由测试人员做。不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。
说一句，个人经常容易把集成测试（IT）和系统集成测试混淆。不要被集成两个字弄混了。IT测试还是属于单元级的测试，非系统级。
3、ST（System Test，系统测试）
ST系统测试(System Test)针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。
ST测试对象为模块规格说明书，模块SRS文档给出了模块的输入输出的相应要求。
ST测试主要是验证模块内功能是否符合模块规格说明书中有关需求规定的测试方法。不考虑程序内部实现逻辑，主要采用的测试方法是黑盒测试。
通常希望在完成ST后，每个模块是牢固可用的。一般来说,ST也常被称为MST（Module ST），模块集成测试。
4、BBIT（Building Block Integrated Test，模块间接口测试）
BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。
BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。
完成BBIT测试之后哦，模块间的接口功能是正确的。
MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。
5、SDV（System Design Verify，系统设计验证）
SDV是系统设计验证，测试对象为系统规格说明书。SDV主要验证系统实现是否满足系统规格说明书中的要求。验证多个模块集成以后是否满足设计需求。完成SDV测试之后，要求系统实现完全符合系统规格说明书要求，系统功能全部实现。
6、SIT（System Intergration Test，系统集成测试 ）
SIT是系统集成测试。也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。
SIT测试主要关注系统间（为了方便理解，你可以将它理解为不同产品之间）的接口是正确的。现网运行的通常都是一个解决方案的产品，部门内的产品只是一个组成单元，如果当前开发的功能需要两个产品之间进行处理，在SIT测试时就需要重点关注。举个例子，充值产品和计费产品归属于两个部门。当充值系统中发送给计费系统的消息接口发生变化时，SIT测试就需要重点关注该接口测试。
7、SVT（System Verify Test，系统验证测试）
SVT是验收测试，其测试对象是产品包需求（也就是客户提出的最原始的需求，原始需求经过SE加工后的叫系统规格说明书）。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。产品包需求不考虑内部实现的差异，SVT也是从整个系统的角度考虑包需求的各种应用场景，属于“系统级”的测试。
各个分层的测试描述完成，结合开发测试模型可以发现：
1）基于系统架构的分解结构（系统－子系统－模块－单元），开发按照自顶向下的顺序逐层设计，测试按照自底向上的顺序逐层验证，这个分解结构在每一层或每一个阶段，将开发和测试过程统一起来。
2）在每一层，测试的对象是开发相应阶段设计的输出（包括需求和这个阶段的设计文档），测试的目的与开发相应阶段设计的思路是相辅相成的，所以决定每个阶段的测试如何开展、评价一个测试过程时，如果离开开发过程，只谈测试自身的话，是不系统、不全面的。
3）除了“系统级”的SVT测试以外，其他各层的测试均包含两个方面：一是对这个层每个构件的测试，有n个构件就要测试n次，二是这n个构件之间接口的测试。例如：nSDV（每个测试项目组的SDV是一个SDV）和SIT、nMST（每个开发项目组的MST是一个MST）和BBIT、nUT和IT。