金融企业软件测试中心筹备书－成立时机篇

         测试工作及相关职责是采用虚拟化团队方式来运作，还是独立出测试中心来负责，这个严格依赖于一个企业的情况而定，没有固定的模式可以套用。那么测试中心合适需要独立出来，需要具备什么样的先机条件呢？笔者认为从架构的演化历史中，看出一些经验。

1、架构的演进式发展

第一阶段：

         公司A刚刚开始创业，正在打市场，但开始阶段用户量和交易量都很小，技术团队也只有1个人，出于成本考虑，在一台机器上使用LAMP架构部署所有软件，已经完全满足了公司的全部需求。

第二阶段：

         公司业务开始有所起色，原有的架构支撑起来已经有点儿捉襟见肘，技术团队已经扩充到了3个人，决定在原有的基础上，增加一台机器，进行应用与数据分离，各自独立部署在一台机器上。

第三阶段：

         公司业务有发展了，发现技术又需要变革，这时技术团队已经扩充到了10人左右，决定将原有一台机器上应用服务部署到一个集群中，同时在集群前面增加负载均衡。

第四阶段：

         业务不断发展，应用集群化后，应用相应的速度明显增加，吞吐量也变大的很明显，但慢慢发现经常性出现数据库表锁死，单边账等情况，于是已经扩充到20人的技术团队，开始进行分库、分表、分区操作，情况有所缓解，后又经过讨论研究，决定开始进行读写分离，划分出一个主库，三个从库。

第五阶段：

         当公司业务扩展之后，发现支撑业务的组件越来越多，发现耦合性也越来越强，怎么办呢？扩充到30人的技术团队决定引入消息中间件、SOA架构，来进行应用解耦，对于不重要的交易开始采用异步、或日终批量处理的方式，情况得到大幅缓解。

第六阶段：

         公司发展太快了，公司的知名度已经越来越高，老总已经开始筹备IPO的事项，一天老总找到CTO喝茶，表示技术要跟上业务的发展，绝对不能扯公司的后退，CTO回家后辗转反侧，反复捉摸老板葫芦里到底卖什么药，也在为自己的未来开始担忧，因为这时他已经带领了一百人的团队了，最后一拍脑袋，决定未雨绸缪，开始在现有架构体系上增加分布式缓存，以及搜索引擎。

第七阶段：

         之后一段时间，公司业务运行平稳，技术部门也受到了老板的奖励，公司也如愿上了市，一天老板搞了公司的聚餐，在吃饭间隙，漫不经心的对CTO说“有人说秒杀是个好东西！”，CTO听完犹如晴天霹雳，连忙跟老板表示，技术团队肯定支持，但需要一点点时间。匆匆吃完饭后，立即召集手下技术团队150人连夜开会，群策群力，最终决定，增加前端反向代理服务器，并使用CDN节点，同时对重要交易系统进行微服务设计重构，并同步开发独立秒杀模块。

         几个月后，公司的秒杀活动圆满结束，老板给CTO又涨了薪水，同时技术团队已经扩充到了200人。

         我们可以从上面看到，公司A的架构演变，从单机LAMP到了最后包含集群、负载均衡、读写分离、消息中间件、SOA、分布式缓存、搜索引擎、反向代理、CDN节点的复杂架构，每一步的演化，都是公司业务的不断发展推进的结果，那如果一开始就使用这个复杂的架构可以吗？答案是不可以，因为没有业务需要，公司也不会允许200人的技术团队来维护本来就不多的业务。

3.2、测试的演进式发展

         从架构的演进式发展维度，我们也可以摸索出测试的演进式发展，以及何时成立独立的测试中心。

(1)、混沌时期

         假设公司一开始之后两个项目组，每个项目组各负责一个系统的开发工作，业务需求变化也不是特别频繁，每个项目组也大概各10人左右，这种情况下，可能连独立的测试人员都不用，直接开发兼职测试，也就是全能型开发人员，从需求到运维的所有环节，都自己搞定，系统也运行的不错。这时不需要单独的测试人员，当然更不需要单独的测试团队。

(2)、初现雏形

         后来公司业务发展越来越大，项目组也越来越多，逐渐可能有10几个项目组，而每个项目的上线时间也都不相同，相互之间的交易调用等依赖也越来越多，而一些公共的测试环节需要独立出来统一管理，例如测试环境准备与维护，测试整体的统一组织等，给予这个情况，老板决定成立一个独立的测试部门，来进行统一协调管理，而这个部门的主要职责目前只有两块：

         a、测试环境的整理规划、分配、维护，测试版本的安装等相关环境管理实施事项

         b、年度测试计划编制、测试整体组织、实施

         到这时，测试中心雏形其实已经具备，只不过暂时是以独立测试部门的形式，还不具备中心的条件。

(3)、成长壮大

         公司的业务开始越来越多，业务种类也越来越复杂，技术团队开发了的系统已经达到了几十个，相互之间的协调配合工作越来越多，而各系统开发周期不一、投产点各不相同，配合其他系统改造量也逐步上升，甚至出现了要配合公司外系统的改造与测试支持，同时老板为了降低成本，决定在几个二线城市成立软件开发中心，导致配合协调难度极具增大，原有的测试部门疲于应对，也最终无法保证上线版本质量，生产上已经出了几次严重缺陷，对公司造成了很恶劣的影响。CTO找到测试部门主管多次商议，最终决定将测试部门大幅增加人员，以保证测试质量，同时对原有的职责进行扩充，增加专业的性能测试小组，功能测试小组，并将原有的人员划分成环境小组和测试管理小组，有效的解决眼下的危机。

(4)、独立自治

         在现有的体系下运行了一年后，发现逐步又有新问题出现，因为考核原因，测试人员与开发人员一同考核，而长期的工作同事关系，导致测试人员往往碍于情面不会通过正常途径完全暴露跟自己熟悉的开发人员的问题，经常采取私下沟通的方式进行，因为测试部门还挂靠在某一个开发中心下面，涉及到跨中心的测试协调上，仍无法站在整体的角度进行组织和协调，为测试质量带来了隐患。另外性能测试方面，经验积累没有完全应用到所有项目组上，性能测试小组疲于应对不断的测试任务，且本中心的任务较多，导致生产上缺陷又开始有增多的趋势，这时老板看到了这个情况，详细听取了CTO与测试部门主管的工作汇报，老板沉默片刻后，一拍桌子，口中蹦出两个字“分家”，自此测试部门完全独立出来，与原有的开发中心并列，不再是从属关系，独立考核，以前的四个小组，也发展成四个独立团队，并扩充了人员规模，生产上的缺陷终于又下来了，自此，测试中心完全成立。

         从上面的演化式的发展，我们总结出以下几个情况需考虑成立测试中心：

         (1)、技术部门下属项目组已经超过十个

         (2)、开发部门异地办公，甚至是在不同城市

         (3)、公司生产上的问题呈现出上升的趋势

         (4)、用户量在可预期的未来会出现大幅增长，对性能指标要求变得越来越高

         (5)、各项目组内部测试人员忙闲不均，部门壁垒十分严重，无法平衡

         (6)、技术部门要大力开展自动化测试

         在任何公司，包括任何体制，都是问题推动解决方案，加上一定程度的提前预判和未雨绸缪，故有信心做大做强的公司，在一定的发展阶段后，必然要成立独立的测试中心，以为公司软件质量保驾护航。