通过早期测试弥补不规范软件开发带来的风险

作者：skisky [b]2007年5月9日[/b]

国内很多软件开发公司缺乏项目的规范化管理体制，软件的开发过程类似“作坊式开发”，一些有点规模的软件开发公司虽然建立了一套规范的项目管理体系，但是由于开发的软件规模不大、工期紧等原因，往往是规范让步。这种“作坊式开发”往往给成功开发项目带来很大的风险，项目的失败或者表现为无法实现的不可为、或者表现为开发周期的不可控制、或者表现为项目结果为用户所不认可、或者表现为项目最终的严重亏损，这种失败的惨痛结果可以出乎人们的意料，以至使人无所是从。

项目中应该产生的文档能省则省，甚至没有，如项目计划、进度计划、变更管理文件等；一些项目文档不按时生成，能拖则拖，有些在软件代码开发之前就应该产生的文档到开发结束还不能提供最终的版本，甚至没有。如在进入正式开发之前，从用户处获取准确的需求后，先要进行可行性分析，对于一些无法实现的技术应该仅早对需求进行调整，并制定出一份需求规格说明书，尽可能地分析清楚，哪些是稳定的需求，哪些是易变的需求以及分析人员和客户之间的歧义理解，以便在进行系统设计时，将软件的核心建筑在稳定而全面的需求上。避免在代码开发过程中，由于先期了解不周全，造成需求经常变动，给项目的实施和进度带来很大的影响。

这种类型的项目，往往是一个项目经理带两三个开发人员来完成，开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档，容易造成误解上的偏差，以及缺少有效的监控。同时大部分的系统开发过程由于大量尝试性、重复性工作而变得缓慢，后期调试会出现许多意想不到的大大小小的问题，狼烟四起之时大多数技术人员特别是技术负责人主要工作是“救火”。这样的项目，工程延期往往是普遍现象，“火势太大”情况下会再投入人力。软件开发的特殊性决定了其工程效率与编程人员的数量并不成正比，没有过程文档支持下的项目到了后期，人员的投入反而有可能使工程进度减慢。工程进度失控将直接导致项目亏损，这是显而易见的。同时客户方面由于系统无法按时上线或投入生产，后续的工作不能按计划实施，造成的经济损失将无法估量。

同样没有任何文档支持的项目，若在项目开发的过程中或后期一旦项目组中的成员由于某种原因被调走，整个项目将进入瘫痪状态，没有人可以接手继续。同时对于软件的后期维护也无据可依、无从下手。

很多软件公司都存在着重开发、轻测试的现象，尤其是一些规模不大的项目根本就不安排测试人员参与，有的公司甚至没有自己的测试团队。测试的目的之一就是能够降低客户在使用产品时发生问题的风险，同时也是在有限的时间内将客户使用产品时发生问题的风险降到最小的过程，测试有助于提高软件的质量。一般而言，内部对产品的测试（称为α测试），需要开发人员与独立的测试小组共同参与。开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节（“白盒”是指看得见程序的内部结构）。而独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求（“黑盒”是指看不见程序的内部结构）。很多情况下“黑盒”测试也是由开发人员自己进行的，也不安排开发小组的成员相互测试对方的程序，这种测试自己开发的程序的做法，往往发现不了很多功能和接口方面的问题。这种不成熟的产品直接交付给客户进行验收，验收测试的工作量是显而易见的，验收的结果往往是错误百出，很多功能无法实现，并存在很多低级错误，开发方拿回去修改后也不能保证关闭所有的缺陷，同时在修改的过程中可能会引入新的缺陷，这样在未达到要求的基础下一遍一遍的测试，等于是在帮开发方完成他们之前应该做的事情，不仅加大了工作量，而且项目的进度得不到保障。

所以在软件开发的初期就引入测试，将测试贯穿到软件项目的整个开发过程中是非常有效的，早期介入测试有助于提早发现问题，同时对大幅度的降低项目风险有很大的好处。在软件的需求分析阶段就可以设计出测试计划书，并对需求进行审核、测试，论证需求是否可以满足用户的要求，从而减少需求风险。在设计阶段，可以明确“黑盒”测试的目标，设计出有效的、可以完全覆盖的测试用例，这种针对函数的测试有助于较早期的发现问题，将软件缺陷消灭在开发早期。在编码阶段，进行每日编译、每日测试，测出的软件缺陷在当天就可以处理，从而保证了把缺陷消灭在早期。这时测试与开发已经完美的结合起来，做到测试与开发的同步，并且不相互冲突。由于测试与开发是同步进行的，所以在开发的后期主要进行的就是对开发过程中发现的问题的回归测试。因为在编码阶段软件缺陷就发现的差不多了，所以这时主要的精力可以放在集成测试，性能测试，兼容性测试等一些测试上来。这样项目的进度就可以得到有效的控制，不至于造成很大的风险。