CSV是否需独立验证环境及PQ执行位置的实践梳理

本期从新系统上线到QMS、DMS功能变更，梳理测试环境、验证环境与生产环境。

近期有网友提出三个非常典型的问题：计算机化系统是否一定要有验证环境？如果有验证环境，PQ放在哪里更妥当？测试、验证和生产环境是不是必须各配一台数据库服务器？

这三个问题表面上在问“需要几套环境”，本质上是在问：测试风险如何隔离、非生产环境能否代表正式系统，以及验证结果如何受控地转移到生产。

先说结论：法规通常不按名称强制企业建立DEV、TEST、VAL、PROD四套环境，也不要求一套环境对应一台物理服务器。环境策略应基于系统风险和测试影响确定。PQ要证明预定用途，既可以在尚未上线的生产环境执行，也可以在具有代表性的验证环境执行；若主要证据来自非生产环境，部署后必须补充生产环境确认。

01 法规有没有强制要求“独立验证环境”？

现行欧盟GMP附录11并没有规定每个系统必须建立一套名为“VAL”的独立实例。其核心要求是：应用程序经过验证、IT基础设施经过确认，验证范围基于患者安全、产品质量和数据完整性风险确定。附录11第4.7条要求提供适当测试方法和测试场景的证据，并对自动化测试工具和测试环境的适用性进行文件化评估。

OECD关于GLP计算机化系统的文件提出，新系统应进行前瞻性验证，并根据系统规模、关键性和新颖性，在可能的情况下于专用验证环境中测试后再转入实验室运行环境。这里的关键词是“根据风险”和“如果可能”，表达的是优先策略，并非对所有系统一刀切。

GAMP关于GxP系统测试的指南同样指出：如果测试活动或测试输出可能干扰运行、造成混淆，或者影响患者安全、产品质量和数据完整性，就不宜把所有测试放在最终运行环境中，此时应建立单独的测试环境。

监管判断点：检查员关注的不是服务器上有没有一个名为“VAL”的标签，而是测试是否充分、环境是否有代表性、测试是否污染真实数据，以及系统上线前是否完成批准。

02 四类环境分别承担什么责任？

环境	主要用途	控制重点
开发环境（DEV）	编程、配置设计、缺陷修复	变化频繁，通常不直接形成正式验证证据
测试环境（TEST）	集成、边界、负面、压力、回归测试	允许发现问题和反复修复，但版本和数据仍须可识别
验证环境（VAL）	执行已批准的OQ、PQ或UAT	版本、配置、账号和测试数据受控，偏差按程序处理
生产环境（PROD）	承载真实GxP业务和正式记录	上线后仅执行必要、受控且低影响的确认

有的企业内部经常混用“测试环境”和“验证环境”。二者可以是同一套技术实例，但用途不同：测试环境以发现缺陷为目标；验证环境以形成可批准、可追溯的正式证据为目标。

如果TEST与VAL合并，正式验证开始前至少应完成版本确认、关键配置冻结、无关测试数据处理、受控测试账号建立和验证方案批准；正式执行后发现缺陷需要修改配置时，应先记录偏差并评估影响，再受控修改和回归测试。

还要区分“尚未上线的未来生产环境”和“已经承载真实业务的生产环境”。前者可以在放行前承担大量确认活动；后者包含真实GxP数据、审计追踪和业务任务，任何测试都可能形成长期影响。

03 所有验证都在生产环境执行，可以吗？

对于新系统，如果生产实例已经完成安装但尚未投入正式使用，IQ、OQ和PQ可以在该环境中执行。这种做法适用于标准化程度高、规模较小、另建环境不合理，并且能够在正式业务开始前完成全部测试的系统。

但“在生产环境验证”不能等于“边生产边试”。企业至少需要明确测试窗口、冻结业务、识别测试数据、控制测试账号、记录配置变化、处理验证偏差，并在测试结束后确认数据、接口、定时任务和账号处于可放行状态。

系统正式上线后，下列测试一般应优先放在非生产环境：

越权和高权限账号挑战；
删除、恢复、故障切换和灾难恢复；
接口中断、重复传输、错误映射和消息重放；
大批量压力、并发和性能极限测试；
大量异常、边界和错误输入；
可能触发真实邮件、报警、签名、审批或批处理任务的场景。

FDA有关药品企业计算机化系统检查的指导强调，软件测试应考虑具有挑战性的生产条件，例如数据量、处理速度和使用频率。这要求测试具有生产代表性，并不意味着必须把破坏性挑战直接施加于正在运行的生产系统。

04 PQ到底在哪里做？

PQ的本质是证明系统在预定用户、业务流程和运行条件下适合预定用途。因此，环境名称不是决定因素，证据链才是决定因素。

路径一：在尚未上线的生产环境执行PQ

先在TEST/VAL完成缺陷发现、边界和负面测试，再把批准版本部署到未来生产环境；随后使用正式或有代表性的账号、接口、打印机、网络和业务流程执行PQ，处理偏差并批准上线。该路径对新建QMS、DMS、LIMS等系统通常最直观。

路径二：在验证环境完成主要PQ，再做生产确认

当验证环境足以代表生产配置时，可以在VAL完成主要业务场景，但应有生产环境的PIQ，文件化比较软件及补丁、数据库、关键配置、权限模型、工作流、接口逻辑、审计追踪、电子签名。差异不需要被强行消除为“完全相同”，但每项差异都应评估其对测试结论的影响。

部署到生产环境后确认事项：

安装位置、软件版本、补丁和关键配置；
正式用户、角色、高权限账号和单点登录；
正式接口、打印、报表、邮件、报警和定时任务；
时间同步、电子签名、审计追踪和关键工作流；
备份任务、监控和必要的业务连续性配置。

