企业官网建设流程全解析

前阵子一个做开发的同学问我，项目群里测试同事天天喊“SIT环境挂了”“UAT又发现两个问题”，自己只能靠上下文猜，实在不好意思开口问这两个词到底是什么意思。这个场景我再熟悉不过了——我刚开始做后端那会儿也是这样，需求评审、排期会议、提测单、验收签字表上到处是SIT、UAT这些缩写，除了知道它们是一种“测试”之外，完全说不清楚区别。这篇文章打算一次性把这两个词讲透，把它们的定义、执行方式、排期比例、常见坑都讲明白，希望对刚入行的开发、测试、产品经理和项目经理有点帮助。

1. 研发流程中的“测试阶梯”：SIT和UAT各在哪一级

1.1 从提需到上线，一个需求要过几道测试关卡

一个需求从提出到交付上线，测试的关卡大致可以分成五道：单元测试、集成测试、系统集成测试、用户验收测试、线上验证。单元测试是开发自己写的，验证函数、方法、类这些最小粒度的逻辑是否正确；集成测试验证同一系统内多个模块拼接在一起能不能对得上；SIT全称System Integration Testing（系统集成测试），是把整个系统的各个子系统、外部依赖全部连接起来，模拟准生产状态做全面验证；UAT全称User Acceptance Testing（用户验收测试），由业务方或最终用户代表模拟真实业务操作做最终验收；最后是上线后的线上验证，靠监控和告警来兜底。这五道关卡不是所有项目都会走全，比如纯前端小页面可能单元测试加线上验证就完了，但企业级交付里，SIT和UAT几乎是最低配的两道关。

很多人觉得测试阶段越多、项目周期越长、越耽误上线，于是能砍就砍。实际上，SIT和UAT不是同一个东西拆成两遍做，而是分别解决两个完全不同的问题：SIT解决“系统的工程质量”问题，UAT解决“业务的匹配程度”问题。你可以把SIT理解成“造车的时候做碰撞测试、雨淋测试”，把UAT理解成“把车钥匙交给客户，让客户按自己的驾驶习惯开一圈说行不行”。没有SIT，车可能出厂就带着零部件匹配错误；没有UAT，车可能是合格的工业品，但不是客户想要的那款车。

1.2 为什么不能只做一轮测试就上线

很多非测试背景的同学会问：开发自测没问题、功能都跑通了，为什么还要搞这么多轮测试？直接上线不行吗？还真不行。开发自测是拿着需求文档写代码，测试数据往往是开发自己造的“理想数据”——字段合规、逻辑顺序完全正确、不会出现脏数据。而真实系统里跑着的，是各种历史数据、异常数据、跨系统返回的超时和错误响应。SIT阶段重点解决“系统之间接口对不对、数据传得对不对”的问题，UAT阶段重点解决“业务上能不能真的用起来”的问题。

举个很直观的例子：一个订单系统调用库存系统的扣减接口，开发自测时两个服务都在本地连同一个开发库，调一下通了他就觉得没问题。结果到SIT阶段把系统部署到集成环境，用真实配置联调，发现订单系统传的是一个Long类型的productId，库存系统那边接口定义的却是Integer，超出精度后直接报错；再往下测，发现订单系统调用库存接口的超时时间设了3秒，库存系统内部又要做事务又要发MQ，平均响应就要2.8秒，高峰时段一慢就大量超时。这种问题在开发自测阶段几乎不会暴露，只有把系统真正“接”起来按生产环境跑，才能发现。

只靠开发自测就上线的系统，大概率会在上线后一个月内被用户的各种花式操作打崩溃。我做过一个数据同步的工具，自测时同步几百条数据很顺畅，结果一上生产同步全量历史数据，直接内存溢出重启。这个场景如果当时有SIT环节，用接近真实规模的数据量测一遍，根本不会带到生产去。

2. SIT系统集成测试：验证“积木拼起来能不能正常运转”

2.1 SIT到底测什么：接口、数据流、跨系统协同

SIT的核心是“集成”。现在很多业务系统根本不是单机软件，比如电商平台通常有订单中心、库存中心、支付中心、会员中心，这些中心可能是完全不同的团队开发维护的，甚至有的是外采系统、有的是老系统改造。每个中心单独测功能都正常，但SIT把它们全部拼起来联调的时候，你会发现各种稀奇古怪的问题：

