web项目和单元测试

由于web程序和一般的软件开发不同,自动化测试的效率和必要性一直较低,因此人工测试一直是web项目的最主要测试手段。

但这并不表示web项目就不需要进行自动化测试。对于web项目而言,自动化测试可以分为单元测试和功能测试。功能测试主要针对具体页面进行测试,个人觉得意义不大,因为既然是针对具体页面进行测试,采用人工测试的方式更为直接,高效,且灵活。当然如果针对某些页面进行的压力测试还是很有必要的。因此以下主要针对单元测试进行讨论。

首先,由于web项目的特殊性,能够进行单元测试的地方也不会很多。一般来说,单元测试会集中在业务逻辑层。

如果是很简单的功能,那做单元测试的必要性就很低。一般来说,需要做单元测试的地方是:逻辑复杂的功能模块。

代码要能够做单元测试,对程序的结构有一定的要求。首先,单元测试的模块必须是个闭合的系统,有固定的输入和输出。因此在系统设计阶段就应该进行充分的考虑:代码的可测试性。

如何做到代码的可测试性呢。主要有以下能力和技巧:

1          把(逻辑)复杂的问题抽象为(数学)模型的能力,这也是最重要的一点。细节上如,将数据库中的数据映射成程序中的数组,针对数组进行处理。

2          好的程序架构。即程序要模块化。单元测试多是针对类或者函数进行。单元测试要求测试对象是个闭合的系统,如果你进行测试的程序块和“外界”有着千丝万缕的联系,那你的程序必然是不可测试的。

3          因为web程序的特殊性,有时候,要做到完全闭合会很困难,或者说要花费很大的精力去改写程序。那这时候,适当的用一些小技巧来实现可测试是必要的。因为测试的目的是为了保证产品质量,如果为了单元测试而延误了工期,那就本末倒置了。具体实现上如,我们可以定义个环境常量,当这个环境常量等于测试模式的时候,就可以做一些特殊的处理。

ok,做到以上几点,你的程序应该可以做单元测试了。进行单元测试的流程贯穿于整个项目的始终。可以参考如下:

A   开发人员在开发和测试过程中,要写足够的测试用例,测试用例应该包含各种有代表性的情况。在进入项目的测试阶段的时候,这些测试用例就应该全部能运行通过。

B   在A之后,程序多数还存在bug。这时候,如果发现新的bug(假定为bug1),那么开发人员要根据产生bug1的情况,写新的测试用例(bug1 test case).

然后修正bug1,并使测试用例bug1 test case运行通过。同时请确保A中的所有测试用例也运行通过。

C   再次发现新的bug(假定为bug2),然后开发人员重复类似于B中的流程。这个时候,请务必确保bug1 test case能运行通过。这就是通常我们提到的“回归测试”,“回归测试”能有效的避免在修正bug的过程中,产生新的bug。

最后,项目相关人员都应该意识到,人的大脑内存是有限的。如果你的项目含有复杂的逻辑,借助好的软件工程方法,才能使程序得到有效的控制。引入单元测试,产品质量才有保证。

posted @ 2009-08-26 23:03  rethink  阅读(770)  评论(1编辑  收藏  举报