计算机化系统验证（九）-运行确认OQ

恨我不成钢

1.  前言

       最近忙项目上的事，对这个有点懒了，抱歉都不好意思说了。

       运行确认是整个计算机化系统验证过程中量最大，也最难做的。好多人把运行确认当做测试中的黑盒测试来做。无可厚非吧，不太恰当，只能说是相似！整个确认过程相似但又有区别，最大的区别就是合规性。测试面对的是功能的完整性，而验证面对的不仅仅是功能的完整性，还有功能的符合性（这里也包括了符合法规）。

2.  风险评估

关键字：风险评估

       说到运行确认，又得拉上风险评估了（之前就说过，风险评估是贯穿于整个验证项目全过程的），运行确认这一步是对功能设计时的风险评估决策的一个确认，确认是否都完整执行了风险评估决策。

       最简单的例子：URS中提出某个需要用户输入的功能。按照我们计算机化系统验证的要求首先应当对该功能设计进行风险评估，其风险评估结果如果是中（注意，这里我用的是如果，而未明确说明是中等风险，其原因可参考我之前的风险评估那篇文章），那就应当采取相应的措施降低其风险，比如采用下拉选项框的方式，以减少用户的输入，从而提高其输入准确率，降低其输入错误的风险（我这里用的是降低，其实风险还有的，比如选择错误的风险）。这个时候功能确认就应当首先确认是否采用了下拉选项框的方式。表面上来看输入错误的风险是降低了，但同时会带来另一个大的风险——下拉框中的选项大量增加导致系统运行速度变慢。那一般采用的方式就是过滤，或者数据归档。同样的，功能确认时还应当确认这部分的功能的完整性。继续来看，好像问题是解决了，其实刚括弧里我也说了，用户输入错误的风险还在，只是几率降低了而已，那我们再来个应对措施吧，增加一级审查功能，用另外一个人的账户进入系统进行数据审核，从而再次降低用户输入错误的风险，当然增加一级审核后风险依然存在，只是更加的低了而已。

       回头再来看上面的例子，风险评估过程中我们发现三个风险，同时针对这三个风险又做了不同的风险的应对措施。如果是按照软件系统的黑盒测试进行，那其实第一步采用输入框的方式，其实已经满足了需求了。其测试用例就会相当简单了。比如测试其输入框的最小长度的、最大长度、字符检查等几个步骤即可。而站在验证的角度去看，测试用例就大变样了，不但要测试下拉选项中选项为空的情况，还要测试数据大量增加后其系统的性能（可放于PQ部分进行，但需在OQ中明确说明）以及数据审核功能的完整性。当然审核功能的完整性同时还包含了可追溯性了。      

3.  运行确认方案OQP

关键字：先决条件、功能确认、安全确认、数据可靠性确认、运行确认

运行确认方案是个关键，其方案的完整性决定了系统以后运行的可靠性。完整的运行确认方案至少应包含培训安排、日程安排、人员安排、先决条件确认、功能确认、系统安全确认、数据可靠性确认、偏差处理、变更处理、确认结果判定以及其他如目的、法规、输出文档列表、参考文档列表等等。

3.1.培训安排

培训安排是对要进行OQ确认的相关人员的培训，只有培训合格之后才能进行相关确认。当然，有培训就得有培训方案了。包括有培训人、参训人、日程安排、培训内容、考核方式等等。

3.2.日程安排

这里的日程安排就是OQ确认过程的日程安排，应明确到天。每天应进行的任务安排以及最终报告形成的日程安排。注意！很多企业这里的日程安排往往被挑战。一是，任务安排不合理，人员根本无法完成，二是，任务安排的日期和最终完成的日期有偏差，而最终结果并未进行偏差处理。所以日程的安排至少应当合理。

3.3.人员安排

人员安排也是相对简单的，无非就是要参加OQ确认的人员安排以及测试用例编写的人员的安排。这里的测试用例编写人员制药企业用户一般无法完成，所以需要供应商进行协助。因为测试用例的编写涉及到功能点的拆分（如果是按照功能点进行确认的话）。

3.4.先决条件确认

先决条件这里一般指的是系统运行环境的确认结果（IQ）以及相关SOP的确认。这些SOP包括了计算机化系统管理规程、数据迁移和退役管理规程、备份和还原管理规程、访问及安全管理规程、维护管理规程、系统问题报告管理规程、电子记录签名管理规程等等。这些规程应当是针对当前系统的管理规程，而非制药企业总的管理规程。这些规程此时可以是草稿状态，但必须在OQ报告完成之前生效。

