从软件质量保证上来划分测试，测试可以划分成静态测试和动态测试。静态测试就是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过 程、接口等来检查程序的正确性，静态测试可以分为代码审查、代码走读、文档审查等行为。动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并 分析运行效率和健壮性等性能的测试过程。从那条参考的时间轴上来看，动态测试和静态测试可以发生在整个软件生命周期的全过程。关于静态测试和动态测试的更 多讨论在我的博文《静态测试和动态测试》中有比较详细的讨论。

　　按照测试技术（test techniques）划分，测试可以划分为白盒测试、黑盒测试和灰盒测试。在这套理论的介绍中，后面会有专门的一节来介绍这三种测试。其中灰盒测试是指 白盒和灰盒测试相混合的一种测试。从那条参考的时间轴来看，白盒测试发生时间比较靠前，黑盒测试发生时间比较靠后，而灰盒测试发生的时间介于2者之间。

　　按照测试阶段（test levels）划分，测试可以划分单元测试、集成测试、系统测试、系统集成测试、用户验收测试和维护测试，这一划分是根据软件生命周期和测试生命周期中自然形成的阶段进行划分的，当然越靠前的测试越先进行。

　　从第二幅图可以看出，单元测试和集成测试是由开发团队来做的，而集成测试和系统集成测试是由测试人员来做的，用户验收测试是由用户和测试团队来 做的，及时用户不参与，测试人员也是在用户的角度进行测试的，这里没有做维护方面的测试。单元测试是指针对各个单元模块进行的测试；集成测试就是由更多的 已经完成了单元测试的测试单元构成的测试，集成测试仍然不是在一个完整的测试过程上测试；系统测试是程序第一次以一个完整的个体形式进行运行而进行的测 试；而系统集成测试在系统测试的基础上，还要关注整个软件系统与外界的交互，比如调用打印机，比如与本软件系统以外的其他系统进行交互；用户验收测试也就 是通常大家所说的UAT，这个时候整个软件系统已经有了比较好运行状态，可以接受用户验收测试啦。每一阶段的结束被看做是输出，都是作为下一阶段的输入， 在测试流程上有明确的定义什么这些输入和输出的标准，后面的章节会对这些标准做详细的阐述。每一阶段的测试，都应该包含前一阶段的测试内容，也就是前一阶 段的测试内容，但是侧重点不一样，从红色的箭头和红色的边框可以看出各个阶段的测试侧重点。比如UAT过程中遇到了不属于UAT测试项的bug，当然也是 属于UAT的内容。

　　按照测试类型（test types）划分，这些划分包含审计和控制、文档和过程、功能、需求、接口、回归测试、备份和恢复、工作流、性能、压力、容量、变换、安装、错误处理、并 行、事物流、可用、UI、可操作性和安全性等方面的测试。具体的一些测试类型的定义，可以从网上搜索得知。

　　各个测试类型可以发生在各个的测试阶段，从第三幅图可以看出，每个测试阶段所涉及到的测试类型，而静态测试应该和这些测试阶段并列开来，也可以 理解成这些测试阶段都是属于动态测试的。从横行可以看出错误处理和回归测试发生在所有的测试阶段，因为每个阶段都会有bug，有bug就会有回归，当然回 归测试会发生在各个测试阶段。从竖行上可以看出，系统测试涉及到了最多的测试类型，因为这个时候软件系统是第一次以一个完整的个体而运行，需要的测试方面 是最多的。也并不是所有阶段都要进行所有的类型测试。

　　从网上可以搜索到很多关于单元测试的定义，比如百度百科中就有详细的介绍。而此理论中关于单元测试的内容有：

　　单元测试是对新的或者更改过的代码模块进行的初步测试。它验证程序或模块的内部逻辑和程序规范。

　　开始点：单元测试开始在开发阶段，当编码已经完成，单元测试计划已经被有关各方已批准。

　　结束点：单元测试结束后，所有的测试案例被成功执行，没有严重缺陷1或2。一项行动计划已经被记录在案，以解决还未解决的其他缺陷。

　　单元测试的作用：单元测试有助于早期识别和修复缺陷，早期消除单元模块的不确定性。

通过测试程序的各个部分，然后再测试其各部分的总和，集成测试就更简单啦。

　　相关活动：测试计划和测试用例审查，由有关各方批准的基线控制之下；

按计划执行单元测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成单元测试报告。

　　单元测试的评估有：代码覆盖率的百分比，符合组编码标准，圈复杂度，行代码，路径，参数，缺陷密度。

集成测试　　

从网上可以搜索到很多关于集成测试的定义，比如百度百科中有详细的介绍，而此理论中关于集成测试的内容有：

　　集成测试验证多个已经完成了单元测试的模块的执行。所测试的应用程序通常不连接到系统中的其他应用程序。

子系统模块的通信测试是在一个控制和隔离的环境。

　　开始点：集成测试开始时，单元测试已经顺利完成，当集成测试计划已经被有关各方已批准，并且在基线控制之下。

　　结束点：集成测试结束后，所有的测试案例的成功执行，没有严重缺陷1或2。一项行动计划已经被记录在案，以解决所有还未解决的缺陷。

　　集成测试的作用：集成测试有助于较早的识别和修复中缺陷，降低了成本。它也减轻了系统测试过程中的风险。

　　相关活动：测试计划和测试用例审查，由有关各方批准的基线控制之下；

按计划执行集成测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成集成测试报告。

　　集成测试的评估有：成本和进度偏差，缺陷，生产力，效率和测试覆盖度。

　　圈复杂度一种代码复杂度的衡量标准，中文名称叫做圈复杂度。

