测试理论——SIT测试和 UAT测试概念

快来打我* 2021-09-28 11:20 812阅读 0赞

# SIT测试 和 UAT测试 #

在企业级软件的测试过程中，经常会划分为三个阶段——单元测试，SIT和UAT，如果开发人员足够，通常还会在SIT之前引入代码审查机制（Code Review）来保证软件符合客户需求且流程正确。下面简单介绍一下SIT和UAT的基本情况。  
SIT (System Integration Testing) 系统集成测试，也叫做集成测试，是软件测试的一个术语，在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。  
UAT (User Acceptance Testing)用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。

# 区别与联系： #

SIT是集成测试、 UAT是验收测试  
从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。  
从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试。它们两个之间的专注点是不一样的.UAT主要是从用户层面这些去考虑和着手测试,而SIT主要是系统的各个模块的集成测试.这在整个软件过程理论的基础知识中相当重要的.理论上讲SIT是由专业的测试人员去完成,UAT是由用户去做的.  
如果按照规范来的话,做UAT测试的人一定是要对业务很精通的,并且是具有代表性的用户,关注的东西就是业务流程是否通畅是否符合业务的需要.以需求分析文档为重要参考,还有一些用户的操作习惯等等一系列的东西.

# 对于大型项目环境的准备问题 #

前提假设是一个大型集团性项目同时规划建设A，B，C，D等多个业务系统，同时建设4A平台，流程平台和ESB服务总线等基础技术平台。这个在我2012到13年企业私有云PaaS平台建设中，专门对集成测试方法和流程进行了详细的阐述，因此在这里只重新回顾一下关键点。

一般需要准备DEV，SIT，UAT和PRD四套环境，即开发，集成，用户验收和生产四套环境。开发环境用于开发厂商自己的单元测试和接口联调，SIT环境用于正式的集成测试，UAT给最终用户验收测试使用。

## 注意对于测试有两个维度的说法。 ##

a.一个维度是单元测试，集成测试和系统测试。  
b.一个维度是开发环境测试，集成环境测试和UAT环境测试。

为什么强调这个概念，因为两个维度都出现了集成测试，容易混淆。即在SIT集成测试环境不是指只做接口的集成测试，在SIT环境同时需要做接口集成测试和业务系统功能点的系统测试。也就是说SIT环境本身也是黑盒的系统测试，只是这个系统测试首先会选择跨系统接口的场景进行测试，确保跨系统场景是通的，然后接着再做业务系统内部的详细功能点测试。

而对于UAT环境的测试，往往不会特意去强调对接口的覆盖，而是完全根据业务场景出发进行测试，端到端的业务场景如果都能够跑通，那么自然是覆盖了所有的跨系统接口的。

因此对于三个环境实际进行的测试内容为：

a.DEV环境：主体是开发厂商自己进行，包括了单元测试+接口集成测试+业务模块功能点的系统测试。  
b.SIT环境：可以是整体集成商牵头进行，包括接口集成测试+系统测试，但是全为黑盒测试。  
c.UAT环境：以甲方用户牵头进行，也是只进行系统测试，以端到端流程和业务场景驱动进行测试。

## 环境和部署包迁移的问题 ##

这个实际上我在持续集成方法论中讲过多次，对于SIT环境和UAT环境的部署，都不应该是重新进行编译和构建，而是应该基于DEV环境测试通过的部署包进行迁移，在进行迁移后只修改相应的配置文件。这个当时在执行Ucloud项目的时候，我们完全可以做到上面这种要求。同时对于编译，构建，环境迁移都全部统一管理，开发厂商只能需要按时提交和Checkin代码，由统一的配置管理员进行编译构建和环境部署。虽然没有完全做到基于PaaS平台的自动部署，但是也实现了完整的持续集成过程和版本管理。

一个开发厂商建设的A系统，首先是在Dev环境进行单元测试，那么什么时候能够迁移到SIT环境。

比如，A系统往往涉及到调用B，C等系统的外部接口，那么需要B和C系统配合才能够完成A系统内部各个功能点的测试，这个时候就需要B和C系统已经部署了配合的接口服务。当然也可以是B和C没有部署，A系统自己实现了了一个接口服务模拟器，类似测试挡板和测试桩。但是整体原则都是A系统必须所有功能都自测通过，才能够申请迁移到SIT环境。

注意，这里A系统自测只会关心自己消费外部的接口全部通过，并确保自己提供的功能模块各功能都可以就可以了。对于其它系统消费A的接口它并不会关心。

如果在DEV环境，每个模块都按照刚才的方法自我验证通过，那么基本确认各个模块相互之间集成应该是没有问题的，那么这个时候才能够都迁移到SIT环境，根据业务集成场景进行集成测试。跨系统交互的业务集成场景自然就会覆盖到所有的集成接口。

对于每次的环境迁移，比如在从SIT环境迁移到UAT环境后，都需要准备一个最基本的冒烟测试脚本先进行冒烟测试，确保环境迁移本身没有问题，然后再进行详细的功能性测试。对于冒烟测试可以是人工进行，也可以是通过自动化测试脚本进行。

即使你没有采用持续集成和持续构建方法论，但是环境迁移和各个环境本身的测试状态，当前各个业务系统在各个环境的部署包的版本都必须得到统一的管理，需要有一个类似可视化看板一样的东西能够很明确的看到当前各个业务系统版本在各个环境中的状态情况，并在某次集成或UAT测试结束或通过后及时的标记关键的基线版本。

## 环境迁移的复杂性 ##

任何环境的迁移，不仅仅是业务系统自身部署包的迁移，同时还涉及到ESB集成平台服务的迁移和部署。而ESB总线的环境迁移仍然应该是迁移部署包的模式，同时只能够是修改相应的配置文件。

注意，对于环境迁移不仅仅是迁移各个业务系统的部署包，更加重要的是静态基础数据的初始化，即在进行SIT或UAT测试之前，各个系统应该有一套相同的基础主数据信息，这个是后续测试的基础。对于这部分基础数据，可以是通过文件或Excel进行导入初始化，也可以是通过接口进行分发，但是具体的规则必须建立好，同时在基础数据初始化完成后必须做校验，以确保期初的基础数据在各个系统是一致的。