• 接口路径和参数名对不上，尤其是一个系统拿另一个系统的接口文档时，文档更新不及时，代码已经改了但文档还是旧的
• 字段类型不一致，一个系统用String，另一个用Long，中间没有做转换
• 报文格式不匹配，比如一个系统期望JSON，另一个传过来XML
• 超时和重试机制互相冲突，A系统重试3次，每次隔1秒，B系统设置的是重试前要等完一个长事务，结果造成大量重复调用
• 幂等没做好，MQ消息重复投递时业务数据被插了两遍
• 数据最终一致性没有保障，主表更新成功了但明细表没更新成功，对账对不上

SIT的主要任务是围绕这些“跨系统协同”问题去做验证，同时也会把系统当作一个整体做端到端的功能校验。它和单元测试最大的区别在于：单元测试保证“零件是好的”，SIT保证“零件组装起来还能正常运转”。

2.2 谁来执行、用什么数据、怎么算通过

SIT的执行主力一般是测试团队，开发也要协同参与。测试人员根据接口文档、需求文档和业务流程图编写测试用例，覆盖正常的业务主流程之外，还会去构造各种边界场景，比如订单金额为0、扣库存超过现有库存、支付超时、外部系统不响应、并发下单同一件商品、用户权限缺失等。这一行做久了你会发现，有经验的测试写出来的用例，往往比开发写代码花的时间还多，但价值也正在这里——他们站在“破坏系统”的角度找问题。

工具方面，接口测试常会用Postman、Apifox、JMeter这类的工具，自动化程度高一点的公司会搭建自动化接口测试平台，把几百条用例沉淀成回归用例集，每次版本迭代跑一遍。缺陷管理一般用Jira、禅道或者自研的缺陷平台，缺陷单里要有标题、环境、前置条件、复现步骤、期望结果、实际结果、日志和截图，缺了任何一项，开发都可能去“猜”问题，来回沟通的成本会很高。

数据准备上，SIT以造数据为主，一般不会直接用生产全量数据，而是通过SQL脚本、接口造数工具准备一套与真实业务形态接近的模拟数据，再手工构造一些脏数据、异常数据来验证系统的健壮性。SIT通过的标准一般定成几条：

• 本轮测试用例执行率达到100%
• 阻断性缺陷和严重缺陷全部修复，并完成回归验证
• 遗留的低级缺陷有明确的处理结论，不影响后续UAT开展

2.3 SIT和开发自测的分工边界

开发自测是把代码按自己理解的方式“跑通”，SIT是按测试用例设计者的验证思路把业务全链路“跑穿”。我见过不少开发觉得自测过了就等于SIT一定会过，其实差距很大。自测时你只会按照正常路径点几下，SIT测试人员会拿着几十条甚至上百条用例逐条验证，包括并发、权限、异常、边界、兼容性。开发自测没有覆盖到的场景，往往就是SIT阶段暴露缺陷的重灾区。

我自己踩过一个很典型的坑：一个导出功能开发完，自测时导出10条记录没问题就提测了。SIT阶段测试人员拿一个页签数据量超过三十万的列表导出，直接内存溢出，整个服务都挂了。这个场景自测基本不会想到，但用户的实际使用场景里非常常见。后来我们团队对所有“导出”“报表”“批量处理”类型的接口，在自测清单里专门加了一条“大数据量级验证”，就是被这个坑逼出来的。SIT和开发自测的本质区别，是“按我理解的方式验证”和“按我设计的验证策略来验证”之间的区别。

3. UAT用户验收测试：业务方用自己的流程来“验收”

3.1 UAT测的不是功能，是“业务能不能跑通”

UAT和SIT的视角完全不同。SIT问的是“功能做得对不对”，UAT问的是“业务上能不能用起来”。执行人也变了——从测试和开发，变成了业务方、最终用户代表或者产品经理。他们会拿着真实业务的流程手册，按平时工作的操作习惯去操作系统。比如一套ERP系统，财务人员会在UAT环境里真的创建一个付款单、真的提交审批流程、真的导出付款申请的Excel，如果他们平时的工作习惯里表格必须包含特定字段和格式，那么系统导出的内容只要有一个字段对不上，就会被判定为验收不通过。