在软件测试的概念里，圈复杂度“用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行 路径条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很 大关系”。

　　在这套理论中，大多用的是缺陷（defect）一词，认为缺陷（defect）包含的范围大于bug所代表的意思，认为软件一切不足的地方都是 可以当做defect处理，而Bug所代表的内容比defect更少一些。其实现在各个公司有各自的叫法，还有叫issue的，但是意思都是一样的，都是 指软件的不足之处。此套理论的后面部分都是称呼为缺陷（defect）。

　　以后介绍的各种测试的定义，都是按照图中所展示的那样结构来展示。左上角是一堆相关的测试类型或者测试阶段，第一页的最下面一排是关于这个测试类型中的各种文档，相关的文档并不一定全展示完了。第二页的右上角都涉及到了这个测试阶段或者测试类型所常用到的测试工具。

　　“参与者”里面详细地介绍了这个测试阶段有哪些测试角色参与，带点的测试角色就被包含在这个测试中，在实际工作中，各个角色之间可以由同一人担 当。这套理论中，测试团队中都有一两个叫“Test architect”的人，测试架构师是团队中的关键人物，类似于系统架构师或者系统分析师，他的作用是参与系统的研发与架构，分析系统与功能模块，找出测试的难点与关键点，决定测试工具环境平台等方面的主意，在技术上主导团队的测试过程。

　　第二页的右下角有相关的评估方面，这些评估方面就是测试用例设计的依据。

　　单元测试和集成测试都是由开发人员完成，在写完代码后进行的。单元测试和集成测试都有明确定义的开始点和结束点，并且测试结束的时候都要提供相应的输出。测试开始的时候，测试计划都已经被各方批准了才开始，各方是项目经理、测试经理、开发经理、需求分析负责人甚至是客户或者投资者。当这个阶段的 测试过程中未出现严重性为1和2的defect的时候才能结束此阶段的测试，并且未解决的所有defect都应该被记录下来，并且做好何时解决的计划。一个缺陷被解决得越早，越能节省成本；一个发现的缺陷越到后面才来修复，需要更多的成本。

　　很多时候，并没有把单元测试和集成测试分开来做，而是一起当做单元测试来进行的。

　　相关活动：测试计划和测试用例审查，由有关各方批准的基线控制之下；按计划执行用户验收测试用例；通过跟踪需求变更来验证测试覆盖面；进行缺陷分析；完成用户验收测试报告。

　　系统测试的评估有：成本和进度偏差，缺陷，生产力，效率和测试覆盖度。

　　可操作性测试的内容是：

　　可操作性测试验证应用程序或系统可以在生产环境中运行。这是一个动态的测试阶段，其中系统的所有验证操作都在真实或模拟出来非常真实的生产环境中发生。可操作性测试考虑的是性能，资源消耗和符合标准等因素。

　　开始点：用户验收测试开始于成功的上一阶段的用户验收测试的结束，用户验收测试计划已经被有关各方已批准，并且在基线控制之下。

　　结束点：一旦被测系统符合测试计划中规定的结束标准，测试便结束。

　　用户验收测试的作用：确保软件产品的正确交付和直到软件产品的正确部署。避免在生产环境（内部和外部）中产生可操作性方面的业务缺陷。

　　相关活动（由技术支持团队实施和验证如下活动）：部署和备份计划；故障切换和恢复计划；紧急中断/修复计划；在run books中更新生产支持；更新帮助数据。

　　系统测试的评估有：成本和进度偏差，缺陷，生产力，效率和测试覆盖度。

　　用户验收测试（UAT）测试方面的知识，可以在网上找到很多。据我了解，很多公司和很多测试人员都知道这一测试阶段。包括我在内，UAT只是处 于一个系统集成测试之后的测试阶段，应该所有测试用例中涉及到和没涉及到的defect和bug和一切看不顺眼有问题的地方都可以当做测试得到的问题。 UAT是请实际的用户参与测试或者测试人员站在用户的角度去思考和测试系统，而很多时候并没请实际用户参与，只是测试人员站在用户角度去思考和测试。系统 测试和系统集成测试涉及到的很多测试类型，将不再在这个测试阶段进行。这个测试阶段结束的时候，将很接近实际生产中的软件情况啦，客户很可能就决定是否接 受这个软件结果。

　　在前面章节中讲解测试阶段的时候没到可操作性测试，而我用介绍维护测试做了代替。可操作性测试应该是UAT结束后，从项目团队到系统部署的这个 过程，由测试人员和技术支持团队（也就是通常所说的售后技术工程师）在模拟的环境中进行部署操作或者直接到客户那边的实际环境中进行部署。这个阶段要做部 署、回复、故障切换、紧急中断和修复等在实际运行中的计划。而且这个阶段使用到的工具也是部署、监控和维护相关的工具。

　　最后阶段当然是系统部署和交付给客户后的维护过程，维护测试就是在这个阶段之后。产品部署后，客户方面有人会用监控和管理系统的运行，当出现 defect或者异常等情况，售后技术支持工程师会到客户那边进行处理。当售后技术工程师解决不了的话，会交给项目相关的支持团队，这个团队中就包括维护 测试团队。所以很多很大的系统（比如银行的系统）都会有专人就行监控和管理，也会有一个专门的技术团队为这个系统服务。当系统出现defect的时候，交 给这个团队修改和回归测试，然后再以补丁的形式给系统更新。当系统有一些新的小需求的时候，由这个团队来开发和测试，然后交付。这个团队可以由原来开发时 候留下部分人员组成，当然也可以现招聘，可以在招聘中遇到招聘项目维护团队的职位。