Ø 问题：发布测试

SP11发布过程中，测试部作了很大努力，但我个人认为测试效果并不理想。主要有问题有：

1、  测试资源配置不足

SP11原先预定4月2日更新，但由于测试时间不足，测试人员也不够，基本上只有4月2号组织测试了一下，我认为测试不够全面，觉得不能发布过去，刚好当时绿城反馈了医保的几个问题，所以就顺延了下来。由于具有打Label权限的测试部人员不在，导致4月3号晚上程序编译出来时，曾贤宝无法在VSS里面打Label。导致现在的另一个问题是，如果我们再不发布SP12的情况下，想对绿城SP11的程序作个别系统升级，操作很复杂，需要一个个PBL取出来，再重新修改和编译，目前绿城的医保已经出现类似需求。

2、  测试流程走的不完整

虽然，绿城SP11发布主要是针对住院、临床和药库房方面，以及少量绿城SP10发布后暴露的门诊系统问题，但是我们编译的程序实际上是完整包括了针对北京协和的门诊修改。SP11的发布测试应该包括门诊业务的完整测试，但是测试人员没有针对4月3号编译出来的门诊程序进行认真测试，我在4月4号绿城现场调试医保的时候，发现出现了协和而不是绿城的业务窗口，而4月7日晚上绿城升级到SP11后，我进行业务测试的时候，诊间甚至出现了无法结束就诊的致命错误，虽然问题的根本原因是开发人员的DSA基线库更新遗漏和开发工具P/S对应关系维护错误，但是测试没发现这个问题实在说不过去。

3、  测试人员的主动意识不够

HIS3现在的自动编译机基于Build_F.INI文件工作。经过这么长时间的HIS3发布，测试人员应该已经能够知道编译机自动编译出问题的大致原因，应该能够主动的去解决一些他们能够解决的问题。这次北京协和增加了一个YB_BEIJING的PBL，北京开发人员没有把所有需要添加这个PBL系统的Build_F.ini作修改（某个系统Build_F.ini文件里添加这个PBL时也添加的不对，漏写”.PBL”），当编译出现问题的时候，测试人员没有根据过去的经验解决这个问题，而是一遍遍重复编译，导致一个上午都编译不出来，浪费了宝贵的时间。

当绿城发布之后，测试部是否可以再接下来的一两天之内继续走这个程序，争取能在绿城医院暴露问题之前，我们自己先能发现和解决呢！

4、  测试人员对于业务的理解不透彻

目前开发部的现状大家都很清楚，缺乏设计文档不是短期内能够解决的问题。杨杰曾经发了一份邮件，建议目前的测试用例编写和测试工作基于需求用例文档和URTracker里对于测试要点的描述。

SP11的测试时间少，人手紧张是事实，但是对于提交的修改，基于测试用例和测试人员对业务的了解，测试工作不能仅仅是简单的验证出错的地方是否修复了，需求是否实现了，应该能够对相关的上下流程进行测试，因为测试人员在修改的时候，有时候是会顾此失彼的。

我认为，测试人员应该抱着怀疑的态度对待开发人员提交的BUG修复和需求实现。开发人员不是神仙，不能保证修改一定是完美的，也存在按下葫芦起了瓢的情况。