前言：测试的过程并不是固定的，要灵活的变化
其实测试的过程并不是固定的，它只是一种规范，也可以把它当作一种指导。但是真实的产品测试和项目测试中，一定是要灵活运用的，甚至是在不断的根据实际情况变化。我在其他平台、app上讨论软件测试时，经常提到：项目测试和 产品测试一定是不一样的。
产品测试一定有非常完整的发版计划，有充足的的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版计划，也可以进行延期。所以产品测试都会尽量的去进行完成的全级别测试。
项目测试一般时间都非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩。到目前为止我经历过大大小小几十个项目，没有一个是能按计划时间充足的上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲，牺牲掉一些不重要的功能，来优先保证 重点功能、常用功能。
一、文档评审
首先是需求文档
在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档，编写完成后，要进行需求文档评审；说是评审，实际上主要是需求讲解。给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。从这个环节开始，测试人员就应该介入进来。
因为需求文档是测试人员测试的唯一标准！
将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！所以，严格来说，测试人员在测试时只认文档不认人。可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。
测试人员参加需求文档的评审的必要性：
1.测试人员也需要了解和学习相关的业务知识。
2.测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。
3.测试人员可以凭借经验对需求文档中的部分设计提出不同的意见。
4.测试人员可以凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。
然后是开发文档
需求文档定型之后，开发经理会根据需求文档来编写开发文档。
开发文档的内容大概包括：开发模型、代码架构、代码规范、接口规范、数据库设计…
为什么测试要参加开发文档的评审？其实主要是去听测试人员需要了解系统的基本架构和实现原理，方便分析问题原因：
· 测试人员需要了解数据库表结构，对后续的测试很有必要。
· 测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素）。
· 测试人员可以发现代码中缺少对某些异常场景的逻辑判断。
最后是测试计划
测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。
测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、测试资源的成本（人/天）等等。
测试计划是测试人员的工作守则和规范。
但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。
所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。
最终的测试过程和测试结果还是以 测试报告 为准。
二、单元测试（又称组件测试 component testing）
单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试。组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：
1.降低风险
2.验证组件的功能和 非功能行为是否符合设计和规定
3.建立对组件质量的信心
4.发现组件中的缺陷
5.防止缺陷遗漏到更高的测试级别
简单的举个例子，现在开发做了一个新增的方法。
单元测试就是要写一个测试类或测试方法，调用开发的新增方法（新增肯定还要传值），并且在调用过程中模拟一些异常情况或者传输错误的值。所以单元测试一般由开发人员来完成，测试人员也可以去做，但是首先测试人员需要有一定的编码能力并搭建开发环境，其次测试人员需要去理解和分析开发的相关代码，甚至是要了解和学习相关架构。
现在成熟的开发框架已经自带的很多测试的组件和工具，以Springboot为例，可以直接导入测试依赖包。
使用idea自动创建测试类,也可以自己手动创建：
写测试类
综上所述，由开发人员来进行单元测试，要更加便捷和高效，更节约成本，几乎是举手之劳。而且能培养开发自测的良好习惯，关注代码质量的重要性。
三、敏捷测试(Agile testing)（可选）
在开发人员进行开发的这个阶段，测试人员无法对产品直接进行测试，工作任务较轻可以安排测试人员进行测试用例的编写。
对于一些紧急的项目，可以引进敏捷测试。敏捷测试是最近几年比较流行的测试方法，也拥有了众多的拥护者。还引出了一个测试思想——测试驱动开发（TDD ）这个概念有时间我单拎出来写。
敏捷测试的最大特点是高频率的快速迭代，几乎是一天一个迭代版本，甚至是一天多个版本。
敏捷测试是遵循敏捷宣言的一种测试实践：
1.强调从客户的角度，即从使用系统的用户角度，来测试系统。
2.重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3.建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
这种高频率的迭代测试，可以极大地提升产品成型的速度，bug能在最短时间内被处理。
这种测试非常考验测试人员的抗压、责任心、领导力和沟通协调能力。
但是敏捷测试也有很多的缺点，在这里我只谈自己的感受，如果有不对的地方可以留言和我讨论：
测试人员工作压力大，休息时间少，几乎没有喘息的时间。
不同版本的bug管理比较混乱，验证起来需要梳理清楚，最好是借助专业的管理工具。
bug反复性高，可能在短时间内甚至不会出现bug逐步下降的正常趋势，而是产生较大的波动。
开发无法按照bug等级来确定工作优先级，因为可能在改一个中等bug，突然来了严重bug，也得等上一个bug改完的。
需求改动频繁，可能昨天做的功能或者做一半的功能突然就舍弃掉了。所以我们正常的测试中一般不会去做敏捷测试，但是有些公司比较推崇。
四、集成测试（integration testing）、系统测试（system testing）
集成测试的重点就是测试各模块的接口，也就是组件或系统之间的交互。
集成测试侧重于集成测试的目标包括：
1.减少风险
2.验证接口的功能和非功能行为是否符合设计和规定
3.建立对接口质量的信心
4.发现缺陷（ 可能存在于接口本身，也可能存在于组件或系统内部
5.防止缺陷遗漏到更高的测试级别
与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更
也不会破坏已有的接口、组件或系统 。
系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。
系统测试的目标包括：
1.减少风险。
2.验证系统的功能和非功能行为是否按照设计和指定的要求进行验证系统的功能和非功能行为是否按照设计和指定的要求进行。
3.确认已完成系统成且系统按预期工作确认已完成系统成且系统按预期工作。
4.建立对整个系统质量的信心建立对整个系统质量的信心。
5.发现缺陷发现缺陷。
6.防止缺陷遗漏到更高的测试级别或生产防止缺陷遗漏到更高的测试级别或生产。一般情况下，系统测试的测试环境应该与集成测试的相同。
我为什么把集成测试和系统测试放在一起，因为我们在做测试的时候，经常是集成测试和系统测试同时进行。
集成测试意味着开发已经完成所有模块的开发，并且对产品有了一定的信心。
所以我们通常是直接进行集成和系统测试，也就是全用例、全流程、全功能、全接口的测试。测试环境由测试人员进行搭建，尽量与生产环境一致。
测试期间测试环境不允许开发人员访问，直到一轮测试结束。
一轮结束后会将测试环境包括数据库移交给开发，用来复现相关问题，并查找问题原因。开发提交新一轮测试后，测试人员重新搭建环境进行测试。
五、验收测试（acceptance testing）
验收测试通常侧重于整个系统或产品的行为和功能。
验收测试通常是由客户、业务用户、产品负责人 或系统操作员负责，也可能涉及其他利益相关方 。
验收测试的目标包括：
1.建立对整个系统质量的信心
2.确认系统 是否完整 且系统将按预期工作
3.验证系统的功能和非功能行为 符合规范
六、其他（确认测试、回归测试）
确认测试：修复缺陷后， 应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例 。 为了覆盖修复缺陷所 需 的变化， 也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。
确认测试的目的是确认是否已成功修复原来的缺陷。
回归测试： 部分代码所做的变更， 无论是修复代码，还是其他类型的更改，都可能会意外地 影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。 变更也可能包括环境的变化 ，例如操作系统或数据库管理系统的新版本。这种意外的副作用被称为回归。
回归测试的目的是运行测试来检测这些意外的副作用。
