测试流程简述
测试过程(以下左图)与测试阶段(或类型)(以下右图)
图-1
说明：
1. 以上左图描述的通用软件测试过程。右图描述的是具体的测试活动阶段，按不同的测试阶段分可分单元测试、集成测试、确认测试、系统测试、验收测试，回归测试，冒烟测试等测试类型。
2. 回归测试是指修改了旧代码后，重新进行测试以确认缺陷的修复，及修改没有引入新的错误或导致其他代码产生错误。软件开发的各个阶段都会进行多次回归测试。
3. 冒烟测试(也叫提交测试)，正式测试前对软件主业务流程和主功能进行验证与确认，确保后续测试能正常进行的测试。现状：一般是在新版本提交前，进行正式测试前的进行冒烟测试
4. 右边的每个测试活动阶段，可以按左侧的测试过程进行，文档评审，测试计划、测试设计、测试执行、测试总结等(可根据实际情况对测试过程进行适度裁剪)
5. 左边的和右边两幅图进融入软件开发过程中，就产生了以下将说到的各种测试模型
6. 阶段(类型)细分：如下图
测试过程和开发过程协作(典型模型举例说明)
W模型为例
图-2
说明：
1.其中系统设计也叫概要设计。
2.软件需求评审，主要是评审软件需求规格说明书、主要依据是产品需求文档
3.系统设计评审，主要是评审系统架构设计等，主要依据系统概要设计说明书
4.详细设计评审，主要是评审详细的设计，比如接口设计是否合理，主要依据详细设计说明书
ps:现实状况是，一般的公司，一般的项目都做不到这么规范的，有些公司甚至没有文档，目前笔者见过的比较规范的也就兴业银行的质量管理（瀑布模型对银行类项目似乎还是比较实用的）
H模型
图-3
说明：
1. V、W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V、W模型都没有很好地体现测试流程的完整性。
为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
2. H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。
3. 概括地说，H模型揭示了：
1）软件测试不仅仅指测试的执行，还包括很多其他的活动。
2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
3）软件测试要尽早准备，尽早执行。
4）软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
4. 结合软件项目开发流程，不同开发阶段，可以根据实际情况，把图-1的测试过程融合到不同开发阶段中。(可根据实际情况对测试过程进行适度裁剪)。如需求分析阶段，可以用纳入“文档评审”过程，进行业务需求文档评审和软件需求规格说明书评审，同时也纳入“测试计划“，”测试设计“对系统测试进行计划和设计。系统设计阶段，可纳入“文档评审”过程，对系统架构设计说明书，概要设计说明书进行评审
测试过程详述
测试计划
测试计划阶段主要工作包括确定测试目的，测试约束，测试需求，测试风险，测试策略，测试资源，测试量化计划，测试进度，测试计划工作量，交付物；
测试计划阶段活动包括：
1、 确定测试目的，测试约束，测试需求，测试策略等。
2、 依据历史数据、类似项目数据和估计的系统测试用例数，估计测试工作量与测试进度。
3、 根据估计出的测试工作量和项目计划，估计测试资源(人力资源及环境资源，工具)
4、 根据测试工作量、测试资源、进行风险分析与规避。
5、 编制测试计划；
6、 评审测试计划
测试设计
分析测试需求，设计测试用例，进行测试用例的评审并跟踪测试计划的执行情况。
测试设计阶段活动包括：
1、 测试相关人员参与软件需求开发过程，分析软件测试需求，参与软件需求评审，确保软件需求的可测性。
2、 编写测试需求，并设计测试用例。
3、 组织搭建测试环境，准备测试数据。
4、 评审测试用例设计。
测试执行
通过测试执行过程中的版本控制、测试环境监控、测试执行进度控制以及变更控制等手段，确保测试对象的质量。
测试执行阶段活动包括：
1、 测试相关人员进行测试脚本的编写和修改。
2、 测试相关人员建立测试执行流并进行联调。
3、 测试相关人员分配测试任务给测试执行人员。
4、 测试相关人员根据测试用例执行测试，保证测试用例的覆盖率达到测试计划要求。
5、 测试相关人员记录测试结果，跟踪缺陷的修改状况并对修改完成的缺陷进行验证。
6、 测试相关人员对测试环境进行监控，并组织进行测试过程量化数据的搜集工作。
7、 测试相关人员进行对测试执行进度进行跟踪控制
测试总结阶段
对完成的测试任务进行分析、总结，并给出测试结论或建议。
测试总结阶段活动包括：
1、 测试相关人员评估测试活动。
2、 测试相关人员分析测试结果。
3、 测试相关人员组织编写测试报告。
4、 测试相关人员进行测试报告评审。
测试阶段详述
单元测试活动
主要由开发人员对编写的代码进行自测和交叉测试，检查代码是否实现模块功能，是否符合编码规范，是否存在明显的逻辑错误。
单元测试活动包括：
1、 编写单元测试用例；
2、 执行单元测试，进行自测和交叉测试；
3、 记录单元测试结果；
4、 评估单元测试活动的有效性；
集成测试活动
将通过单元测试的模块逐步组装成具有良好一致性的完整的程序，制订集成测试实施策略，确定集成测试的实施步骤，设计集成测试用例，逐一地添加模块进行测试。
集成测试活动包括：
1、 编写集成测试计划；
2、 开发集成测试用例；
3、 执行集成测试；
4、 对缺陷修复版本进行回归测试；
5、 记录集成测试结果；
6、 进行增量集成模块测试，重复步骤(二)～(五)，直到增量集成结束；
7、 编写集成测试报告；
8、 评审集成测试报告。
确认测试活动
确认测试本身就是属于系统测试，只是有时候强调它的重要性，而单独出来。确认测试确认测试又称有效性测试，的目的是向未来的用户表明系统能够像预定要求那样工作。
软件测试的工作归结起来就是两个V，Verification和Validation。
Verification翻译为验证，在在ISO9000中，“验证”的严格定义是：验证是通过检查和提供客观证据，表明规定要求已经满足的认可。
Validation翻译为确认，在ISO9000中，“确认”的严格定义是：确认是通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。
从定义上可以看出“验证”关注是否满足规定，即需求规格说明书，“确认”关注的是是否满足预期用途，即用户的真正需求。我们知道，软件的设计，编码实现都是依据软件的需求规格说明书。对于软件测试来说单元测试，集成测试，系统测试的目的是验证软件是否符合软件的需求规格说明，因此都可归于验证过程。然而需求规格说明书并不能代表用户的真正需求，而且依据需求的设计也往往同需求会有些偏差，所以得出的软件产品在经过了系统测试以后还需要进行，确认测试。测试软件产 品是否就是用户想要的产品。
最简单的解释是：
Verification：Are we building the product right？
（功能验证）是否按需求做出了正确的产品
Validation：Are we building the right product?
（有效性确认）是否作出了用户想要的产品。
总之，验证针对的是软件规则需求说明书，检验软件是不是根据需求来设计实现的，确认针对的是用户，检验软件能否满足用户的需求。
备注：是否要采用确认测试具体要看被测系统的大小。如果被测系统是比较大型的系统，包括软件、硬件等，就需要在集成测试后进行专门针 对软件子系统的确认测试，然后再针对整个系统进行系统测试；如果整个系统就是由软件构成的，就不需要进行专门的确认测试了，在集成测试后直接进行系统测试 就可以了。
系统测试活动
验证需求规格说明书中的各个功能点是否齐全、是否正确实现，同时对系统的安装、部署、适应性、信息安全、界面等非功能性需求进行测试。
系统测试活动包括：
1、 编写系统测试计划；
2、 开发系统测试案例；
3、 执行系统测试；
4、 记录测试结果；
5、 编写系统测试报告；
6、 评审系统测试报告
用户验收测试（UAT）活动
验证需求规格说明书中的业务功能是否满足，并关注系统界面、响应时间等非功能性需求。
用户验收测试（UAT）活动包括：
1、 制定UAT测试计划；
2、 编写UAT测试用例；
3、 执行UAT测试；
4、 记录UAT测试结果；
5、 编写UAT测试报告。
6、 评审UAT测试报告。
---------------------以上无绝对描述，具体情况具体分析--------------------------
每家公司不一样，项目不一样，人力资源不一样，开发模式不一样（比如敏捷开发）,流程自然就不一样，，但是总体大致思想是一致的，可以根据实际情况进行适度裁剪，该有的还是要有的，即便是敏捷测试……以上总结，主要是帮助新手入门，让新手有个大概的印象
