【导读】本文简要说明了IBSS软件项目中的测试需要经历的过程和其中需要注意的问题。

IBSS是一个庞大的软件项目，其开发周期长，参与人员众多，实施难度较大。要很好的控制到整个软件开发的质量，肯定就需要一个非常强势的软件测试部门进行严格、有效的监督与管理，达成完善的闭环控制管理才能做到。

另外有一点必须注意到的，在IBSS的将近两年的开发过程当中，开发人员的进进出出十分之频繁。据我个人的观察，普信开发组的人员至少已经陆续的调换了三分之二。如此之高的人员流动，IBSS的软件质量的控制难度无疑又增加了不少。

说实在话，在这种情况下面，普信开发控制能够做成这样的程度，也真是不容易了。虽然也像微软一样，隔三差五的要打些小补丁啦，做些紧急更新了，也是无伤大雅了。

但是，如果要做到像上海贝尔的林锐博士所倡导的“将软件质量内嵌在开发过程当中”，或者达成韩国三星集团董事长李健熙所要求的“产品零缺陷，抛弃客服维护部门”那样的境界，软件开发管理还要走相当相当漫长的一段路。

就测试的分类来讲，大体有以下几种。

◆就开发而言：代码自检，代码走查，单元测试，集成测试，功能测试；

◆就系统而言：功能测试，性能测试，压力测试，用户测试。

就我参与整个IBSS的开发历程来看，前面的两个步骤是完全忽略了的。为什么？因为没有时间。省公司这把达摩克利斯宝剑在上方高悬，催命似的要求赶快，赶快上线。单元测试与集成测试也是进行的比较粗糙，主要是进行了黑盒测试方法学当中的功能测试。

组织了一个测试组，针对开发人员提供的已经实现了的功能清单，逐项逐项的进行验证。通过了划勾，不通过了打叉拿回去重新开发。但是，在功能测试里面，一个相当重要的层面也是忽略掉了，那就是回归测试。也就是这个地方做得不够好了，导致一次重大的功能改进之后，紧接着就是多个的紧急更新了。

特别是当各地上线之后，需求蜂拥而至，任何一个哪怕是条件判断语句的调整都有可能会牵连到其它代码段的应用。“牵一发而动全身”，特别是新加入人员的参与开发，在未完全了解整个程序的运作情况下面，由于代码的封装性并不是做的很好，往往改了一段、一个地方，其它地方就跟着出事了。回归测试没有做好，也没有时间做好，导致了频繁的更新。

这里面，局限于开发时间的压力，我是建议今后我们如果要达成较好的效果，也不妨参照IBSS的做法，直接使用功能测试就好了。虽然投入的成本，回归测试的次数可能会增加；但是，我们面对的是给用户的最终产品，不断的调整优化，总会让用户满意的。

设计时、开发中间以及开发完成之后，都需要用户积极的参与到评审、测试工作当中来。这一点IBSS处理的相对比较好，前期设计当中多次到用户中进行实地调研，考察现有的业务管理应用状况。开发出来的原型系统让用户不断地、反复地进行业务使用测试，发现问题，解决问题。原型也就在一次又一次的迭代过程当中，逐渐的丰满起来；由当初给用户批得一无是处，进化到还可以使用，再发展到比较好用的阶段。

同时也要注意，任何一件事物，都不可能让所有的人都100%的满意的，我们要注意抓住重点。满足了大部分人80%的重大需求，一个软件也就算是可以成功了。对需求的管理，也是蛮令人头痛不已的事情。管得严，得罪不少用户；管得松，害死开发的弟兄们。这中间有一个平衡的度，很讲究处理的艺术与方法的。

IBSS软件系统的整体性能测试我没有参加，也不知道最终是用了什么指标参数来量化，不过。可能是对于软件的扩展性估计不足吧，在IBSS运行了不足一年时间后，广州局的性能比较的不足了。据说又开始评估了，不知道最终的结果会怎样。

压力测试倒是参与了几回，广州番禺、中山、湛江、肇庆，基本上是使用人海战术，组织一大堆人同时登录上系统进行相关的操作，验证系统的负荷情况。这种大规模人力的测试，其效果最终如何还有待于评价。主要是看测试时间点控制的好不好，测试用例准备的周不周全。尤其是后者没做好的话，如果用户只是登录上系统后挂机，什么也不做的话，对系统也不会增加多少压力的。据我所知，几次压力测试都没有详细的用例，很多时候用户登录了系统也不知道做些什么。基本上，几个点测试出来的结果都是几近于没有压力的，呵呵，挺好。

最终的用户测试是挺重要的，用新系统去模拟旧系统的业务功能实现，看能否满足日常使用的需求。这也是用户要把的最后一道关卡，作为验收系统的时候使用。这种测试，需要完全以业务人员的使用角度来组织，从使用的正确性、方便性、容错性来考量。用户需要的不是解释，而是真正可用的产品。

整个测试的过程，除了性能测试的时候邮科院使用了部分的自动化工具外，没有使用什么辅助性的工具来提高测试效率。虽然我们有Rational工具，但是实在是没有杰出的测试人才来组织；同时，更为重要的是，我们没有时间。一切都被逼着走，软件开发的进度管理，纯粹是演化成为了长官意志所要求的deadline往前的倒推；如果上一个deadline不行的话，就又有一个新的deadline搞出来了。这也是整个中国整个软件业的悲哀，暂且就放过不提了。(在这个过程当中，我们也练就了坚强的神经，清楚明白市场人员或者是管理人员承诺的事情是可以部分实现，或者是完全不实现的。呵呵，这个东西也就私下里一说罢了。)

最近有位朋友来找我，看是否有合适的软件测试人才可以推荐下。我想了想说，特定行业的测试人员只能由自己从项目当中培养出来的。来了空降兵的话，也只能在方法学和组织上面给项目带来一些帮助；实际的东西，还是必须要由熟悉本行业业务、熟悉计算机技术的人员去做的。包括最基本的测试用例设计、评审、执行、反馈，测试质量的把关、验收等等，非精深的业务人员没有可能做得到的。

所以，我们要注意培养自己需要的电信软件测试人才，累积自己的业务知识，提高自己的业务能力。