企业官网建设流程全解析

做软件测试这行，几乎每场面试、每次需求评审、每个上线前的临时群里，都会有人甩出这四个缩写：UT、IT、ST、UAT。新人听完一脸问号，工作三五年的老人有时候也会含糊——尤其是IT和ST，边界一模糊，就容易互相甩锅。我见过最典型的场景是：开发说"我单测都跑过了，你测出问题就是你环境不对"，测试说"你这属于集成阶段的问题，找我干嘛"，最后业务方在UAT里点出一个明显跑不通的流程，大家一起沉默。这篇就把UT（单元测试）、IT（集成测试）、ST（系统测试）、UAT（用户验收测试）这四个层级掰开揉碎讲清楚：它们各自管什么、不管什么、谁来干、什么时候干、干到什么程度算过关。不管你是刚入行的测试新人、写代码但懒得写单测的开发，还是需要组织验收的产品和业务方，看完至少能搞明白一件事——这个问题到底该在哪个环节被发现，以及为什么它偏偏漏到了下一个环节。

1. 四个层级的整体设计与职责划分

1.1 为什么要分层：从盖楼这件事说起

我习惯用盖楼来类比测试分层。单元测试是检查每一块砖、每一根钢筋的标号和强度，砖没烧透，后面砌得再漂亮也是危房；集成测试是把砖砌成墙、把墙拼成房间，重点看接缝处漏不漏水、门框和墙体对不对得上；系统测试是整栋楼交付前的全面验收，水、电、气、消防、承重一起跑，看这栋楼能不能正常住人；UAT则是业主拿着钥匙进门，按照自己的生活习惯走一圈——厨房动线顺不顺、插座位置够不够、楼下吵不吵。这四层最核心的区别在于测试对象和关注点的切换：从单个代码单元，到模块之间的协作，到完整系统的行为，再到真实业务场景的可用性。

搞混这四层，最常见的后果就是职责错配。比如把本该在UT阶段拦住的空指针异常放到ST阶段才发现，排查成本会从几分钟变成半天；反过来，如果在UAT阶段还在纠结某个工具类的方法写得对不对，那就是拿大炮打蚊子，浪费业务方的时间。分层不是为了显得流程正规，而是因为缺陷的发现成本随着阶段后移呈指数级增长，业内常被引用的一个经验估算是：同一个缺陷在需求阶段修掉成本记作1，编码阶段约6，测试阶段约15，上线之后可能要100。这个数字不一定精确，但方向是对的——越往前拦，越省钱。

还有一层现实原因：不同层级解决的是不同角色的信任问题。开发对代码质量负责，交付的是"我这部分逻辑是对的"；测试对系统质量负责，交付的是"整体拼起来是能用的"；业务方对业务价值负责，交付的是"这玩意儿真的解决我的问题"。四个层级其实就是四份不同视角的确认书，缺一份，上线之后就少一道保险。

1.2 UT / IT / ST / UAT 的定位对照表

光讲概念容易飘，直接上表更直观。下面这张表是我在团队里做新人培训时用的精简版，涵盖谁执行、测什么、依据什么、什么阶段、产出什么：

需要特别提醒一个高频混淆点：IT在软件测试语境下指的是Integration Testing，但很多团队里IT部门指的是信息技术部门，开会时说"这个走IT测试"经常产生歧义。为了避坑，我们内部一律说"集成测试"或者干脆用联调代替，写文档时也会标注清楚。另外ST经常和SIT（System Integration Testing，系统集成测试）混着用，严格说的话SIT更偏系统间的集成验证，ST更偏系统自身的整体验证，但实际项目里两者常常合并执行，不必强行切分，关键是把"测什么"说清楚，而不是纠结缩写。

还有一个容易漏掉的：冒烟测试和回归测试不属于这四层中的任何一层，它们是"横切"的活动。冒烟测试是提测前的准入检查，跑通主干流程才允许进入ST；回归测试是在修完缺陷之后，回头验证老功能没被改坏，几乎每个层级都在用。把它们和四层混为一谈，是新人最常犯的认知错误之一。

