由于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。

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

建议继续学习：

1. Linux下c/c++项目代码覆盖率的产生方法    (阅读：2065)
2. 单元测试中的Fluent Interface    (阅读：1730)
3. rebar单元测试中源代码的中文乱码问题解决方案    (阅读：1472)
4. Clojure世界：单元测试    (阅读：1459)