但是手动测试存在的问题比它所带来的好处要多得多。手动测试可能引入错误，人为的输入错误很容易发生，尤其在数据量大的情况下；大量重复性的手动测试可能成本较高，如果考虑软件发生改动而需要重复手动测试的情况，这个成本还会更高；手动测试的覆盖面不广，只能够测试系统的输入和输出；没有办法对组件进行隔离的测试，从而导致发现问题和解决问题的成本都太高。
基于上面的讨论，我们应该看到，测试应该做到自动化。虽然一开始测试自动化的成本较高，但是从整个的开发过程来看，自动化测试所产生的价值远远超过其成本。
自动化测试的范围
那么，到底有哪些东西是需要纳入到自动化测试的范围的呢？例如，对于一个典型的分层应用来说，就有数据库层、数据库访问层，业务逻辑层、界面控制层、界面层。这些层次的测试特点各不相同，哪些应该进行自动化测试呢？最理想的情况是全部。测试一切可能是测试的基本原则，让一切测试都变成自动化则是测试驱动开发的准则。
应该承认，建立自动化测试需要付出成本，有些自动化测试成本较低，有些则较高。例如，对业务方法的自动化测试相对容易，对关联到数据库的业务方法的测试则繁琐一些，因为你需要处理更多的情况。而界面的自动化测试则较困难，因为界面涉及到大量的人机交互，手动测试是非常简单的，但是自动化测试则相当的困难。
那么，我们就来看看，像界面测试这样的成本高昂的测试需不需要进行自动化呢？我们拿驻留的Web界面来作为人机交互界面的范例。
首先，按照分层的原则，界面的层次上不应该拥有业务逻辑，界面层负责的事情是收集用户的动作，将用户的动作请求委托给后端的业务层，并对动作进行响应。所以，和业务相关的逻辑已经被剥离到了业务层了。它的自动化测试属于业务层。同时，我们还发现，在测试的推动下，软件的结构变得更加的合理。
其次，虽然业务逻辑大量的迁移出界面层，但是界面层中还有状态，还有控制逻辑。这些因素都是和界面的控制的表现息息相关的。既然有逻辑，就需要测试。根据MVC的思路，界面层中包含了模型、视图和控制器。模型是对业务层数据的封装，在J2EE的应用中，可能是普通的JavaBean，也可能是离线的数据封装，或是简单的数据集合。视图负责表现模型，而控制器的职责则比较多，它需要负责处理和检查请求参数，负责调用业务对象并传递请求中所包含的数据，负责创建模型，负责生成视图并把模型传递给它。
所以，在一个真正的MVC界面设计中，测试的重点在于控制器。模型的测试是很容易的，大部分的模型仅仅包含了数据，所以甚至都不需要测试。一个完美的视图，它应该没有包含任何的逻辑，仅仅只是将模型以某种方式表现出来而已。一个设计优秀的视图，可以很容易的进行替换，而不会造成任何的影响。例如，一个JSP视图可以用一个XSLT视图进行替换。所以，结构合理的视图也是不需要测试的（但对页面要素的检查是必要的）。注意，这里的讨论也同样表明，测试驱动设计向合理的方向发展。
大部分的控制器都是基于servlet技术的，servlet技术是典型的容器内应用，这使得Junit不容易使用。而Cactus能够解决这个问题，它对Junit进行了扩展，提供了大量的预置功能，简化了request、response、session的使用，Cactus通过Redirector Proxy，建立了一个测试客户端和测试服务端模型，来实现基于容器内的测试。下图是典型的Servlet的结构图：
文章来源于领测软件测试网 https://www.ltesting.net/
