软件测试｜测试级别概述（三）

​笔者是软件测试方向的硕士研究生。作为应届生拿下了20余个软件测试、测试开发的offer。

《校招生如何准备测试》 系列会将我的测试理论体系与大家分享、探讨和学习。本期和大家串联一下测试级别的概念。

测试依据（Test Basis）

首先讲一个测试中很重要的概念，测试的开展离不开用例的设计，那一个测试用例的设计应该参考哪些资料？在ISO29119中将测试所参考的知识体系统称为Test Basis，中文翻译为测试依据。不同的测试级别、测试类型都对应着不同的测试依据。测试依据可以是需求、也可以是代码。不同的测试依据对应的测试用例设计技术也不同。

测试级别

本期讲解一个抽象的概念-测试级别，测试级别与软件开发生命周期中瀑布模型中的级别相对应，如图1是瀑布模型的变体（V模型）。这种变体模型强调了测试和设计之间层级的对应关系，软件开发周期中的瀑布模型的不同阶段决定了不同的测试级别。通常情况下测试级别从大到小可分为验收测试、系统测试、集成测试、单元测试四个级别：

1. 单元测试（Unit Testing）

位置：在V模型的底部。
描述：单元测试是针对软件中最小单位（通常是代码中的函数或模块）的测试活动。目的是验证单元的功能是否按照预期工作。
特点：由开发人员编写和执行。

2. 集成测试（Integration Testing）

位置：单元测试之后，系统集成测试之前。
描述：集成测试是将已通过单元测试的模块整合在一起，并测试它们之间的交互作用。
特点：着重于验证不同模块之间的接口和数据流是否正确。

3. 系统测试（System Testing）

位置：集成测试之后，验证测试之前。
描述：系统测试是对整个软件系统进行的端到端测试，旨在确保整个系统符合用户需求并能够正常运行。
特点：验证系统的功能、性能和安全性等方面。

4. 验收测试（Acceptance Testing）

位置：系统测试之后，用户验收测试之前。
描述：验收测试是由客户或最终用户执行的测试，以确认软件是否满足其需求和预期。
特点：通常由业务用户或客户代表来执行。

此外，这四个级别对应的测试依据也是各不相同。测试级别与基于规范的测试和基于代码的测试之间存在一种普遍被认可的关系，测试依据也决定了使用什么样的测试用例设计技术，大多数从业者都认为单元级测试中适合使用基于结构的测试方法，而基于规范的测试方法则适合在系统级测试、集成测试中使用。

敏捷开发模式下的测试级别

随着敏捷开发的盛行，测试不再是瀑布式开发流程的其中一个环节。测试人员需要全程参与软件开发流程，测试开始“左移”，拥有了更多的主动性，也对测试人员有了更多的要求和挑战。

传统的瀑布开发把测试分为：单元测试、集成测试、系统测试和验收测试。而在敏捷开发模式下测试人员需要参与需求讨论与评审、单元测试、系统测试、回归测试等。这时的测试不再区分什么测试级别了。以下是测试人员在敏捷开发不同阶段扮演的角色。（面试问题：你们公司的测试流程是什么？）

需求评审阶段： 测试可以站在客户角度上来阐述自己的观点，和产品、开发等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

开发过程中： 测试应该尽早介入测试，这里的‘尽早测试’可以理解为，在接口确定下来之后，尽早进行接口测试用例设计与接口自动化设计（测试左移）。在开发完成程序开发与单元测试后，测试人员可以进行code review（代码复查可以显著提高测试效率），通过review代码加深测试人员对业务的理解、提高测试用例的覆盖率，同时也可以避免一些冒烟测试不通过的问题（严重bug）。

提测阶段： 分析要测试的类型，比如：功能、性能、安全等方面（可参考上一篇推文），完成新功能的测试，针对程序中修改的地方要提前做风险分析，根据代码调用情况，捕获受影响的服务，确定回归测试的范围并执行对应的自动化脚本。

灰度阶段： 灰度放量，对用户分批放量，查看线上是否出现异常。（测试右移）

下面是本系列的文章目录：

本期小tip

加强对测试级别的了解，能让测试人员对项目整体流程有更清晰的认识，可以帮助QA找到每个阶段的重点和抓手。

好了，以上就是本文的全部内容，如有问题可留言讨论。

我正在组建测试开发方向的求职交流社区，如果您对软件质量管理方面感兴趣，欢迎加入了解。

欢迎点赞、评论、收藏，it's important for me.

Searching for QALog ​