这类问题在SIT阶段往往很难发现，因为测试人员虽然懂业务逻辑，但并不知道财务流程里的实际操作习惯。UAT的价值就在于此：把判断标准从“开发测试认为对不对”换成“业务用户觉得行不行”。很多时候开发觉得“这功能做完了”，业务方一上手就发现不对，因为流程顺序不对、按钮位置反人类、必填项设置得不合理、权限粒度跟组织架构对不上。

3.2 典型UAT执行方式：UAT脚本、业务演练、验收签字

UAT不等于让业务方随便点点鼠标，而是要有组织的执行。比较正规的做法是提前准备UAT测试脚本（也叫UAT Checklist），脚本的内容由产品经理和测试团队根据业务场景编写，把核心业务流程拆成一条条可操作、可勾选的步骤。业务方拿到脚本后照着操作，每完成一个步骤记录结果，发现问题时填写缺陷单或者截图反馈，整个过程形成记录。

所有核心场景验证完毕后，项目组会跟业务方一起开一个UAT review会议，盘点所有缺陷和遗留问题，确认没有阻断性问题后，业务方在UAT验收意见书（UAT Sign-off）上签字。这份签字代表业务方正式确认系统可以上线，后面如果再出问题，项目组的责任就轻了很多。很多公司的UAT会专门找个会议室用投影一起操作，业务方一条流程走下来，所有人当场看结果，这种透明方式在跨部门协调时效率很高，也避免了事后扯皮说“我根本没看到这个效果”。

3.3 UAT发现的“新需求”和“优化项”怎么处理

UAT阶段业务方经常会提出“这里能不能再加一个字段”“这个列表能不能默认按时间倒序”“这个页面的颜色能不能换一换”。这类问题一半是真实缺陷，另一半是业务方看到成品之后产生的新想法。处理原则很简单：先记录、再分类。

• 功能不正确、业务流程走不通、数据算错、权限越权，属于缺陷，必须当天评估，严重的立刻修复并重新部署到UAT环境
• 体验优化、样式调整、提示语修改、新增查询字段这些，属于增强项，记录到下一期迭代，不要马上动

最忌讳的就是UAT期间大动核心逻辑。我之前经历过一个项目，UAT第二天业务方提了一个列表过滤逻辑的优化，开发觉得改动简单，不到一个小时就改完、没做完整回归就发上去了。结果这个改动影响到了另一个核心流程的数据展示，UAT直接中断了两天，整个排期往后拖了一周，原因就是“小改动也要走完整回归”这条铁律被破了。

另一个典型案例是UAT期间业务方提了一个导出报表新增汇总行的需求，产品经理觉得不过分就答应了，开发加了两天班做出来。结果上线前一天导出功能又出问题，临时回退，把原本已经验证完的支付流程也连带着影响到了。这类“临时插需求”是UAT阶段项目延期和线上事故最常见的导火索。

4. SIT和UAT的核心区别：一张表理清所有疑问

4.1 一句话概括核心差异

SIT验证的是“系统搭得对不对”，UAT验证的是“业务走不走得通”。这句话虽然简单，但基本能帮你应对大多数场景下的判断。测试环境的接口报错、字段对不上、数据不一致，属于SIT范畴；业务流程不符合日常操作习惯、导出的内容不是业务想要的格式、审批流节点设置不合理，属于UAT范畴。

理解这个差异，比死记硬背SIT和UAT的英文全称更重要。很多人问SIT和UAT有什么区别，其实真正问的是“我遇到的问题该找哪个阶段负责”“我排期该给多少时间”“我提的缺陷该归到哪一类”。这些问题都能从上面那句话找到答案。

4.2 多维对比表

这张表不是让你背下来的，而是想说明：SIT和UAT不是简单换了一拨人去测，而是目标、数据、用例设计思路、完成标准都发生了实质性的变化。

4.3 边界模糊时的判断方法

实际项目里SIT和UAT并没有泾渭分明的边界。小团队一个两三周的小版本，SIT可能只花两三天，UAT两天就过了；大型系统改造，SIT可能持续一两个月，UAT也有好几轮。判断一个问题到底该归到哪一边，最简单的办法就是问“谁来提这个缺陷”：测试人员站在技术视角发现的接口不通、数据不一致、系统崩溃，归SIT；业务方站在使用视角发现的业务流程不顺畅、审批链顺序不对、报表格式不符合要求，归UAT。如果两拨人都发现了同一个问题，说明这是一个兼具技术与业务属性的大问题，开发测试产品三方要一起去处理。