1.3 分层背后的成本账：别让缺陷坐电梯下楼

我在实际项目里做过一个粗糙的统计，把某版本的全部缺陷按发现阶段归类，结果很说明问题：约55%的缺陷在UT阶段由开发自己发现并修掉，25%在IT联调阶段暴露，15%落在ST阶段，剩下5%逃到了UAT甚至线上。而这5%逃逸缺陷，占用了整个版本大约30%的返工工时。这就是缺陷成本的直观体现——数量上只占一小撮，处理成本上却是一大块。

为什么会这样？因为越往后，一个缺陷牵动的上下文越多。UT阶段发现一个分支没覆盖，改两行代码、跑一遍测试，五分钟搞定；ST阶段发现同样的问题，要先确认是不是环境配置导致的，再确认是不是数据构造有问题，然后提单、复现、定位、修复、回归，一轮下来可能要半天。到了UAT阶段，还叠加了业务方的时间成本，人家是抽空来验收的，你让人家等着你修bug再验一遍，体验极差。

所以分层测试设计的核心原则不是"每层都要测一遍"，而是"每类问题在最便宜的那一层被拦住"。逻辑错误归UT，接口契约和数据传递归IT，跨模块业务流程和系统级质量属性归ST，业务规则和操作习惯归UAT。分清楚这个映射关系，比背四个缩写有用得多。反过来说，任何一个层级如果长期发现不了自己该负责的那类问题，就说明这个层级要么形同虚设，要么测试设计有系统性漏洞，需要专门复盘。

注意：分层不是越细越好。我见过一个团队把测试分成七层，光准入文档就写了十几页，结果开发不愿意写单测、测试不愿意做联调，最后所有测试都堆到ST阶段一次性爆发。层级的价值在于"责任清晰"，不在于"数量多"。

2. 逐个拆解：每个层级的核心细节与实操要点

2.1 UT（单元测试）：代码的螺丝级质检

单元测试的本质是"隔离验证"——把被测单元从它的依赖里剥出来，只验证它自己的逻辑对不对。剥依赖的手段就是桩（Stub）和模拟对象（Mock）：桩负责给出预设的返回值，Mock负责记录调用行为并验证交互。举个具体例子，一个运费计算函数依赖了会员等级查询接口，写单测时就把这个接口Mock掉，直接让它返回"是会员"或"不是会员"，只测计算逻辑本身。

下面是待测函数和对应的单测示例，用Python写的，逻辑很朴素：基础运费加上重量和距离的系数，会员打九折。

# freight.py def calc_freight(weight_kg, distance_km, is_member=False): if weight_kg <= 0 or distance_km <= 0: raise ValueError("重量与距离必须为正数") base = 10 + weight_kg * 2 + distance_km * 0.5 if is_member: base *= 0.9 return round(base, 2)

# test_freight.py import pytest from freight import calc_freight def test_normal_case(): # 10 + 2*2 + 100*0.5 = 64.0 assert calc_freight(2, 100) == 64.0 def test_member_discount(): # 64.0 * 0.9 = 57.6 assert calc_freight(2, 100, True) == 57.6 @pytest.mark.parametrize("w,d", [(0, 10), (-1, 10), (5, 0), (5, -3)]) def test_invalid_input(w, d): with pytest.raises(ValueError): calc_freight(w, d)

这里有两个细节值得说。第一，边界值一定要覆盖，weight_kg <= 0这种判断，0和负数必须各测一次，光测正常值等于没测异常分支。第二，浮点数比较不要用==去卡死，我用round保留了两位小数，代价是精度损失，好处是断言稳定；如果业务要求更高精度，应该用pytest.approx或者改用整数分单位。

