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。
最后,项目相关人员都应该意识到,人的大脑内存是有限的。如果你的项目含有复杂的逻辑,借助好的软件工程方法,才能使程序得到有效的控制。引入单元测试,产品质量才有保证。
文章来源于领测软件测试网 https://www.ltesting.net/