软件测评前的内部自测不是把软件再完整测一遍，是让送测版本有可被独立检查的质量基础和交接条件。

一、范围和影响

送测前先确定这次到底送什么、改了什么、可能影响什么。

列明本次送测对应的需求条目、变更点和影响模块。

范围外改动要么拆出，要么在提测说明中单独标注，不能混在送测版本里。

列出受影响的关联模块、接口和上下游依赖，标明哪些需要回归。

范围未冻结，不应进入后续自测和交接。

二、自测并记录

内部自测不能停留在点过了，没问题，至少要完成以下方面，并留下可查的执行记录。

冒烟自测：确定安装部署能完成，启动正常，登录、页面和主流程可走通。冒烟不通过，后续深测没有意义。

主流程和异常分支自测：主流程用例全部执行通过；异常分支至少包括输入检查、超时、权限不足等已识别场景。只测正常途径而忽略异常分支，是常见缺口。

关联模块回归：对影响面清单中涉及的模块和接口进行回归，确定本次修改没有破坏已有功能。

非功能自测：如果送测包含性能或安全测评，内部应提前做基础证实。性能重视重点交易响应时间、并发下基本可用性；安全至少自查 SQL 注入、越权访问、敏感信息硬编码等常见问题。非功能自测不必达到第三方测评深度，但不能完全空白。

自测记录要写明包括的功能点、用例执行结果和未包括部分，避免只写已自测，通过。

三、可追溯

提测版本对应唯一创建号，创建号可在创建系统或发布记录中查到。

创建来源分支和送测分支一致，创建可成功部署并启动。

版本号可追溯，部署日志和版本说明齐全。

创建不可追溯是典型阻断项：测试方无法确定送测版本和自测版本是不是一致，测评结果的可信度也无从谈起。

四、缺陷少到可送测

送测版本不能携带阻断性或严重级缺陷进入外部测评。

基础的要求是：致命级和严重级缺陷为 0；一般级遗留缺陷应有确定处理计划或规避方案，数量在团队约定可接受范围内。送测前整理已知问题清单，逐条说明现象、影响范围和是不是阻断主流程，随版本一并交接。不要把已知问题藏起来等测评方发现。

五、测试环境和数据

送测后的测评环境一般要求独立、非生产、可稳定访问。内部自测阶段就应打好基础：

环境可正常访问，部署版本和送测版本一致。

测试账号、权限就绪，登录入口可证实。

依赖的上下游服务、接口、消息中间件连通。

测试数据已准备，敏感字段完成脱敏，数据可重置到基线。

环境不通或数据缺失，测评方无法开始有效执行，送测版本可能被直接退回。

六、文档和证据

内部自测结果需要材料支撑，送测前至少整理好以下文档，并保证软件、文档、数据三者版本一致：

自测报告或自测记录：证明主流程、异常分支、回归已执行，附用例和结果。

已知问题清单：说明遗留缺陷状态、影响和规避方案。

需求规格说明书或功能清单：测评方界定测试范围的根据。

部署或安装手册：指导测评环境搭建。

用户操作手册：测评方核对功能和文档一致性。

接口文档：涉及接口测试时作为基础。

创建记录和版本说明：证明送测版本可追溯。