uat测试用例和sit测试用例_集成测试和UAT测试(8.7)

这篇文章再回顾下对于大型项目建设中集成测试和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进行导入初始化，也可以是通过接口进行分发，但是具体的规则必须建立好，同时在基础数据初始化完成后必须做校验，以确保期初的基础数据在各个系统是一致的。

集成测试和UAT测试各自的关注点

注意，对于SIT环境的集成测试，重点是关注两个业务系统之间两两是否能够集成起来，而到了UAT测试，则关注的是多个业务系统之间是否完全能够串联起来完成一个端到端流程。即集成测试的测试数据准备满足两两系统之间即可，而对于UAT测试时候的数据准备，却需要从头到尾完整的用一套数据，能够从头走到尾。

这和我们搭积木往往是一个道理，即只有首先保证两个积木之间能够集成起来，然后才可能去讲多个积木串联起来形成一个完整流程。

同时对于做集成测试的人虽然也是做黑盒测试，但是他们却很清楚如何通过测试用例来覆盖到所有的跨系统交互接口，而到了UAT测试阶段，做UAT测试的人往往并不关心这点，而是完全从端到端业务场景触发去做验证。UAT测试的前提假设是只要端到端流程能够跑通，那么一定是覆盖了所有的跨系统接口的。