边界模糊的时候，判断标准还可以进一步细化：如果系统不接外部依赖也能暴露问题，那它更偏向功能测试；如果必须把多个系统全接起来才能复现，那它属于SIT；如果必须按业务操作流程一步步点完整个闭环才能看出来，那它几乎可以肯定是UAT层面的问题。

5. 排期、环境和缺陷流转：SIT/UAT落地时最常踩的坑

5.1 排期怎么估：SIT多久、UAT多久、缓冲留几天

排期是一个很讲究的事情。给SIT和UAT估时间，不能拍脑袋，也不能只看开发周期。我常用的一套粗略估算办法是：包含三四个子系统的中型项目，SIT一轮一般需要5到10个工作日，通常安排两轮，第一轮全量回归暴露缺陷，第二轮针对缺陷修正和相关模块做重点回归；UAT一般安排1到2轮，每轮3到5个工作日。开发周期越长、子系统越多、外部依赖越复杂，SIT的时间要相应拉长，UAT则可以相对固定，因为业务方的验证范围主要由业务场景数量决定。

实操中我建议SIT和UAT之间至少留出2到3个工作日的缓冲，用于缺陷修复后的回归测试。这个缓冲一定要写进项目计划里，不要口头承诺“我们很快的”。另一个容易忽略的是环境准备时间：SIT环境要部署最新包、初始化测试数据、配置外部依赖；UAT环境要同步配置权限账号、准备业务方熟悉的数据样例。这些时间看着零碎，加起来往往要占整个测试周期的四分之一，提前不规划好，排期一定会乱。

5.2 SIT环境和UAT环境为什么要分开

原则上SIT环境和UAT环境应该分开部署，原因很简单：两个环境的使用场景和稳定要求完全不同。SIT环境面向开发测试，代码迭代频繁，一天可能重新部署好几遍，数据库随时可能被开发刷新；UAT环境面向业务验收，要求尽量稳定，业务方今天测到一个问题，明天再来验证，希望看到的环境状态和昨天一致。

如果共用一个环境，开发在SIT过程中刷新了数据库或者重新部署了一个中间版本，业务方在UAT侧正看着系统，眼瞅着功能一会儿有一会儿没有，数据也跟着变来变去，根本没法定。这样的“环境不稳定”往往会被业务方解读成“系统质量差”，项目组的专业形象也受影响。项目资源紧张的时候确实有人共用一套环境，我也这么干过，后来被业务方吐槽过几次，还是老老实实把环境隔开了。环境分离的本质不是技术问题，是信任问题——UAT环境必须让业务方感到可靠、可控。

5.3 UAT的缺陷要不要当天修

这个问题没有绝对答案，我的经验是分级处理：

• 阻断性缺陷，比如核心流程走不通、数据计算错误、部分用户完全无法登录，必须当天修复，当天发布到UAT环境，修复后再请业务方验证
• 一般缺陷，比如某个非核心页面显示异常、某个报表字段排序不对，可以进缺陷库，每天开例会挑选当天可修复的来处理，但上线前必须给出明确的处理结论
• 极低优先级的小问题，比如文案拼写、提示语不统一、按钮间距，直接记录留待下个迭代，不要影响验收签字进度

最忌讳的是UAT期间大动核心逻辑。UAT阶段测试的范围和深度通常没有SIT那么全面，如果在这个阶段改核心代码，很容易引入新的回归问题，而项目组往往已经没时间再做一轮完整的全量回归了。所以我在团队里定的规矩是：UAT期间的非阻断性优化一律不做，只做缺陷修复；缺陷修复也要评估改动范围，改动面超过两个模块的，必须补一轮冒烟回归再发UAT环境。

5.4 进入退出标准怎么写才不会被钻空子

SIT和UAT都应该有明文的“进入条件”和“退出条件”。写得具体，后面扯皮的概率就小。SIT进入条件一般是：开发完成、自测通过、测试用例评审通过、代码和依赖包部署到SIT环境；SIT退出条件一般是：测试用例执行完成、所有阻断和严重缺陷全部修复并回归通过、遗留缺陷经产品确认可以接受。