先决条件里还包括了另一部分文档，系统相关的文档了，比如功能操作手册、系统配置手册等等。

3.5.功能确认

功能确认关键点就一个：明确说明采用何种方式进行功能点的确认。这里的方式指的是单元测试、集成测试、系统测试、验收测试以及是否需要回归测试。这几个名词解释自行百度吧。这里我主要说下验收测试。因为其他几类测试基本上对于制药企业用户来说很难完成，一句话由供应商提供质量报告即可。

验收测试时，我们又可按照功能划分为各个小的功能点的测试。而功能点的划分又必须明确不同功能点的关联性。一般建议把无关联的功能点进行划分，有关联的功能点放到一起进行测试。当然，测试过程是否采用脚本的方式，就完全看功能的设计了。

一旦把功能点拆分完成后，就应当针对不同的功能点编写相关的测试用例了。编写时一般建议按照先决条件的方式进行编写，比如某个功能的完整必须由上一个功能完整后才可进行。

当然了，运行确认方案中应当明确都包含哪些测试用例，而且最好按照先决条件的顺序罗列并执行。

3.6.系统安全确认

安全确认往往是被用户很容易忽略或者说知道又不知道如何来做的问题。关于安全确认包括的内容就很多了，这里我只简单说三个常用的安全的确认。

1）系统运行环境安全确认。字面意思就是运行环境的安全性确认，比如机房安全、服务器安全、网络安全、电源安全等等（防火防盗防……）。

2）系统本身的安全确认。比如登录安全、防篡改、暴力破解、SQL注入、密码安全、数据库相关安全、端口安全等等。

3）数据储存安全确认。比如异地备份（关于异地备份可参考我之前写过的一篇文章，切不可过之而为，即浪费了财力又浪费人力）等。

3.7.数据可靠性确认

这个恐怕是最难做好的确认了。之前我有讲过相关的概念。这里单独列出来进行确认，其实就是对数据的真实性和可追溯性的一个确认过程。

真实性还好做一点，无非就是在系统功能中的关键节点上再进行一次确认，明确指明该功能点的设计时考虑了数据的非法修改的控制等。

可追溯性就稍微复杂了一些。即要保证该来源数据的不可篡改（一般是系统运行数据的入口处控制），又要保证在系统中流转的数据的全程追溯、跟踪、审计等。

关于数据审计跟踪在这里就不啰嗦了……

3.8.确认结果判定

这里的结果确认判定即是对结果判定的结论预值，以及结果的接受条件。明确表面合格或失败采用什么样的方式表明，什么样的结果是可接受的，一旦发生不可接受的结果后应当如何处理等。

3.9.其他确认

剩下的确认有的是SOP的确认，有的就是相关支撑文档的确认了。比较简单，这里就不啰嗦了。

4.  运行确认报告OQR

确认方案的执行完成之后就可以编写确认报告了。这里要注意的一点就是确认报告的最终完成日期之前，方案中先决条件下的相关SOP就必须生效了。

确认报告附件的相关测试用例可参考IQ的测试用例编写格式，同样的，实际结果应当采用手写的方式，至于用什么颜色的笔，目前大多数企业都采用的蓝色笔，以区分复印的痕迹。

当然也要注意确认报告的格式，可参考IQR即可。

5.  总结

OQ方案中的量和难点都在测试用例的编写上。如果是按照功能点的拆分进行确认，其拆分难度很高，一定要明确其关联性。对于强关联性的功能点就建议放到一个测试用例中进行好了。当然，如果不按照功能点来拆分确认，按照系统整体进行确认也是可以的，但测试用例会很庞大，一旦发生偏差，就得从头再来，这一点我是害怕的！

最后还要说明一点。确认过程中产生的相关数据，必须要保留在系统中，至于该系统是否生产系统还是验证系统，只要能明确经过确认后的系统和生产用的系统是一致的即可。我一般的做法是将确认后的系统切换成生产系统，免得提供的证明文件无法证明两个系统环境的一致性而被挑战（嘿嘿……）。当然切换成生产系统就需要很多个相关前置条件的确认了……

wwhcom

谢谢楼主，看来以后需要实时关注楼主的帖子，很有用处的

雪山玉龙

谢谢楼主，用心发好帖，受益匪浅。

北重楼

写的太粗略，有没有具体点的

唐延进

出发点是好的，不过略显简单！我们还是要鼓励与坚持的，这个本来就没法写的尽善尽美

jixia

多谢楼主的经验总结，说的很好