写单测有几个公认的原则，业内常说的F.I.R.S.T：快（Fast，全量跑完应该在分钟级）、独立（Independent，用例之间不能有顺序依赖）、可重复（Repeatable，任何机器任何时间跑结果一样）、自验证（Self-validating，结果只有通过和失败两种，不能靠人看日志判断）、及时（Timely，跟着代码一起写，不是事后补）。这五条里最容易违反的是"独立"——我见过大量单测用例共享同一个数据库连接或者静态变量，单独跑全绿，一起跑就随机红，排查起来极其痛苦。

关于覆盖率，我给的实操建议是：新增代码的行覆盖率门槛设80%，核心业务模块（涉及金额、权限、状态机的）设90%，历史遗留代码不要一刀切要求，按模块逐步补齐就行。覆盖率是发现"哪里没测"的探针，不是质量评分——见过太多为了刷覆盖率而写的断言为空的用例，那种覆盖率毫无意义。

实操心得：Mock别滥用。如果一个类写了十几个Mock才能测通，八成是这个类的职责太重、依赖太杂，这时候该动的是设计，不是测试。我个人的判断标准是：单测里Mock数量超过3个，就停下来想想是不是该拆了。

2.2 IT（集成测试）：模块之间的接口体检

单元测试全绿，不代表系统能跑。每个模块自己逻辑都对，但A传过去的是"用户ID字符串"，B期望的是"整数"，这种问题只有拼起来才暴露。集成测试要盯的就是这些接缝：接口的入参出参格式、数据类型、字段必填性、错误码约定、事务边界、超时与重试、消息的顺序和幂等。

做集成测试有两个层次。浅一点的是"接口能通"——调一次，看返回码是不是200，字段有没有缺。深一点的是"契约稳定"——消费者和提供者对同一个接口的理解必须一致，这就是契约测试的思路。具体做法是消费者侧把期望的请求和响应结构固化成契约文件，提供者侧在流水线里拿这份契约去校验自己的实现，一旦提供者改了字段名或者把某个字段从必填改成可选，契约校验会直接失败，在联调之前就把问题卡住。这个思路在微服务拆得比较碎的团队里价值极高，能省掉大量"上线才发现调不通"的事故。

举个具体的坑。某次做订单和库存的集成，接口文档写的是库存扣减成功返回code: 0，失败返回code: 1。开发实现时用了一个通用响应包装，成功返回code: 200，失败返回code: 500。单测各自都过，因为开发是照着自己的实现写的断言。联调时订单侧判断code == 0才继续，结果每次扣减都判定为失败，订单全部回滚，但库存实际已经扣了，造成数据不一致。这个问题的根因不在代码，在于没有一份双方共同认可并且会自动校验的契约。

集成测试里还有几个必须覆盖但经常被忽略的点，我列在下面：

• 空值和缺省：字段传null、传空字符串、整个字段不传，三种情况的行为是否一致
• 幂等：同一个请求重复提交两次，结果应该是扣一次还是扣两次，必须有明确约定并验证
• 超时与重试：下游响应慢的时候，上游是等待、降级还是直接失败，重试会不会造成重复处理
• 事务与补偿：跨服务的操作没有分布式事务时，中间失败靠什么回滚
• 并发：同一份数据被两个请求同时修改，最终状态是否可预期

这些点用单测基本测不出来，用系统测试又太靠后（出了问题定位成本高），放在集成测试阶段做是最经济的。

2.3 ST（系统测试）：整个系统的整车路试

系统测试是把整个系统当成一个黑盒，按照需求规格说明书去验证它作为一个整体是否满足要求。这个阶段测试人员不关心内部怎么实现，只关心输入什么、输出什么、在什么条件下输出。ST覆盖的范围比前两层宽得多，除了功能，还要包括性能、安全、兼容性、可靠性、易用性这些非功能属性。

