网页测试和网站测试，在我这些年做测试的过程中，被混着讲的情况见过太多。刚转测试的同学很容易以为网页测试就是打开页面点点点，网站测试就是把所有页面过一遍。如果只这么理解，最后的测试方案多半是一张没有重点的检查表，既漏了页面内部的交互细节，也漏了页面之间的跳转关系。这篇是软件测试基础理论体系学习的第9篇，我想把网页测试和网站测试分别测什么、两者的关系怎么理清、真正落地时按什么顺序做什么，用一篇讲明白。适合刚入行的测试同学，也适合做过一些项目但还没系统梳理过这套逻辑的人。
1. 网页测试和网站测试：先弄清“测哪个”
1.1 网页测试的关注点：页面级功能与表现
网页测试的对象，是一个“独立页面”或者“一个功能页面”，关注的是这个页面内部的一切表现是否正常。说得再直白一点，就是用户在这个页面上能看到的元素、能完成的交互、以及交互背后调用的接口，都要对得上。
实际操作时，我会把网页测试拆成下面几个维度来检查：
- 页面元素是否完整：标题、正文、图片、图标、按钮、弹层、页头、页脚，该有的有没有，位置准不准。
- 交互是否响应：点击、悬浮、滚动、拖拽、键盘输入，包括不同状态下的按钮是否可点击。
- 表单是否可用：输入校验、提交按钮、成功提示、失败提示、提交后跳转。
- 页面资源是否加载：样式、脚本、图片、字体文件是否都成功加载，有没有404资源。
- 页面内接口是否正确：交互触发后，对应的接口返回了什么，前端有没有正确处理响应。
这里最容易踩的坑是，页面“看起来成功”但接口实际报错。我之前在测一个登录页面时，点击登录后按钮变成了“登录中...”，随后弹了“登录成功”，页面也正常跳转了，看起来一切正常。结果跳过去之后用户信息是空的，查了半天发现登录接口返回的其实是500，前端只判断了响应状态是不是成功，没有校验接口返回体里的业务状态码，直接把失败当成功处理了。这种问题只看页面表现是发现不了的，一定要同时盯着接口看。这也是为什么我坚持在做网页测试时，把浏览器开发者工具的网络面板一直开着。
1.2 网站测试的系统级视角：从首页到全站
如果说网页测试是看“每一个页面内部对不对”，那网站测试看的就是“整站把页面串起来之后对不对”。网站测试关注的核心是页面与页面之间的关系，以及用户在整个站点中穿行的体验。
具体来说，包括这些点：
- 导航结构是否清晰：主导航、频道导航、面包屑、返回入口是否让用户知道自己“在哪、能去哪、怎么回去”。
- 链接是否有效：站内所有可点击的链接，能不能按预期到达目标页面。
- 信息架构是否合理：栏目划分是不是符合用户直觉，层级是不是太深，重要的内容是不是暴露在足够近的位置。
- 跨页流程是否顺畅：登录后跳转、支付后回跳、参数传递、状态保持，每一步都不能断。
- 全局机制是否一致：整站的页头页脚、Logo、站点地图、404页、搜索入口是不是统一。
网站级的问题最典型的就是“单页没问题，一跨页就出事”。我之前测过一个资讯站，每个频道页都能正常打开，文章详情页也能正常打开，但某篇文章详情页里点击“返回首页”，却跳到了404。后来定位到是文章页模板里首页链接写成变量占位符，而模板渲染时没替换掉，导致整类页面都带病。这种问题只测单个页面根本发现不了，必须站在全站维度去遍历、去点跳转。
再比如分页场景：从列表页翻到第3页，点进详情页，再按浏览器后退，结果回到的是第1页。页面本身没问题，但“点击分页后没有把当前页码状态更新到URL参数里”这种状态管理问题，就是典型的网站级缺陷。
1.3 两者的关系：先页面后网站，还是先网站后页面？
我的习惯是，两层都做，但分开设计用例、分开执行。网页测试保证“每个点是对的可用的”，网站测试保证“点与点之间的线是通的可达的”。
判断一个问题属于网页级还是网站级，我常用一个简单标准：这个操作从触发到结束，是不是跨页面的。如果一次操作从开始到结果都在同一个页面内完成，属于网页级；如果操作过程中要经过多个页面、需要传递参数或者保持状态，那就是网站级。修改个人资料通常在一个页面内完成，属于网页级；找回密码必然要经过填写账号、接收验证码、重设新密码、重新登录，这个多页面链路就是网站级。
两张维度对比可以看这个表格：
| 对比项 | 网页测试 | 网站测试 |
|---|---|---|
| 测试对象 | 单个页面或单个功能模块 | 整站页面集合以及跨页面流程 |
| 核心关注点 | 页面元素渲染、交互响应、表单逻辑 | 导航结构、链接有效性、跨页状态 |
| 典型缺陷 | 按钮失效、样式错乱、接口响应误判 | 断链、跳转错误、登录态丢失 |
| 建议测试方式 | 逐页面功能测试并校验接口 | 全站链接遍历加端到端流程测试 |
实际排测试计划的顺序，我一般先做网页级的页面功能测试，保证单点可用；再做网站级的全站遍历和跨页流程测试，保证链路可达；最后回归时两层一起过。这样每一轮发现的问题归属都很清楚，开发也好复现。
2. 测试前要做的三件事：梳理范围、设计用例、选工具
2.1 用URL清单和功能地图圈定测试范围
网页/网站测试做得不够扎实，很多时候不是执行不到位，而是测试范围一开始就没圈全。我会在动手前先把需求文档、站点地图、路由配置全部拿过来，把每个模块、每个页面、每个核心操作整理成一张“功能地图”。
我自己常用的底表格式大致是这样的：
模块：内容详情页 URL示例：/content/detail?id=xxx 核心操作：阅读正文、查看附件、分享、收藏 依赖接口：内容详情接口、收藏接口 优先级：P0这张表有两个作用。第一，它是测试执行的底表，测一个勾一个，不漏页面；第二，它也是后面做全站链接遍历的基础数据。等到网站测试阶段，我会把里面的URL全部抽出来跑一遍链接有效性检查，这个底表直接就能用。
除了需求里明确的功能页面，我还会把一些容易被忽略的“状态页面”单独列出来：404错误页、搜索无结果页、列表空数据页、权限不足页、接口异常时的错误页。这些页面平时没人提，但用户一旦遇到，体验影响很大。列表页做了空数据展示，和直接白屏，完全是两个效果。
范围梳理完成后，还可以做三个简单自检：
- 所有入口都覆盖了吗？包括首页、导航、搜索、外部分享链接、二维码扫码进入的页面。
- 所有用户角色都考虑了？游客、注册用户、管理员看到的范围不同，权限边界要测。
- 所有操作路径都有吗？不仅是从入口正常走到出口，还包括从中间状态进入页面的情况。
2.2 测试用例分级：P0/P1/P2怎么排
用例设计的第一步不是把每一个可能的情况都写上，而是先分级，否则执行时什么都想测，结果什么都测不细。
我参考的标准是：
- P0：核心路径和基本可用性。首页能打开、登录能成功、核心业务操作能完成。P0的问题不能留到上线。
- P1：重要功能但存在替代路径。比如搜索结果排序、列表筛选、站内通知。P1有缺陷可以带病上线，但必须尽快修复。
- P2：视觉细节、文案、边缘交互、浏览器细节。这类问题可以排期处理。
分级是策略，用例设计本身还是要做到正向、反向、边界都有。拿一个常见的密码框来举例，如果规则是6到20位，至少需要准备这些输入：空值、5位、6位、20位、21位、全数字、含中文、含特殊字符、前后带空格、超长重复字符。每一个输入都要有对应的期望结果，不能只写“提示错误”或者“提示成功”。
一条完整的用例字段，我习惯至少包含：用例ID、所属模块、前置条件、操作步骤、输入数据、期望结果、优先级。这样执行的人不会产生歧义，也方便后续复用和自动化转换。
2.3 工具选型：为什么先别急着上自动化
很多测试同学刚接触网页测试时，第一反应是“这么多样例，我是不是应该写个自动化脚本跑”。我的建议是，先别急，手动测试配合浏览器开发者工具和一份抓包工具，已经能完成大部分网页和网站测试工作。
我这么说是因为，手动测试阶段最重要的不是“省人力”，而是“理解现象背后的原因”。点击一个按钮没反应，到底是事件没绑定、接口没返回、还是前端JS报错？这些信息在浏览器控制台和网络面板里一眼就能看到。抓包工具则能看清请求参数、Cookie、重定向、返回状态码，把前端行为和后端能力对应起来。
自动化更适合放在这几种场景：用例已经稳定、每个版本都要回归执行；有大量重复且组合多的数据验证；需要多浏览器、多设备组合反复覆盖。如果只是验证页面能不能打开、按钮能不能点，手测比写脚本快得多，也灵活得多。
还有一个操作习惯想强调：我在提交问题前，都会先用无痕窗口加清缓存的方式重新做一次复现。很多“偶发问题”其实是浏览器缓存旧资源导致的假象，做完这一步再提缺陷，开发不会再跑来问你“到底稳不稳定”。
3. 核心测试项拆解：链接、表单、兼容性和性能
3.1 链接有效性：最容易漏掉又最容易暴露的坑
链接有效性是全站测试里性价比最高的检查项，因为它门槛低，影响却很大。用户点了一个链接，结果404了，对站点的信任感基本瞬间归零。
链接问题常见的来源有几个：
- 相对路径和绝对路径写错，导致页面在子目录下时链接指向错误。
- 域名变更后旧地址没有做跳转，老链接全部变成死链。
- 地址大小写不匹配，服务端区分大小写时直接404。
- 动态链接参数拼接错误，比如在处理包含特殊字符的搜索词时没有做URL编码。
手动抽查只能覆盖一部分，更可靠的方式是批量扫描一遍全站链接。在测试环境里，可以把所有页面URL收集到一个列表，循环请求并检查状态码。比如这样一个简单的思路：
while read -r url; do code=$(curl -o /dev/null -s -w "%{http_code}" "$url") if [ "$code" != "200" ]; then echo "$code $url" fi done < urls.txt这里要提醒一句：扫描结果不能直接照单全收。有些链接返回404是设计预期，比如故意隐藏的下载资源；有些站点对爬虫请求和真实浏览器返回的内容不一样，批量工具扫出来正常，人工一访问却报错。所以批量扫描之后，对高优先级链路做人工复核是必须的。
处理扫描结果时，我习惯先按“链接所在模板”分组。同一个导航模板里的链接写错了，会导致全站几十个页面同时出问题；而修好这一处模板，几十处问题同时消失。这个归类思路能把“零星缺陷”升级成“公共缺陷”，对开发修复效率帮助很大。
3.2 表单测试：从校验规则到提交结果全链路
表单是网页功能里最藏坑的地方，核心原因有两个：第一，用户看到的“提交成功”不等于数据真的写库成功；第二，前端校验只是体验，后端校验才是安全底线。
一个完整的表单测试，至少覆盖这些点：
- 前端校验：必填项是否提示，邮箱、手机号、密码格式是否按规则校验，错误提示是否准确且不会遮挡输入框。
- 后端校验：绕过前端，直接调用接口提交非法数据，服务端能不能拒绝。
- 提交过程：点击提交后有没有防重复提交机制，按钮是否置灰，loading状态是否正常。
- 提交结果：成功后跳到哪里，失败后提示什么，用户输入的已有内容是否保留。
- 数据落库：刷新页面后数据是否还存在，数据库字段值和显示值是否一致。
- 特殊输入：脚本字符串、SQL片段、超长文本、emoji，都要测一遍。
前端限制格式是给正常用户输入做引导，不能被当成安全屏障。我在测试反馈功能时，发现页面限制留言最多200字，但我用抓包工具把请求里的内容改成2000字再发出去，后端没有做长度校验，照单全收了。结果列表页在展示这条留言时，整个卡片被撑爆，布局直接崩掉。这就是典型的前后端校验不一致问题。所以凡是前端校验过的规则，后端必须同样校验，测试时也要专门去“绕过前端”验证一遍。
3.3 浏览器兼容性和响应式：用矩阵表管理组合
浏览器兼容性测试最大的坑是“什么都想测，最后什么都没测透”。控制范围的方法，是先确定一个目标矩阵，而不是把所有浏览器所有版本都铺开。
一个基础的矩阵可以这样定：
- 桌面端：Chrome最新版、Edge最新版、Firefox最新版。
- 移动端：iOS Safari、Android默认浏览器或者主流内核浏览器。
- 设备尺寸断点：375px、768px、1024px、1440px。
在这个矩阵下，重点观察这些现象：
- 布局是否错位，文字是否溢出，图片是否变形。
- 弹窗、下拉菜单、悬浮层是否被遮挡，能否正常关闭。
- 交互是否失效，特别是事件绑定在不同浏览器下的差异。
- 键盘输入、粘贴行为、滚动行为是否有差异。
- 字体渲染差异导致的行高、间距不同。
响应式页面一般可以用开发者工具模拟设备尺寸来做基础判断，但我还是建议关键页面在真机上过一遍。模拟器不会反映出触摸操作的反馈、软键盘弹出后的遮挡、以及不同屏幕尺寸下的真实视口变化。我见过一个注册页面，模拟器里怎么看都没问题，一到真机，软键盘弹出来把提交按钮完全盖住，用户根本无法完成注册。
3.4 性能与安全基线：页面响应、并发和常见漏洞
这里说的性能，不是要求测试人员做一套完整压测平台，而是要做基础体验的校验，至少保证上线后的页面是可接受的。
我常用的几个基础指标：
- 首屏加载时间，建议3秒以内。
- DOMContentLoaded时间，建议1.5秒以内。
- 核心接口响应时间，建议500毫秒以内。
- 大图资源，建议超过200KB的图片都检查一遍是否压缩合理。
如果一个列表页在数据量只有几百条时很流畅，上万条数据就变卡，这时候要去分“是接口返回慢”还是“前端渲染慢”，这个能力在网页测试中很重要。观察点就是网络面板里接口返回耗时与页面渲染完成时间之间的差值。
安全方面，我会在常规测试里做几个基础动作：
- 登录错误次数有没有限制，防止无限暴力尝试。
- 密码等敏感字段在传输过程中是否加密。
- 输入框能不能注入可执行脚本，能不能挡住常见的注入内容。
- 未登录用户能否直接访问需要登录的接口。
- 错误页是否暴露了服务器路径、数据库信息、异常堆栈。
这些只是“基线检查”，完整的渗透测试需要专业安全团队，但测试人员如果能养成顺手扫一遍的习惯，对中小型项目来说已经能挡掉一大批明显问题。
4. 实操记录：完整走一轮网站测试的流程与判断
4.1 测试准备：环境、数据和用例清单
以某内容型网站项目的上线前测试为例，这个项目包含首页、栏目页、内容详情页、用户注册登录、搜索、个人中心。
第一件事是环境准备。我会确认测试环境地址可用，数据库已经完成最新版本的迁移，静态资源已经部署到对应目录，避免跑到一半发现页面样式引用的是旧版本。这些准备工作看起来琐碎，但没做好的话，后面所有测试结果都可能是无效的。
第二件事是数据准备。账号至少准备三种角色：游客、注册用户、管理员。列表数据要超过一页，最好有三页以上，这样才能测分页、测筛选组合。详情页要准备正常内容和异常内容，比如已下架的内容、被删除的内容，确保各种状态都有覆盖。搜索要准备有结果的词和没有结果的词。
第三件事是用例导出。按模块把已经设计好的用例清单导出，标好优先级，我习惯把P0单独放在一个Sheet里，先跑P0再跑其他。之前吃过一个亏，用例没分级，执行时从低优先级用例开始测，结果测了一下午，最核心的登录流程反而没有覆盖到。从那以后，冒烟测试和P0用例永远排在第一天。
4.2 执行过程：从抽查到全量验证
我的执行顺序大致是这样的：
- 冒烟测试：首页打开、注册登录、主要页面跳转，先确定没有阻断性问题，功能是可用的。
- 全站页面遍历：按URL清单逐页访问，记录所有打开异常、样式错乱、资源加载失败的问题。
- 模块功能测试：按照P0优先级，逐个模块做功能、边界、异常场景验证。
- 跨页流程测试：登录到搜索到详情到个人中心的完整链路，至少走两轮。
- 兼容性测试：在目标矩阵上复查核心页面。
- 收尾基线检查：链接有效性、性能基线、安全基线。
整个过程中最重要的习惯，是记录问题时的信息完整度。我要求自己提交任何问题时，都带上截图、操作路径、接口返回信息、控制台报错，以及当时的浏览器版本。开发看到“这个页面打不开”的描述，基本上无从下手；但看到“点击列表页第5个商品的“加入收藏”，请求/api/favorite/add返回503，控制台报 Uncaught TypeError”，定位速度就完全不一样了。
对于偶发问题，我还会尝试用最小化步骤复现。先看是不是必现，如果不是，就从最简路径开始加条件，找到触发问题的最小条件组合。这个过程虽然费时间，但能把“偶发”变成“必现”，缺陷价值完全不同。
4.3 缺陷处理和上线判定
缺陷提交后要跟踪，不能只发出去等结果。我在项目里通常按优先级跟踪：
- P0缺陷，当天提出，阻止上线，当面找开发确认。
- P1缺陷，当天或者第二天解决，带病上线要有明确方案。
- P2缺陷，排期修复，记录在版本说明里。
上线判定时我参考的标准是：P0全部关闭，P1全部解决或明确带病方案，P2评估影响并排期；核心用户路径全部走通；关键性能指标在预期范围内；所有已修复的缺陷都做过回归验证。
这里要特别提醒的是，看到“已修复”状态不能直接信，一定回到用例里再执行一遍。我有过不止一次，开发说修好了，结果我一验证还是原样，要么是修复没生效，要么是修错了分支。回归验证是上线前的最后一道保险，这个动作不能省。
5. 网页/网站测试常见问题与排查技巧实录
5.1 断链的批量排查技巧
断链排查看起来简单，但实际做时会遇到几个坑。
第一个坑是爬虫结果和真实浏览器结果不一致。有些页面会根据User-Agent返回不同内容，爬虫抓出来是200，人工浏览器访问却是403。所以批量扫描只能作为初筛，最终判断要靠人工复核。
第二个坑是404不一定都是错。有些资源链接本身就是故意指向不存在的地址来隐藏文件，扫描判断时会误报。对这类链接，要结合需求确认“预期行为”是什么。
第三个坑是动态链接的构造。页面里很多链接是带参数的，比如/content/detail?id=xxx，如果用了一组没有存在数据的ID去测，返回404不代表链接有问题，而是数据本身不存在。构造扫描URL时，要用真实有效的参数集合。
批量扫描之后，按模板分组定位公共问题，这个方法很有效。同一个模板里的链接写死，会在全站所有使用该模板的页面同时报错，修一处就解决一整批。
5.2 页面加载慢如何定位是前端还是后端
用户报“页面加载慢”之后，测试要做的不是直接甩给开发，而是先定位到“慢在哪一段”。
我用浏览器开发者工具，主要看几个指标：
- 主文档的TTFB。这个值如果明显偏高，先怀疑后端接口、数据库查询、服务器配置。
- 静态资源下载时间。图片、CSS、JS单个资源体积过大，就要考虑压缩、裁剪、拆包。
- 脚本执行时间。前端如果有大量同步脚本，会直接阻塞渲染，表现为页面白屏一段时间后才出来。
- 请求数量。页面一次性发起几十个小请求，浏览器会并发排队，整体等待时间会被拉长。
举个例子，一个列表页在数据量超过一万条时加载非常慢，开发一开始怀疑前端渲染效率低，优化了好几轮都没效果。测试后来抓包发现，后端接口一次性返回了全量数据，返回体几十MB，问题根源是缺少分页接口。页面再优化，也架不住一次要处理和渲染几十MB数据。测试如果能把问题定位到这一层，开发修复的方向就完全不一样了。
5.3 兼容性问题先按矩阵排查
兼容性问题一多，容易乱。我的经验是先按“现象”分类，再按最可能的“原因”去查。下面这个矩阵是我实际工作中比较常用的：
| 现象 | 可能原因 | 首选排查方式 |
|---|---|---|
| 样式错乱 | CSS兼容性差异、公共样式未加载 | 网络面板确认CSS是否加载，再对比渲染 |
| 按钮点击无反应 | JS报错、事件未绑定、插件冲突 | 打开控制台看报错，检查事件监听 |
| 字体或间距异常 | 浏览器默认样式差异、rem计算错误 | 检查根字号与视口设置 |
| 图片拉伸变形 | 容器高度缺失、object-fit未设置 | 比对图片原始尺寸与CSS容器 |
记录兼容性问题时，有一个细节必须做到：带上浏览器具体版本号和操作系统。我之前遇到一个样式问题，只在某个浏览器的旧版本上出现，开发根据版本号很快定位到是某个CSS新特性没有被支持。如果描述里只写“在某个浏览器上样式错乱”，开发还得来回问版本号，沟通成本一下就上去了。
再补充一个操作习惯：做兼容性测试时不要只依赖开发者工具的模拟设备。真实设备的触摸反馈、软键盘弹出、默认字体渲染、屏幕亮度对视觉效果的影响，都是模拟器模拟不完全的。核心页面一定要在真机上跑一遍。
最后说一个自己的习惯。每个版本上线前，无论需求大小，我都会专门留出半小时做一轮全站链接扫描和核心页面回归。这个动作看起来简单，但救过我很多次。很多线上问题并不是某个页面功能坏了，而是藏在页面与页面之间的跳转关系里，平时不遍历不觉得，一出事就是直接暴露给用户。测试做久了你会发现，网页测试和网站测试这两层，本质上就是让你既要看得见树，也要看得见森林。
