网页问题怎么反馈？页面地址、复现步骤与截图清单

网页问题反馈可以按“在哪个页面、什么条件下、怎样操作、原本期待什么、实际出现什么”整理。把这些信息写在同一条记录里，接手的人才能知道需要查看和复测的对象；只发“网站有问题”或一张局部截图，往往还需要补充上下文。

本文面向网站委托方与交付协作人员，提供可复制的问题记录表和一份虚构填写示例。它不判断故障责任，不保证修复时间，也不把一个页面复测通过当成整站全部验收通过。

先确认：这是功能异常、视觉意见，还是新增需求

可以先给每条意见标明类型，再由双方确认处理范围：

表中只是说明写法，不代表任何真实项目已经出现这些情况。若还不确定是否属于原范围，就标记“范围待确认”，不要先写成对方已经认可的缺陷。静态图片与排版偏好可另看设计修改意见整理方法；本页重点是可以按操作步骤追踪的网页问题。

记录页面与环境，让问题有明确位置

先保存出现问题的页面地址，并说明是测试页面还是正式页面、是否登录、使用哪类账号。若地址包含登录令牌、私人标识或其他敏感参数，先删去敏感值，并告诉接手者哪些部分已隐藏；不要把完整带密钥链接发进公开问题单。

记录设备类型、操作系统、浏览器名称和实际版本。涉及手机排版时，可补充屏幕方向、浏览器缩放或是否在 App 内打开。项目有版本号或交付批次时一并写入；不知道就填写“待确认”，不凭发布时间猜版本。

偶发问题可以附发生时间与时区，以及当时正在做的事情。没有测试过其他设备，就写“尚未测试”，不能因为自己一次遇到就断言所有用户都会遇到。也不要为了补齐环境表而填写并未查看的版本信息。

将复现步骤、预期结果和实际结果分开

从接手者能找到的起点开始，一步写一个动作：打开哪个页面、选择什么条件、点击哪个按钮。需要登录、特定数据或前置状态时先说明；不要要求对方猜出截图之前做过什么。

“预期结果”说明依据，可以是已经确认的需求、交付说明或需要进一步确认的使用目标。“实际结果”只写看到的现象，例如出现了哪段提示、哪条记录或哪个位置发生变化。错误提示尽量保留原文；“后端写错了”“服务器一定坏了”属于原因猜测，应另列为待排查。

Mozilla 的 Bug Writing Guidelines 也建议报告明确的复现步骤、预期与实际结果，并把观察事实与猜测区分开。该来源面向 Mozilla 项目的问题报告；这里仅借用信息组织方式，不把它当作所有网站项目的统一验收标准。

把“经常出错”换成实际观察记录。只看到一次，就写一次；没有稳定复现步骤，可以记录发生条件、时间与附件，并明确“暂未稳定复现”。本页不规定必须重复尝试多少次，尤其不要反复执行可能产生订单、付款、消息或数据变更的操作。

截图要能定位，录屏要有开始和结束

截图可以保留页面标题、相关控件及异常位置，再另加箭头或框选说明。局部图看不出所在页面时，补一张范围更大的图；标注不要遮挡错误提示。附件用问题编号与版本命名，保留能辨认内容的尺寸，不只发送多次压缩后的模糊图片。

录屏适合说明连续动作。开始时说明页面与前置条件，结束时停在实际结果；不需要录下整个桌面和无关聊天。发送前检查姓名、手机号、地址、客户内容、账号信息和浏览器其他标签，确认分享范围并处理敏感部分。

接手者确实需要日志时，再确认需要哪段、对应时间及交付方式。不把密码、访问令牌、整份客户数据或未经确认的网络抓包文件直接附进反馈单。普通委托方可以先提交观察记录，由负责排查的人说明还缺什么材料。

可直接复制的问题记录表

一条记录先聚焦一个可以独立复测的问题。多个问题可以放在同一份清单中，但分别保留编号、实际结果和处理状态。

字段可以按项目缩减，但不要为了表格看起来完整而把“未知”填成确定结论。反馈记录不是维修完成证明，也不替代双方对交付范围的确认。

虚构示例：筛选条件在翻页后没有保持

以下为虚构示例，仅演示填写方法，不代表真实客户、订单、供给、收入或经营结果，也不表示我们已经对某个站点执行过这些测试。页面路径、版本与观察次数均为演示设定。

问题编号与标题：WEB-01，筛选“可在线交付”后切换下一页，出现未满足筛选条件的项目。

页面与前置条件：演示测试页 /demo/catalog，演示版本 A；未登录。按本示例设定，测试数据包含多个结果页。设备与浏览器字段在真实反馈中填写实际查看到的信息，不沿用示例猜测。

操作步骤：

1. 打开演示测试页，确认未选择筛选条件。
2. 选择“可在线交付”，观察第一页显示结果。
3. 点击结果列表的“下一页”，记录新页面的筛选状态和项目内容。

预期结果：按本示例设定的需求，翻页后仍保留已选条件，结果均符合该条件。

实际结果：按本示例设定，第二页出现标为“仅线下”的项目；筛选控件仍显示“可在线交付”。这说明观察到的内容与示例预期不同，但不能据此直接判定是哪段代码出错。

观察与附件：演示设定为一次观察，尚未验证其他设备；附件名为 WEB-01-版本A-结果页.png。这里仅演示附件命名，本文没有附一张伪装成真实测试回执的截图。

待确认：开发方先核对示例需求是否与实际交付范围一致，再说明需要补充哪些数据或环境信息。真实项目应替换所有演示条件，不能直接提交这段文字充当实际故障记录。

处理后，用原步骤复测并保留结果

先请接手者说明处理了什么、在哪个版本可以复测，以及有没有尚未覆盖的条件。反馈人按原记录中的起点与步骤重新检查，写明这次实际结果；需要更换测试数据或环境时，记录变化，不把不同条件的结果混作一次对照。

可以使用“待补信息、待处理、待复测、原问题仍存在、在本次条件下通过”等具体状态。对方回复“已修复”之后，如果自己还未检查，就保留“待复测”。一次复测通过只描述这次检查范围；其他页面和新增问题分别跟进。

若新版本出现另一个问题，另建编号并链接原记录；原问题尚未解决时继续沿用原编号，避免同一件事在聊天中失去上下文。是否增加工作范围、费用或排期，应由双方确认，不从“问题已提交”推断对方已经接受所有要求。

这几种情况，先补信息再下结论

无法稳定复现：保留发生时间、当时步骤与可分享的附件，标明哪些条件未知。不能复现不等于用户没有遇到，也不等于故障原因已经确定。

怀疑浏览器显示了旧页面：先记录当前显示内容与版本。是否刷新、使用新的测试会话或清理缓存，应结合项目安排选择，并在记录里注明操作前后差异；不要把“清过缓存”写成问题根因已确认。

表单提交后没有提示：不要立刻连续提交。先记录页面状态与时间，请相应负责人核对是否已产生记录；需要再次操作时，使用获准的测试环境和样本，避免重复订单、消息或真实资料写入。

发现疑似信息暴露：不要继续尝试获取更多资料，也不要在公开反馈单附上原始敏感内容。通过已约定的负责人渠道说明位置与现象，再由有权限的人处理。

如果项目还处于选择服务方和确定需求的阶段，可先使用网站开发需求与交付核对清单。明确原需求之后，再用本页记录具体网页问题，分别推进范围确认、修复和复测。

了解极客豌豆 App：下载极客豌豆 App。具体功能与服务以 App 内实际展示为准。

本文由极客豌豆编辑部整理与复核。作者与审核说明｜内容与编辑政策