功能测试的用例设计方法就那么几套，但用得好不好差别很大。等价类划分是把输入空间切成若干类，每类取一个代表值，避免穷举；边界值分析是专挑分类的边界上取值，因为绝大多数的逻辑错误都发生在边界；场景法是按照用户的真实操作路径串起来，验证跨功能的流程；判定表适合处理多个条件组合的业务规则，比如优惠券的叠加规则，用正交表可以把组合数量从几百降到几十。这几种方法不是互斥的，实际写用例时通常是先按场景切大块，块内再用等价类和边界值细化。

系统测试阶段最容易出问题的地方，其实不是用例写得不够多，而是环境不一致。测试环境的配置、数据量、网络延迟和生产差得远，测出来的结论就没法迁移。比如测试环境数据库只有几万条数据，查询都是毫秒级，上了生产几百万条数据，同一条SQL直接超时。我的做法是尽量让测试环境的关键参数向生产看齐——数据库量级至少到生产的十分之一，中间件的超时配置、线程池大小必须和生产一致，网络延迟能模拟就模拟。做不到完全一致，至少要在测试报告里明确写出差异项，让上线评估的人心里有数。

性能测试放在ST阶段做是合理的，因为它必须依赖完整的系统环境。压测不是随便跑个脚本看TPS就完事，得先明确三件事：压测目标是什么（是验证容量、找瓶颈，还是做稳定性浸泡）、业务模型是什么（各个接口的调用比例要和真实流量分布接近）、通过标准是什么（响应时间的P95、P99卡在多少，错误率低于多少）。我见过最多的情况是只压了登录接口，压出一个漂亮数字，然后上线被下单接口打垮——因为真实场景里下单才是重头戏，登录请求占比连5%都不到。

注意：ST阶段的准入必须有硬门槛。主干流程冒烟不通过就不该进入正式测试，否则测试人员会把大量时间浪费在"环境不通""数据没准备好"这类非缺陷问题上，最后压缩的是真正的测试时间。

2.4 UAT（用户验收测试）：业务方的交房验房

UAT和前三个层级有本质区别：执行者不是技术团队，而是业务方或最终用户。它的目的不是找代码bug，而是确认"这个东西按我们的业务方式能不能用起来"。所以UAT的用例不应该是测试人员写的那套功能用例，而应该是业务场景——一个真实的业务人员，拿着真实（或脱敏后接近真实）的数据，从头到尾把他日常要做的事做一遍。

举个具体的对比。ST阶段的用例可能是"点击查询按钮，列表返回符合条件的数据，分页正常"；UAT阶段的场景则是"每月初我要导出上个月的结算单，按客户维度汇总，核对总额和财务系统对得上，然后发给对接人"。前者验证功能，后者验证业务闭环。很多在ST阶段全绿的系统，在UAT阶段会暴露出大量"功能都对，但用起来不对"的问题：字段顺序不符合业务习惯、必填项太多导致录入效率低、导出格式财务那边打不开、审批流的节点顺序和实际组织架构不一致。这些问题严格来说不算缺陷，但直接影响系统能不能被真正用起来。

UAT的执行有几个关键前提，缺一个就容易流于形式：

验收标准最好在需求阶段就写清楚，用Given-When-Then的格式能把模糊地带压到最小。比如"给定一个信用额度为5000的客户，当订单金额达到5200时，系统应拒绝下单并提示可用额度不足"，这种写法业务方能看懂，测试能直接转成用例，开发也不会理解偏差。反过来，如果验收标准写的是"系统应支持信用额度控制"，那UAT就必然变成扯皮现场，因为每个人心里的"支持"定义都不一样。

UAT还有一种变体值得提一下：灰度或试运行。有些系统的影响面太大，直接让全体用户切换风险高，就先放一小部分用户进来用，边用边收集问题。这种做法本质上把UAT的周期拉长了，但换来的是风险可控。我个人比较推荐在核心业务系统上采用这种方式，代价是上线流程会复杂一些，需要设计好灰度范围和回滚方案。

