单元测试、集成测试、系统测试、验收测试的区别

按项目开发阶段来分：单元测试、集成测试、系统测试、验收测试

1．单元测试

单元测试在实际工作中，是由开发人员在开发完成后自行进行的测试。

在这里先要明确一个概念，单元测试是一种测试，它需要独立设计测试用例及执行bug 修复的过程，而不是开发在完成程序的调试工作。 调试是调试，测试是测试，希望大家不要混淆这两 种不同的概念。 单元测试是指对软件中的基本组成单位进行的测试，如一个模块、一个过程等。 它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的 正确性。 单元测试方法包括：控制流测试、数据流测试、排错测试、分域测试等。

站在测试的角度，测试人员希望开发人员能够在开发程序后进行单元测试。 原因有二。

（1）对于程序员，单元测试能保证一定程度的开发质量，对于程序员自身能力的提高和自我 约束能起到很好的作用。 很多情况下，整体测试执行中的bug数会被体现在开发的绩效中。 而在 单元测试环节，开发就能够通过自测修复一部分bug。

（2）对于测试员，单元测试在保证开发质量的基础上，也减少了测试执行的成本。 这个成本 分为两方面。

• ·测试执行不仅包括测试人员执行测试用例，很多时间是花费在程序员与测试员的交互 上。 这种交互是由于bug管理而产生的。 因为bug数的减少，这部分测试执行的成本会 被压缩。

• ·测试执行大约占整个测试过程1／3的比例。 由于开发质量问题造成测试增大工作量或者被 推翻重来的情况很多。 为了让测试成本可控并且有效地减少项目的成本代价，单元测试 就是有效维护开发质量的方式。

当开发做了单元测试后，测试人员就利用冒烟测试检查单元测试成果。 如果冒烟测试通过， 项目正式进入测试阶段。 如果不通过，则程序被退回，需要开发自行测试通过后，再交于测试人 员进行冒烟测试流程。

还有另外两种情况如下。

（1）单元测试并不是由开发完成的。 而是由专业的单元测试人员完成的。

（2）单元测试是由测试人员提供测试用例，但测试执行由程序员自己完成。

这两种情况虽然和我们常规的单元测试定义不同。 但理论是死的人是活的，只要测试部与开 发部能够达成一致，对该项目有推进作用，那就是可行的方法。

2．集成测试

集成测试是在单元测试之后进行的测试。项目中的集成测试大多由开发自己完成，开发把这 种测试叫作接口联调。独立的集成测试项目是指在软件系统集成过程中所进行的测试，其主要目 的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合 成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确。

集成测试的策略主要有自顶向下和自底向上两种。

（1）自顶向下的集成是从主控模块（主程序，即根结点）开始，按照系统程序结构，沿着控 制层次从上而下，逐渐将各模块组装起来。在从上向下的集成测试过程中，需对那些未经集成的 模块开发桩模块。在集成过程中，可以采用宽度优先或深度优先的策略向下推进。

（2）自底向上的集成是从最底层模块（叶子结点）开始，按照调用图的结构，从下而上，逐层 将各模块组装起来。在从下而上的集成测试环境中，需对那些未经集成测试的模块开发驱动模块。

大部分情况，测试人员所做的集成测试又被称为接口测试。这也是本书所要阐述的测试重点。 接口测试主要分为两种情况。

（1）系统层面

• ·模块与模块间的接口传输是否正确。

• ·系统与系统间的接口的传输是否正确。

（2）代码层面

类与方法的调用。

测试人员会在系统未被组建完全前，对模块的接口调用进行测试。当确定模块的接口传输正 确时，我们可以初步认定模块被集成后不会出现问题。模块与模块间的接口是否传输正确，也可 以通过功能测试的方法进行辨别。

对于复杂大型的系统架构而言，系统与系统间的接口测试比模块与模块间的接口测试更为重 要。例如，一个资金入账的功能，就可能需要通过入账平台、第三方支付平台、资金平台、财务 平台等多平台共同工作完成。这时平台与平台间的接口测试就尤为重要了。模块与模块间的接口 问题，你或许可以通过系统测试时的功能测试被发现。但平台与平台间的接口问题，则需要独立 的集成测试才能被尽早发现。这部分内容，会在接口测试章节中做出详细解析。

3．系统测试

系统测试是在集成测试之后进行的测试，也是测试人员接触最多的测试环节。系统测试是指 对已经集成好的软件系统进行测试，以验证软件系统的功能正确性和性能等是否能满足其需求规 格说明书所指定的要求。软件系统测试方法很多，主要有功能测试、性能测试、兼容性测试等。

在系统测试中，我们会经常用到回归测试和冒烟测试。

（1）回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他 代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。

（2）冒烟测试是指对软件基本的功能进行测试。测试的对象是每一个新编译的需要正式测试 的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑起来，可以进行后续的正式测 试工作。

系统测试在工作中的实践情况为：系统测试是测试人员遇见最多的测试；功能测试就是系统 测试的主要组成部分；在测试人员完成功能测试后，如果需求规格书上有对系统性能、安全性、 兼容性等方面的要求，测试人员应该根据其规定的指标，进行性能测试、安全性测试以及兼容性 测试。

系统测试分为：测试需求提取、测试框架确定、测试用例编写、测试用例执行、测试报告编 写及评审阶段。测试人员在编写测试用例时，需考虑测试执行的顺序。在测试用例执行阶段，测 试人员通常可以将其分为三轮测试及回归测试进行。将整体测试用例合理地分为三轮测试，最好 能做到有两轮测试重复验证重要功能的情况出现，我们称为双重保证。这就需要测试人员去思考， 怎样布置测试用例能够保险且不影响测试效率。在测试人员完成测试提交测试基线前，通常还会 安排一次整体的回归测试以确保主要业务流程的正确性。

4．验收测试

验收测试是在系统测试结果后进行的测试。由客户或最终用户执行，旨在向软件的购买者展 示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是 验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入 使用之前的最后测试。

通常验收测试分为两个部分。

（1）Alpha 测试：由用户在开发环境的场所进行，并且在测试人员对用户的“指导”下进行 测试。测试人员负责记录发现在错误和使用中遇到的问题。总之，Alpha 测试是在受控的环境中 进行的。

（2）Beta测试：由软件的最终用户们在一个或多个客户现场进行。与Alpha测试不同，开发及测试人员通常不在Beta测试的现场，所以Beta测试是软件在测试开发人员不能控制的环境中 的“真实”应用。用户记录在Beta测试过程中遇到的一切问题并且定期把这些问题报告给开发者。 接收到在Beta 测试期间报告的问题之后，测试人员会初步筛选确定其是否为缺陷，再由开发人员 对软件产品进行必要的修改，并将最终的软件产品发布给全体客户。

在很多项目中，除了需求、开发、测试、项目经理这些IT职称外，还有一类职称叫作实施人 员。他们是业务人员与运维人员的综合体。他们可以介入测试阶段帮助测试人员一起测试，也是 验收阶段的主要执行人员。验收测试一般不由测试人员直接进行，因为经过长时间的测试执行过 程，测试人员的思维会形成固式（思维局限性）。实施人员精通业务，他们是需求的创始者，最 后会脱离测试用例的约束，真正从初始需求的角度配置生产环境进行验收测试，做好面向客户的 最后一道防线。