二、重要性

目前的软件开发更加的系统性，早已脱离了一人或几个人小作坊式的工作模式，注重的功能性和性能性也越来越多，而针对金融企业，成立独立测试中心的目的就是为了保证软件质量，那是否真的有必要成立一个独立的测试中心吗？它的重要性和价值到底体现在哪里呢？

2.1、环境的统一管理

在银行业整个软件体系架构中，系统的规模可能在几百个左右，如果用微服务的方式进行改造和重新划分，则会有几千个组件，而如此数量级的系统组件，在投产时间点上错中复杂，相互配合起来也是十分庞杂，如何保证每个系统版本能在符合条件的测试环境上进行测试将是一个棘手的问题。

诚然，测试环境的机器配置，不论是在任何公司都无法与生产环境想媲美，这主要是出于成本的考虑，那么如何利用有限的资源，来保证可靠的测试效果呢？那么就需要测试环境的统一管理，按需分配，保证整体的环境可用性。

另外，从专业性的角度，统一的事项交给专业的团队做有助于效率的大幅度提升，避免了各个系统项目组单独分出人力做整体层面的重复性工作，同时，也利于版本的统一管理。

2.2、跨系统组织和协调

如果一个公司只有几个系统，且都在统一地点办公，则没有必要成立测试中心，需要的时候几个系统人员坐在一起开个会就解决了，但如果不是这种情况，系统数目众多，划分出了不同的软件开发中心，各个中心所在的办公城市都不一样，这时沟通协调的成本将大幅增加，跨部门的协调在任何大型组织中来说都是极其困难的事情。

虽然管理学家经常强调打破部门壁垒，消除部门利益，但在实际工作情况中，部门壁垒依然坚实存在，想要有不同利益诉求的不同部门协调合作沟通，必须要抽象出一个上层部门来进行统一协调和沟通，在测试工作环节中，该部门的角色则由测试中心来担任。

如银行业每年年终都会有一项固定的重要测试，年终结转测试，也就是算账出报表，看一年的盈利情况以及资产负债情况等，类似于这种测试，甚至都没有主牵头的系统，如果没有测试中心的统一组织，测试情况和生产实施效果无法想象。

2.3、测试技术的创新

独立的团队专注做测试，才能有效的形成测试经验的积累，才会导致测试技术的创新。不论是功能测试还是性能测试，经验的积累至关重要。丰富的经验可以避免很多弯路，同时，相似的系统测试经验，也可以举一反三的用在同类型的系统上，对于性能测试来说，由于偏注在技术层面，重要的测试内容是测试指标是否符合要求，技术经验的积累，更容易应用在不同的系统中间。

当经验积累到一定的程度，会引发技术的创新，如测试工具的创新，测试方法模式的创新等等，这些创新又会大幅提高测试的效率，保证整体的测试质量。

2.4、测试人力资源的平衡

当企业采取项目组制的工作模式，每个项目组必然要负责软件全生命周期的全部环节管理工作，测试也其中，而测试人员在整个项目组人员组成中又占据了不小的比例，如果某个系统的版本密集，需求量旺盛，测试人员的工作量是饱和的，但如果一段时间内无大版本上线，则会出现人力资源浪费的情况，反之如果一个系统要出现大规模重构或重大需求变更是，原有的测试人力资源就会无法满足工作量的需求。这时如果 A 项目组想从 B 项目组借人来完成工作，基本是不可能的，给予以下两种考量，B 不会借人给 A 项目组：

(1)、B 项目当前本身也比较忙碌，无资源外借

(2)、B 项目目前比较空闲，人是过量的，但如果人员外借，就相当于想所有人宣布该项目组工作不饱满，第二年的预算申请就会变得困难、以及产生很多消极影响

解决此问题，唯有测试人员集中管理，统一分配，这样才能平衡各系统、各版本不同时期的测试人员需求问题。

三、成立时机

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

3.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)、技术部门要大力开展自动化测试

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