3. 落地实操：从环境到准入准出的一整套流程

3.1 各层级的准入准出标准怎么定

流程能不能跑起来，关键看准入准出卡得清不清楚。准入是"达到什么条件才允许进入这个阶段"，准出是"达到什么条件才算这个阶段完成"。这两个标准如果含糊，测试就会变成无限期的等待和扯皮。下面这套标准是我在几个团队里反复调整后固化下来的版本，可以直接拿去改改用：

这里有两个数字值得单独说。单测全量执行时间控制在10分钟内，是因为超过这个时长，开发者就会倾向于不跑或者只跑自己改的那部分，覆盖率数据随之失真。如果超时，优先做的是拆分测试集、把慢用例（比如依赖外部资源的）单独标记，而不是降低覆盖要求。另一个是P0/P1缺陷清零这个准出线，现实中经常被"这个bug影响面很小"给突破，我的经验是这条线一旦松一次，后面就再也守不住了，宁可延迟上线也别开口子。

缺陷等级的划分也要说清楚，不然"清零"就是空话。我一般这么定义：P0是核心功能不可用或数据错误，P1是主要功能受阻但无数据风险，P2是次要功能异常或体验问题，P3是文案、样式类的瑕疵。P0必须当天修完，P1在当前版本内修完，P2排期处理，P3看情况。等级划分的依据是影响面和数据安全，不是开发觉得好不好改。

3.2 一个完整版本的时间分配参考

纯讲理论容易虚，我把一个典型的两周迭代版本中各阶段的投入比例摆出来，这个比例是从实际项目里统计的，不同团队会有出入，但量级可以参考：

这个比例里最容易被压缩的是用例设计和UT，因为它们在时间线上不"显眼"。但恰恰是这两块压缩得越狠，后面ST和UAT阶段越容易失控。我做过对比，同样是两周迭代，提前把验收标准写清楚的版本，ST阶段发现的缺陷数量能少三成左右，而且基本都是真缺陷，不是需求理解偏差造成的"伪缺陷"。

还有一个实操建议：把UT的完成情况纳入代码提交的门槛，而不是靠人自觉。具体做法是在代码合并流程里挂一个检查，单测不通过或者增量覆盖率不达标就不允许合并。这件事一开始会有阻力，尤其是有历史包袱的模块，但坚持两三个迭代之后，开发者会习惯"写功能顺手写测试"的节奏，比事后补效率高得多。历史模块可以设一个白名单逐步清理，别想着一次到位。

3.3 缺陷逃逸的复盘怎么做才有用

每个版本上线之后，我都建议做一次缺陷逃逸复盘，只看一件事：哪些缺陷本该在更早的层级被发现，为什么没发现。这个复盘的价值远高于统计"这个版本提了多少bug"。

复盘的时候按这个维度归类：本该UT发现的（逻辑分支错误、边界处理缺失）、本该IT发现的（接口字段不一致、异常传播错误、幂等缺失）、本该ST发现的（跨模块流程断裂、性能不达标）、本该UAT发现的（业务规则不符、操作习惯冲突）。归完之后看分布，如果某个层级持续"漏"，就是系统性问题的信号。

我遇到过两种情况，印象很深。一种是UT阶段几乎零发现，但IT阶段缺陷爆炸，查下来是开发写单测只测正常流程，异常分支全部跳过，覆盖率数字很好看，但都是"快乐路径"。另一种是ST阶段发现的全是接口字段问题，说明集成测试根本没做契约校验，全靠人工联调碰运气。这两种问题的解法完全不同：前者要调整单测的用例设计规范，强制要求异常分支和边界值；后者要把契约校验接进流水线，变成自动化检查。不做归因，笼统地说一句"要加强测试"，等于什么都没做。

4. 常见问题与排查技巧实录

4.1 高频疑问速查表

这四个缩写被问得最多的问题，我整理成一张表，遇到争论直接对照：

4.2 各层级最容易踩的坑