UAT进入条件一般是：SIT核心回归通过、UAT环境就绪、UAT测试数据和账号准备完毕、UAT脚本评审通过；UAT退出条件一般是：业务方验证所有UAT用例通过、无阻断缺陷、遗留问题三方确认处理方案、业务方签字确认。

很多项目组写退出条件，写着写着就变成“测试通过”“验收通过”这种空话，等于没写。上线的标准必须是可验证的、可检查的，比如“支付全链路通过率达到100%”“导出功能数据量级达到50万行验证无OOM”，这样后面即使出了争议，翻出当时的退出条件就能一目了然。我见过最规范的团队，连“遗留缺陷清单要附上影响评估和上线预案”都写进退出标准里，这种做法很值得借鉴。

6. UAT之后还有一道关：灰度发布与线上验证

6.1 为什么UAT通过后还要灰度

很多人以为UAT通过就能直接全面上线，其实中间还差一个灰度发布。UAT再怎么模拟真实业务，它毕竟不是生产环境，测试数据规模、真实用户并发、第三方系统的真实响应时间、网络链路延迟，都会跟线上有差异。就拿并发来说，UAT环境里同时在线操作的可能就几个业务方的人，而线上一个普通促销活动就能带来上百倍的并发请求，缓存、数据库连接池、网关限流这些在高压力下的表现，UAT阶段根本看不到。

所以比较稳妥的做法是金丝雀发布：先让5%到10%的流量切到新版本，观察几小时或者一两天，核心错误率、接口响应时间、订单成功率这些指标没问题，再逐步扩大到50%、再到100%。灰度期间项目组的监控工具要开全，日志要查得勤，一旦发现指标异常，立刻回滚到旧版本。UAT只能证明业务方“认可”了这个系统，灰度才能证明系统“扛得住”真实的生产环境。

6.2 线上验证和UAT的差异

线上验证通常由开发或测试团队盯着监控系统来确认，关注点不再是“功能有没有”，而是“稳定性如何”。UAT业务方手工操作每个页面，线上验证则是看接口报错率、错误日志、核心指标报警。我在实际项目中会列一个线上验证检查单，包含关键接口成功率、页面白屏率、数据库连接池使用率、慢SQL数量、第三方支付回调成功率、移动端JS报错率等，每项设定阈值，超过阈值立刻告警并准备回滚。

这个检查单最好在UAT开始前就结合系统压测的结果来准备，而不是上线之后临时想。比如一个接口在压测环境下支持1000 QPS，线上验证时如果发现实际只有200 QPS就报错，那说明代码在性能上还没准备好，直接关掉灰度查问题。线上验证和UAT还有一个很重要的差异：UAT是业务方主观判断“行不行”，线上验证是数据驱动判断“稳不稳”。前者人说了算，后者指标说了算。

6.3 大版本和小迭代的UAT策略差异

最后说一下不同项目规模下的UAT策略。大版本或者核心系统改造，UAT要安排多轮、扩大业务方参与范围、做完整的端到端业务演练，有条件的话可以做UAT环境和回归环境的双环境并行验证；小迭代、修复型版本，UAT可以简化为业务方登录UAT环境跑一遍主流程加受影响模块，签字上线即可。越小的变更越不要过度流程化，否则全员会在流程上花费大量时间，反而挤占了真正该留给测试和开发的精力。

我在团队里推广的做法是：凡是改动范围涉及核心主流程的版本，UAT必须完整执行，比如下单、支付、退款、对账这些一条龙流程全部走一遍；凡是只改文案、样式、非核心后台页的版本，UAT做冒烟验证加产品验收，签字放行。这套做法执行下来，既保证了变更质量，又没把团队淹没在流程里。

说来说去，SIT和UAT并不是多么高深的概念，本质上是软件交付过程中两道分工不同的质量关卡：SIT替开发和测试团队守护技术质量，UAT替业务方守护业务价值。我个人的实际体会是，这两个词被频繁挂在嘴边，很大程度上是因为它们代表着两个最容易让项目延期的“关键节点”。如果你们团队现在还是靠喊“大家抓紧测一下”来推进项目，我强烈建议把SIT和UAT的进入退出条件、环境策略、缺陷分级处理规则都明文定下来。哪怕只是一个十几个人的小项目，把这套机制跑顺之后，你的上线效率和上线后的安心程度都会上一个台阶。