一句话：PQ不一定全部在生产环境做，但不能只证明“VAL运行正常”，却没有证明部署到PROD的版本、配置、权限和接口仍处于已验证状态。

05 新上线QMS：推荐如何安排？

假设企业新上线一套涵盖偏差、CAPA、变更和投诉的QMS。推荐路径如下：

TEST：完成工作流配置、角色权限、退回/撤回/升级、电子签名、审计追踪、边界输入、接口中断、报表逻辑和回归测试。这里允许反复修复缺陷。
VAL：配置冻结后，按批准方案执行OQ、关键流程PQ/UAT、端到端业务场景和数据完整性控制测试。
PROD：上线前确认正式账号、单点登录、邮件、接口、报表、备份和关键流程测试，完成验证报告及上线批准后才接收真实记录。

若企业没有独立VAL，也可以直接在尚未上线的生产实例完成正式验证，但应预先规定测试数据的标识、保留或处理方式，确保不会与真实偏差、CAPA和投诉记录混淆。

06 已上线QMS增加功能：为什么更需要非生产环境？

假设QMS已经运行两年，现在增加“CAPA超期自动升级”和“管理层趋势看板”。如果直接在生产环境边改边试，可能错误升级真实CAPA、向用户发送错误邮件、改变记录状态、影响趋势统计并产生难以解释的审计追踪。

推荐采用“变更控制—影响评估—非生产环境配置与测试—回归测试—正式验证—批准迁移—生产确认—启用功能”的路径。验证范围取决于功能风险：新增一个不参与质量决策的显示字段，可以缩小测试；改变审批、电子签名、状态转换或质量决策逻辑，则需要更充分的再验证。

07 已上线DMS增加电子审批：不是简单增加一个按钮

DMS从文件存储扩展到电子审批和生效控制，可能同时影响文件版本、起草审核批准权限、电子签名、生效日期、旧版作废、培训触发、打印状态和审计追踪。

应在非生产环境完整覆盖退回、撤回、拒绝、重新提交、代理审批、人员离职、签名失败等分支；部署后再确认正式账号和角色、签名、时间同步、邮件及培训接口、文件生效与作废、打印水印和审计追踪。不要拿真实SOP在运行中的生产环境反复测试审批和作废。

08 三套环境必须购买三台数据库服务器吗？

环境数量与物理服务器数量不是一一对应关系。企业可以使用独立物理服务器，也可以在一套经过管理的虚拟化集群或云平台中，通过独立虚拟机、容器、应用实例、数据库实例、存储区域、网络策略和账号权限实现隔离。

这里的“实例”可以理解为一套能够独立运行和管理的软件或数据库运行单元。即使底层共用一组物理硬件，DEV、TEST/VAL和PROD仍可以拥有各自的应用地址、配置、进程、数据库、账号和数据。

关键不是共不共用硬件，而是以下控制是否有效：

非生产用户不能访问或修改生产数据；
测试接口不会误连生产业务，连接字符串和密钥受到控制；
各环境版本、配置、域名/IP和数据库实例可以明确识别；
测试数据不会成为正式GxP记录；
资源竞争、备份和维护不会影响生产可用性；
配置、代码和主数据迁移经过审批、核对并可追溯。

需要注意，“测试数据不应随意迁入生产”不等于任何数据都绝对不能迁移。经批准和验证的配置、工作流、模板、字典或主数据可以通过受控发布流程迁移；用于模拟业务的测试记录通常不应进入生产。若生产数据复制到测试环境，还应实施脱敏、访问限制、供应商访问控制和到期删除。

09 什么时候可以合并环境？

TEST与VAL可以合并，甚至验证可以在尚未上线的PROD执行，但应同时满足以下条件：

系统标准化程度较高、变更频率低，测试范围可控；
正式验证前能够冻结版本和关键配置；
测试不会影响正在进行的GxP业务或其他系统；
测试数据能够被识别、审核并按批准方式处理；
缺陷修复、重测和偏差处理有完整记录；
上线前能够确认正式账号、接口、任务和备份配置；
环境合并及其补偿控制已经过书面风险评估和批准。

对于持续开发、频繁发布、接口复杂、用户众多或承载关键质量决策的系统，长期只有一套已经运行的生产环境，通常很难同时满足缺陷测试、数据隔离和业务连续性要求，建立受控非生产环境更为合理。

10 测试验证环境如何写入CSV管理程序？

建议：计算机化系统环境的数量、用途和隔离方式，应根据系统关键性、开发模式、变更频率、测试风险及数据完整性要求确定。验证可在受控非生产环境或尚未投入正式使用的生产环境执行。对于已经正式运行的生产环境，应限制可能影响真实GxP数据、系统可用性和正式业务的测试。主要验证在非生产环境完成时，部署后应确认生产版本、配置、权限、接口及关键运行任务。环境间的软件、配置和数据迁移应经批准、核对并保留记录。

实际决策时，可以连续问三个问题：

测试会不会删除或污染数据、触发真实任务、造成系统中断？如果会，优先放在非生产环境。
测试是否依赖正式接口、域账号、打印机、邮件、网络或备份？如果依赖，应在上线前或受控窗口补充生产确认。
非生产环境是否足以代表生产？如果差异可能影响结论，应缩小差异、补充测试或说明理由。

结语：环境可以合并，控制责任不能消失

高风险和破坏性测试与正式业务隔离；测试环境具有代表性并受到控制；系统投入使用前完成验证和批准；迁移过程可追溯；部署后确认生产配置；上线后的变更通过风险评估和再验证持续维持验证状态。

最后概括：开发环境用于改变系统，测试环境用于发现问题，验证环境用于形成证据，生产环境用于承载真实业务并证明最终部署正确。它们可以合并，但任何合并都必须清晰版本控制、数据隔离、偏差处理和上线批准。