UT的坑：为了覆盖率而测试。最典型的表现是先写测试再写实现，或者写完实现之后对着代码一行行补断言，测的全是"这行代码执行了"，而不是"这个行为符合预期"。判断方法很简单：把被测函数里的某一行逻辑改错（比如把>=改成>），跑一遍单测，如果测试还是全绿，说明这批用例的断言没有真正校验行为，等于白写。我建议新写的核心模块至少做一次这样的"变异检查"，成本很低，效果立竿见影。

IT的坑：只测成功路径。大部分团队的联调就是把主流程跑通，一旦返回200就认为集成完成。但线上事故里，接口相关的故障绝大多数出在异常路径——下游超时了怎么办、返回了非预期格式怎么办、重试之后数据重复了怎么办。这些必须在集成阶段就用工具模拟出来，比如用抓包工具篡改响应、用延迟注入模拟超时，验证上游的兜底逻辑是否真的生效。

ST的坑：测试环境与生产差距过大。前面提过，这里再强调一次数据量的问题。测试库里几千条数据跑得飞快，不代表生产环境几百万条也行。索引缺失、慢查询、分页深度过大这些问题，只有数据量上去了才会暴露。条件允许的话，ST阶段至少做一次接近生产量级的数据验证，尤其是列表查询、报表统计、数据导出这几类功能。

UAT的坑：把验收变成演示。有些团队的做法是业务方坐在会议室看测试人员点一遍系统，然后问一句"没问题吧"，对方点头就签字。这不叫验收，叫观看。真正的UAT必须让业务方自己动手操作，用他们自己的业务数据，走他们日常的流程。我见过一个案例，演示的时候一切正常，业务方上手第一天就发现批量导入的模板列顺序和他们现有表格不一致，导致几千条数据全部导入失败——这种问题演示永远发现不了。

4.3 几个我从实践里攒下来的小技巧

第一个，把验收标准提前写进需求文档。这件事听起来是产品经理的活，但测试人员主动去推动收益最大。具体做法是需求评审时，测试针对每个核心功能追问一句"这个功能做到什么程度算做完"，把答案用Given-When-Then固化下来。这个过程会逼出大量模糊需求，早发现早澄清，比开发完了再吵强得多。

第二个，给每个缺陷标注"应该在哪个阶段被发现"。提单的时候多花十秒钟选一个标签，积累一两个版本之后，就能画出各层级的缺陷分布图。这张图比任何汇报都有说服力，能直接指出流程里最薄弱的一环。我们团队就是靠这张图发现集成测试形同虚设，然后才推动把契约校验接进流水线的。

第三个，UAT之前先自己走一遍。别把业务方当第一轮用户，测试人员按照UAT的剧本先完整走一遍，把明显的流程阻塞、数据准备问题、权限配置问题提前清掉。这一步大概花半天，但能显著提高UAT的效率，也避免业务方一上手就卡在登录不上这种低级问题上，白白消耗信任。

第四个，环境差异要显式记录。做不到测试环境和生产完全一致是常态，但差异项必须写进测试报告，比如"测试环境数据库为单节点，生产为三节点集群""测试环境未开启缓存，生产开启"。这些差异直接决定了哪些测试结论可以迁移、哪些需要在上线后重点观察。我现在的习惯是每个版本出一张环境差异清单，跟测试报告一起归档，上线出问题时第一时间对照，能省掉很多猜测。

第五个，别迷信层级齐全。四个层级都有，不代表质量就好。见过流程文件写得极其完备、每个阶段都有签字确认的团队，线上事故照样不断，因为每一层都在"走过场"。真正决定质量的是每一层有没有认真对待自己该负责的那类问题，而不是有没有这个阶段。反过来，有些小团队只做UT和ST两层，但UT写得扎实、ST用例设计到位，质量反而稳。层级是工具，不是目的，把这句话记住，很多流程上的纠结就能放下了。