2.3 项目文件与状态管理

2.3 项目文件与状态管理

本节摘要：一次真实评估要跨天推进，现场的保存与恢复能力决定工作连续性。本节讲清临时项目与持久项目的差别、项目文件里到底存了什么、哪些状态值得刻意维护，以及配置库怎么让"每次开新任务都从头点一遍设置"的重复劳动消失。

状态与现场保全

证书问题解决后，管道完全就绪。但在进入测试动作之前，还有一件容易被轻视的事：工作现场的资产管理。想象第二天早上回到工位，打开工具发现昨天的站点地图、历史记录、标注全部消失——临时项目的默认行为正是如此。社区版只有临时项目，专业版可以把现场存成项目文件，这是两个版本在"承接真实工作"上最实质的差别之一，比功能清单更能说明选型理由（呼应 1.2 节的结论）。

项目文件保存的内容比多数人以为的多：全部历史与站点地图、扫描结果与问题条目、手工添加的标注与高亮、会话状态、扩展加载记录与全局配置。换句话说，它保存的不只是数据，还有你的判断痕迹——哪些请求被标过、哪些范围被圈过。这些痕迹在写报告时就是证据索引，第六章会直接引用。

图：项目状态在任务周期中的流转

这条闭环里有两个动作值得制度化。一是阶段性保存：把项目文件存进任务目录，按日期留版本，防止单点损坏；二是配置抽存：任务里调好的监听、替换规则、范围配置抽出来存成命名配置，下一个同类任务直接套用。

项目文件里存什么、不存什么

值得存的状态可以按"丢失后要花多少时间重建"排序。头一档是历史与站点地图——丢了等于重测一遍；第二档是标注与高亮——丢了等于重新翻几万条记录找回重点；第三档是扫描问题——本身可重扫，但扫描耗时；最后一档才是界面布局这类易重建项。评估中期的项目文件可能长到可观，属正常现象，历史记录的体量在那里。

也有不进项目文件的东西要心里有数：导出过的报告是独立文件，截图、委托书、沟通记录在任务目录里自行管理。工具内的现场与工具外的交付物要分开归档，移交时两套都要交。

一份实用的任务目录组织方式：

任务目录/
  委托书与授权扫描件/
  项目文件/          按日期留版本
  导出报告/          中期稿与终稿
  证据截图/          与问题编号对应
  复测记录/
​

💡 项目文件按"一天一存"节奏落版本，文件名带日期。存档的成本几秒钟，回滚的价值按小时算。

配置库：把重复设置一次性做掉

每个新任务都要重做的设置——监听器端口、替换规则、范围模板、界面字体——都可以在配置页另存为命名配置文件，启动时或运行中随时恢复。建议维护三套基础配置：练习配置（回环监听、拦截默认开）、评估配置（回环监听、拦截默认关、范围模板就位）、移动端配置（绑定全部接口）。有了这三套，环境准备从半小时缩到两分钟，也避免了"忘了改某个设置"引入的隐患。

多人协作时还有一个朴素的替代做法：项目文件本身可以直接拷贝给同事接手，配合口头交接能快速续上。注意项目文件里含全部抓包数据，交接前确认其中的敏感内容（测试账号、凭证）在移交范围内。

任务交接与多人协作

项目文件的另一个用途是交接。评估中途换人、跨团队支援、休假接续，都是真实场景，交接质量取决于现场的可恢复程度。一份能用的交接包包含四件：项目文件本体（全部历史与标注）、当前的任务清单（哪些条目已确认、哪些在验证、哪些未动）、账号与环境的说明（测试账号权限、靶标地址、已知的环境怪癖）、报告草稿或条目池（已确认问题的现状）。工具内的标注体系就是任务清单的载体——3.1 节说的颜色语义在交接时直接变成协作语言：红色已坐实、黄色在验证、灰色待观察，接手人打开地图就知道战场态势。

多人同时操作同一项目文件并不可行——项目是单写者的，协作的正确粒度是"按人按任务分项目，报告阶段合并条目"。合并时的对齐动作：条目编号统一规则、等级评定口径事先商定、重复发现的去重原则（同根因合并、不同位置分列）。这些约定写在测试计划里，比事后争论省力得多。

配置的版本化管理

2.3 节的配置库解决了"复用"，这里补"演进"。配置文件是文本格式，天然适合放进版本管理：规则调整有历史，团队共享有载体，回滚有依据。实践中建议给配置提交写清动机（"为某项目增加内部标记规则"），半年后翻配置历史时，动机比内容更值钱。与代码仓库管理不同的一点：配置里可能含环境地址与内部命名，仓库的访问范围要与数据的敏感度匹配——这个意识与 5.1 节的插件审查同源，都是"便利资产的敏感度管理"。

另一类值得单独管理的状态是"已排除项"。测试过程中被推翻的假设——试过的路径、排除的疑点——留在历史里不加标注，几天后就会连自己都说不清"这条当时为什么不成立"。给排除项一个统一的标注语义（与坐实项、待复核项并列），报告的覆盖说明就有了现成素材：哪些地方看过、为什么判定无问题。排除项的记录颗粒度不必大，一句判定理由加关键请求的引用即可，积少成多后，它是抵御"你们是不是没测这里"这类质询时最扎实的弹药。

高频疑问

问：临时项目用了一半，能转成持久项目吗？
答：可以，工具支持把当前会话另存为项目文件。但更推荐的做法是开工就建项目——临时转持久的时刻恰是你最忙的时候，而项目文件应该从第一条流量开始积累上下文。

问：项目文件会不会很大，影响保存恢复速度？
答：重度使用后确实可观，几十上百兆都正常，恢复耗时随体量增长。缓解办法：历史里过滤掉静态资源类的噪音（显示过滤不影响保存内容，大项目靠作用域与去噪规则从源头控制体量）。

问：配置文件和项目文件都丢过，怎么彻底防？
答：把保存动作嵌进流程而非依赖记忆：每次收工的最后一个动作就是保存并提交版本管理。加上 2.3 节的按日版本留存，单点丢失最多损失半天——这已经是可接受的灾难半径。

与后续章节的接口

现场可存、配置可复用之后，工具的"后勤"齐了。第三章回到测试主线：先把历史流量整理成站点地图，把范围圈出来，再把值得深挖的请求送进重放器。从下一章起，你做的每个动作都值得顺手标注——这是 2.3 节留下的习惯红利。

本节要点回顾

• 版本差异的实质：持久项目保存的不只是数据，是判断痕迹与工作连续性。
• 优先级：历史与站点地图最贵，标注次之，界面布局最贱，按重建成本管理。
• 归档纪律：工具内现场与工具外交付物分开归档，移交两套都给。
• 配置库：练习、评估、移动端三套基础配置，环境准备标准化。