本文目录导读：
这是一个非常专业且具体的主题,PHP项目的验收通常涉及技术验收和业务验收两个维度，而UAT（User Acceptance Testing，用户验收测试）是业务验收的核心环节。
以下是一份针对PHP项目（特别是Web应用、API接口或管理后台）的验收清单与UAT测试指南。
核心定义与区别
- UAT测试：由最终用户（不是开发者）执行，目的是验证系统是否满足业务需求、流程走得通、易用性好。
- 技术验收：由技术负责人或运维执行，目的是验证代码质量、性能、安全、部署架构是否达标。
- 验收：是上述两者的总称，通常UAT通过后才算正式验收。
PHP项目UAT测试清单（面向业务用户）
在进行UAT之前,必须确保测试环境与生产环境尽可能一致（PHP版本、扩展、数据库结构等）。
核心业务流程测试（最重点）
- 正向流程：用户能否从头到尾完成所有关键功能？
- 例子：注册 -> 登录 -> 下单 -> 支付 -> 查看订单 -> 申请退款 -> 客服处理。
- 逆向流程：用户操作错误时，系统是否友好？
- 例子：提交空表单、输入过期优惠券、上传非法文件类型。
- 状态流转：系统状态变化是否符合预期？
- 例子：订单状态：待支付 -> 已支付 -> 已发货 -> 已完成 -> 已取消，每个状态的触发条件是否严格。
边界与异常测试
- 输入极限：
- 输入超长用户名/密码（如255字符）。
- 金额输入负数、0、超出余额。
- 日期选择：跨越年度、2月29日（闰年）、1970-01-01以前。
- 并发操作：两个用户同时操作同一条数据（如抢购最后一件商品、同时编辑同一条记录），PHP在处理并发时，是否有锁机制或乐观锁？
- 浏览器兼容性：UAT用户常用的浏览器（Chrome, Edge, Safari, 微信内置浏览器）是否正常。
- 移动端适配：如果项目有前端，是否适配手机、平板？
业务规则验证
- 权限控制：
- 普通用户是否能通过修改URL访问管理员页面？
- 不同角色（管理员、编辑员、普通会员）看到的功能/数据是否严格隔离。
- 计算逻辑：
- 价格、折扣、税费、运费的计算公式是否准确？（建议准备一组已知结果的数据进行代入验证）。
- 报表统计（如销售额日报）的合计、平均值、环比是否与手工计算一致。
- 数据一致性：
删除一个用户后,该用户的订单、评论、收藏是逻辑删除（隐藏）还是级联删除？数据是否冗余（如订单中复制了用户快照）。
UAT评分与反馈
- 易用性：用户能否在不看文档的情况下完成任务？（操作路径是否过长、按钮位置是否合理、错误提示是否清晰）。
- 性能感知：页面加载是否超过3秒？接口响应是否超过2秒？
- Bug分级：
- P0（致命）：核心流程断掉、数据丢失、支付出错。
- P1（严重）：功能不能用，但有替代方案。
- P2（一般）：显示错位、提示不友好。
- P3（建议）：优化建议，不影响上线。
PHP项目技术验收清单（面向开发/运维）
UAT通过后,上线前必须过技术关。
代码与架构层面
- 框架版本：使用的Laravel/Symfony/ThinkPHP等是否是最新稳定版？是否有已知CVE漏洞？
- 依赖管理：
composer.json中是否有废弃或高危依赖？是否存在dev-master等不固定版本？ - SQL预编译：是否所有SQL都使用了参数绑定（PDO/ORM）？坚决杜绝字符串拼接SQL。
- 敏感信息泄露：
.env文件是否在代码仓库中？数据库密码、API Key是否硬编码？ - 错误处理：
php.ini中display_errors应为Off，是否有全局异常捕获（try-catch或Laravel的Handler）？
安全层面（PHP项目重灾区）
- SQL注入：测试
' OR 1=1 --等注入字符串。 - XSS跨站脚本：用户输入的内容（如评论、昵称）在被展示时是否进行了
htmlspecialchars()转义？ - CSRF跨站请求伪造：所有POST/PUT/DELETE请求是否有Token验证？
- 文件上传：是否限制文件类型（白名单）、大小、且文件保存路径不可被直接访问（应放在
public目录外或使用Storage驱动）？ - 越权：用户A能否通过修改URL中的ID参数查看用户B的订单详情？
性能与压力（上线前必须做）
- 慢查询日志：开启MySQL慢日志，检查是否有全表扫描（
type: ALL）或未命中索引的SQL。 - 接口压力测试：使用工具（如Apache Bench、JMeter）压测核心接口（如列表页、登录、下单）：
- QPS（每秒请求数）是否达标？
- 是否有内存泄漏？执行10万次请求后PHP进程内存是否暴涨？
- 缓存策略：是否合理使用Redis/Memcached？缓存失效的雪崩/穿透是否有防护？
运维与部署
- 日志系统：是否有业务日志（如登录日志、支付日志）和错误日志？日志轮转是否配置？
- 环境一致性：
php.ini配置（memory_limit,upload_max_filesize,max_execution_time）是否与需求一致。 - 回滚方案：上线脚本是否支持
git revert？数据库迁移（migration）是否能回滚？
验收与UAT的流程建议
- 预验收（内部测试）：开发团队自测 + QA（Quality Assurance，质量保障）团队测试，修完所有P0/P1（致命/严重）Bug。
- UAT环境部署：搭建独立于开发和生产环境的UAT环境。
- 用户培训与UAT脚本：给用户写一份“测试用例”或“操作指南”，而不是让用户乱点。“请尝试使用优惠券购买一个商品，金额务必为XXX元”。
- 执行UAT：用户按脚本操作，记录Bug和反馈。强调：禁止在UAT环境直接修改代码和数据库；所有修改必须走开发流程。
- Bug修复与回归：开发修复UAT发现的Bug，然后进行回归测试。
- 签署UAT报告：用户确认所有P0/P1已修复，核心业务可用，签署验收报告。
- 上线：部署到生产环境。
常见PHP项目验收失败原因
- 环境差异：生产环境是Linux + 编译安装的PHP，UAT环境是Windows + XAMPP，导致性能或行为不一致。
- 权限混乱：忘记了中间件（Middleware）的配置，导致用户能看到管理员功能入口。
- 忽略HttpOnly（超文本传输协议安全标志）Cookie（网络小甜饼）：Session ID泄露，导致CSRF/Session劫持。
- 时区问题：
date.timezone未设置为PRC或Asia/Shanghai，导致订单时间显示为UTC时间。 - 内存限制：导出Excel/生成PDF时，前端按钮点下去以后，后端因
memory_limit不够直接返回500错误。
对于PHP项目,UAT的核心是业务流程走得通，技术验收的核心是不崩溃、不泄露、能抗压，建议将上述清单做成一个checklist.md文件，UAT测试结束后逐项打勾。
