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

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

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

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

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

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

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

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

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

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

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