软件测试分哪几种？

软件测试的分类有很多种，它们分别站在不同的观察角度，但是无论哪一种都是针对测试工作内容进行划分的。

1.4.1　按照开发阶段划分

众所周知，软件测试和软件开发相辅相成，因此按照开发阶段划分相对来说应该最容易了。按照开发阶段，软件测试的划分如图1-10所示。

图1-10　按照开发阶段软件测试的划分

按照图1-10的划分方式，软件测试很容易就和软件交付的V字模型对应上。其实V字模型就是较早对测试进行细分的一种模型。

单元测试的被测对象是程序模块，这是软件设计中最小的模块。

集成测试的被测对象是将程序模块组合到一起且对外暴露的接口，这里重点验证集成到一起的程序模块是否满足概要设计的要求。

确认测试就要验证被测试软件是否满足软件需求规约中的要求，重点检查功能特性的符合程度。

系统测试是指在真实或者仿真环境中对被测系统进行验证。在这个阶段，除功能性之外，还包含性能效率等其他质量特性要求。在很多实际项目中，常常把确认测试和系统测试合二为一。

验收测试是指按照最初的约定，验证被测系统、软件需求规约、用户手册三方的一致性，以及非功能特性的符合性。

1.4.2　按照测试实施组织划分

除按照开发阶段进行划分外，软件测试还可以按照测试实施组织来进行划分，如划分为α测试、β测试。按照测试实施组织，软件测试的划分如图1-11所示。

图1-11　按照测试实施组织软件测试的划分

这里说的α测试指由一名用户在非生产环境下进行的验收测试，这里强调开发人员或者测试人员陪同完成验收测试，实时记录暴露的缺陷。β测试指由少部分用户在真实环境中完成的验收测试，β测试与α测试有一个明显的区别，就是没有开发人员或者测试人员的陪同。α测试、β测试都隶属于验收测试。

1.4.3　按照测试技术划分

如果站在测试工程师的角度按照测试技术划分软件测试，那么有两种划分方式。一种是按照测试过程中是否需要了解程序结构和处理过程来划分，另一种是从是否需要检查代码运行结果的角度来划分。按照测试技术，软件测试的划分如图1-12所示。

图1-12　按照测试技术软件测试的划分

按照测试过程中是否需要了解程序结构和处理过程，软件测试可以划分为白盒测试、黑盒测试及灰盒测试。

按照是否需要检查代码运行结果，软件测试可以划分为静态测试和动态测试。白盒测试既可以是静态测试也可以是动态测试，灰盒测试、黑盒测试只能是动态测试。

1.4.4　测试左移

测试左移的概念最早由Arthur Hicken提出。Arthur Hicken提出，为了弥补瀑布模型的不足，以及避免测试工作成为系统交付前的最后且唯一的质量保障手段，测试应左移并贯穿于项目的整个研发生命周期。

这也说明测试工程师在项目的需求分析阶段就应该参加相关活动，从而在需求分析阶段就站在测试角度补充各种验收条件。从需求分析开始到测试业务分析，再到测试用例设计、测试执行及测试结论总结，都应由同一名测试工程师完成。在此过程中，这名测试工程师可以不断地理解需求并澄清需求。

测试工程师在需求分析阶段就参与相关活动，能够更早地帮助开发人员发现系统在设计之初就存在的业务逻辑缺陷、使用缺陷及交互缺陷，从而将一些缺陷在系统开发之前就排除，避免团队投入的浪费，提高团队的投入产出比和交付效率。　　

此外，当研发工程师开始开发系统时，测试工程师就可以同步完成测试用例的设计。在这里，并不像传统方式下那样按照系统的操作步骤设计测试用例，而是按照业务流程的梳理结果设计测试用例。这种更深入的参与和理解能促进测试工程师获得产品的完整知识，彻底理解各种应用场景，并根据软件行为设计实时场景。以上这些都能帮助制品团队在编码完成之前识别出一些缺陷。测试左移聚焦于使测试人员在最重要的项目阶段就参与进来，将关注点从发现缺陷转移到风险预防，从而避免一些技术风险和业务风险，同时驱动项目商业目标的实现。

当测试团队不断实践测试左移时，质量文化便会在整个团队中不断建立并传播，人们不会再将质量保障等同于在测试中发现缺陷，而是参与到项目的各个环节中以降低业务风险和技术风险，促进团队所有成员积极合作，在项目的初始阶段就为满足业务需求及避免业务风险开展工作。测试工程师在项目开始阶段就应为建立有效的测试策略不断努力，并在测试策略的指导下避免业务风险和技术风险，使整个团队聚焦于产品的长期价值和可靠性。

随着测试左移思想的发展，更提倡测试工程师在需求阶段就开始有质量保障的输出，因此开卡、验卡实践越来越受到各种DevOps实践团队的推崇。

当团队中开发工程师准备实现一张故事卡片时，他会按照故事卡片上的验收条件向测试工程师、产品经理详细讲解自己对故事的理解，以及如何实现。这时，如果产品经理发现故事卡片有遗漏的验收条件，就需要及时补充，测试工程师基于自己对需求的理解、对系统全局的认识及对上下游依赖的分析，补充验收条件中缺失的内容，这种快速的集合讨论就是开卡（Kick Off，KO）动作。

开发工程师完成开发后，同样需要将产品经理、测试工程师集合到一起，按照故事卡片上的验收条件和已经实现的系统完成验收，这里产品经理站在是否实现了对应故事的角度进行分析，测试工程师站在是否完善的角度进行分析，通过验收后进入测试环节，这个动作称作验卡（Desk Check，DC）。

在这个过程中，验收条件就是这条需求的测试用例，测试工程师只需要补充一些非功能测试用例就可以了。这种验收条件和开卡、验卡的实践保证了交付的流畅度，是目前测试左移一种有效的实践方式。

