传统的测试方法一般通过web页面进行测试，这样做的好处很多，例如：

　　1）实现比较简单，只要有测试用例任何人都可以操作。

　　2）测试的结果更直观，如果测试质量足够好，就能代表这个产品就可以发布了，是质量保证的一个非常重要的阶段。

　　当然，也有很多局限性，要不也没有这么多人想破头皮采用了其它的方法了，这里列举3个问题：

　　1）测试介入的时间延后，必须要等web页面完全展现后才能测试，而从实际的项目中来看，java代码和web页面的集成是需要一段时间的，这也往往导致测试开始的时间要比计划的时间延后。

　　2）发现问题的时间延后，一些关系到前后模块的或影响到架构的方法要到手工测试的时候才能测试出来，这样有可能导致返工很多。

　　3）测试的效率比较低，web页面存在很多本次测试中并不关心的内容，这些内容的部暑，展现等都需要花很多的资源。

　　正是由于以上的一些问题，常常导致项目的延期发布.那如何预防项目的延后发展呢，答案只有一个，尽早测试，不停地测试。

　　尽早测试：

　　Manager层主要关注业务逻辑的测试，但是在web页面之前就可以测试了，Service层主要是为Manager层服务的一些基础方法的实现，跟测试微软发布的一些API差不多。这两次测试的中心思想是保证上层应用可以正确使用，有了前面的这两层测试必然是保证了整个产品的质量，也将必然缩短web层的测试时间。

　　不停地测试：

　　不停地测试必然用到自动化，在Service层测试，用户中心项目已经得到了很好的应用，接下来可以在manager层的测试更加自动化。

　　Manager层和Service层测试的重点和难点：

　　Manager层的测试主要测试的重点是业务逻辑，但又关系到接口的定义，比如说要测试一个登录这个业务，首先要编写测试用例，测试用例的来源来自于业务UC，然后又要了解登录的接口实现，这样就要求开发人员在编写代码之前先定义好接口的实现，以便测试代码和开发代码同步实现，这样必须要提高前期设计文档的质量，一旦接口的设计变动，将影响测试代码的实现。

　　Service层的代码主要涉及到物理上的数据读写，业务逻辑相对简单，前期的准备是接口的定义要准确，这一点跟manager层测试一样。另外需要准备前期的各类测试数据，测试的重点主要集中在数据状态的完整性。