uat测试⽤例和sit测试⽤例_测试理论——SIT测试和UAT测试
概念
SIT测试和UAT测试持续集成的概念
在企业级软件的测试过程中，经常会划分为三个阶段——单元测试，SIT和UAT，如果开发⼈员⾜够，通常还会在SIT之前引⼊代码审查机制(CodeReview)来保证软件符合客户需求且流程正确。下⾯简单介绍⼀下SIT和UAT的基本情况。
SIT(SystemIntegrationTesting)系统集成测试，也叫做集成测试，是软件测试的⼀个术语，在其中单独的软件模块被合并和作为⼀个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进⾏作为它的输⼊模式，组织它们在更⼤的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的⽬的是校验功能、性能和可靠性要求，配置在主设计项⽬中。
UAT(UserAcceptanceTesting)⽤户验收测试，通常是由最终软件的⽤户(通常这些⽤户不了解软件的具体逻辑，⽽对业务逻辑却相当熟悉)进⾏的测试，因此是⾯向最终⽤户的测试，结束之后通常就可以发布⽣产环境了。
区别与联系：
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进⾏导⼊初始化，也可以是通过接⼝进⾏分发，但是具体的规则必须建⽴好，同时在基础数据初始化完成后必须做校验，以确保期初的基础数据在各个系统是⼀致的。
本⽂内容不⽤于商业⽬的，如涉及知识产权问题，请权利⼈联系51Testing⼩编(021-********-8017)，我们将⽴即处理

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。