1.4.5　测试右移

测试右移是相对于测试左移而言的，指制品发布到生产环境之后进行的一些测试活动。但是这里的测试活动并非通常说的测试活动，而是指通过环境监控、业务监控、APM等手段考量服务的可用性、稳定性等，以便在发现生产环境的问题时，尽快将问题暴露给制品交付团队并快速修复，给予用户良好的使用体验。

测试右移就是将测试移动到生产环境，这就决定了该部分的测试活动与通常说的测试活动有很多区别。在传统的测试角色分工中，生产环境的负责人是运维工程师，运维的核心工作理念是“稳”，这就和当前测试工程师要求的快速验证、快速修复有冲突。

测试右移不仅包括在生产环境中进行测试活动，还包括在生产环境中进行的部分测试实践。

测试右移不是和运维冲突，而是利用运维的一些技术平台给测试工程师一些判断的输入来源，然后结合测试中原有的一些技术沉淀，完成服务质量的保障工作，以便早发现、早预防。其具体方法如下。

〓● 利用运维技术平台。充分利用运维工程师提供的监控平台、日志平台等数据监控服务的状态，以便更早地发现生产环节中存在的问题，并将对应问题的一些留痕数据（日志信息、监控数据等）记录到缺陷系统中，从而辅助解决对应生产缺陷（如果造成损失也可能是故障）。

〓● 利用自动化测试。利用自动化测试手段为生产环节提供业务正确性的巡检功能，这样既可以在运维工程师保障服务的基础之上模拟自动化测试的业务逻辑，又能保障业务的稳定性。这是监控分层的一种思想实践。

除此之外，用户使用系统的行为有可能并不是按照该系统设计的预期方法进行的，因此需要在测试右移环节中，通过前端埋点等技术记录真实用户的使用方法、喜好等，从而在测试左移时反哺业务需求。这样，我们就可以在测试左移时关注测试右移中获得的很多有价值的需求信息，从而充分保障从业务到需求环节的质量。

当然，如果要完成这种实践，我们必须要实现真正的敏捷测试，而非披着敏捷外衣的伪敏捷实践。

虽然生产环境以稳定为前提，但是仍有一些测试技术和测试环境可以在该前提下实施。

〓● 全链路测试。全链路测试是通过流量录制、回放技术在生产环境中完成的测试技术。当然，生产环境下的全链路测试并不是测试工程师就可以完成的事情，这需要对被测系统做全套的技术改造。

〓● 灰度环境。有了灰度环境，系统就可以在部分环境中先上线，然后再进行一些测试活动或者实验活动。

〓● A/B测试。A/B测试可能在用户增长领域比测试领域应用得更广，但它也是一种对生产环节的测试验证活动。

1.4.6　测试左移、测试、测试右移的关系

测试越早开始，发现问题、修复问题的成本就越低。那多早才算早呢？当然是在软件开始的初期，也就是开卡阶段，测试工程师就参与到项目中，以发挥质量保障作用。在开卡阶段，测试工程师的工作也很重要，他要评估需求的质量，并给出完善的建议。

测试工程师在开卡阶段对故事验收条件的考虑如图1-13所示。

图1-13　对故事验收条件的考虑

具体要求如下。

〓● 唯一性：对应的故事是全部系统中的唯一功能，不能存在两个相同的功能。既要横向对比一次迭代中的需求，也要纵向对比已有的功能。

〓● 完整性：每一张故事卡片的描述都是完整的，都有对应验收条件的完整描述及约束描述，没有不确定性的描述。

〓● 可测试性：每一个验收条件都可以验证，其中既包含了功能性也包含了非功能性。

〓● 一致性：验收条件之间是一致的，无冲突的，每次迭代中故事卡片的内容和已有功能也是一致的，无冲突的。

〓● 易理解性：验收条件的描述和设计上是容易理解的，通过故事卡片上的描述就能判定实现的功能。

依照上述特性要求完成故事卡片的评估并补充不完善的验收条件，就完成了测试左移的第一步，接下来进入代码评审、代码扫描、单元测试等针对开发工程师产出物的评价环节。代码扫描属于静态测试技术的实现手段，单元测试是动态测试技术的实现手段，这两种测试手段都属于白盒测试。

测试左移的目标是防止缺陷并降低技术风险，这意味着要持续不断地进行测试，才可以交付高质量的产品。

相对于测试左移，测试右移指产品发布上线或者交付客户后的一些与质量相关的活动，从而保障业务的连续性，提升交付后的产品质量。这里的质量活动包含生产环境监控、生产日志监控、线上巡检、业务指标监控等方面。在生产环境中发生故障时，测试工程师可以把生产故障反馈给制品交付过程中解决问题的关键角色，完成质量回溯的职责。

测试左移、测试、测试右移的关系如图1-14所示。

图1-14　测试左移、测试、测试右移的关系

一图胜千言，图1-14已把测试左移、测试、测试右移解释清楚了，这也是敏捷测试的约束范围。

书籍推荐

持续测试

陈磊 著

本书旨在讲述如何通过持续测试交付一个功能完善、质量完美的系统，满足测试人员快速交付、快速迭代的需求。本书首先概述了什么是持续测试，以及持续测试和自动化测试的异同，介绍了如何提升持续测试的效率和效果，然后讨论了如何通过持续测试中的非功能性测试保障软件的可靠性、可用性、可移植性、性能效率等质量特性，如何通过建立质量门禁保障所交付系统的质量，并通过自动化提升质量效能，最后介绍了持续测试技术的发展，讨论了如何通过有效的度量促进质量的成熟，以及持续测试下测试工程师的自我修养。

本书适合测试人员阅读。