单元测试的一些酌见 软件测试
自从从事这个行业以来，积累了一些经验，今天一吐为快，和大家交流一下
1、对于一个项目，应该怎样划分在项目中需要测试的类和方法?
举个例子，一个基于被封装后的struts和EJB项目，哪些需要测试?在我看来，大而全是没有必要的。
个人觉得，Action的单元测试属于比较没有用处的一个。因为在画面疏通的过程中，担当者对Action的测试会更加的仔细一些，基本上可以替代非常麻烦的Action单元测试。同时对于Form的测试在没有特殊的方法追加的情况下，也可以省略掉。
然后是Dao层的测试是需要做的，但是针对非框架组成部分的成员来说，测试SQL语句应该就足够了。CMP以及共通Dao的相关测试应该由框架来保证。
然后是service层的测试，用来做框架内部调用的代码的测试可以主动地忽略掉，由框架开发者做出足够的测试就可以了。只针对业务逻辑的相关方法进行测试。在这里顺便提一提设计上的一个问题。如果有通用的业务逻辑处理的话，建议直接使用工具类的形式来提供，而不要使用父类方法然后子类继承的方式，非常的不利于单元测试。(有不同意见的可以批评指正。)
2、由谁来完成测试类?
我比较倾向于测试和功能代码的担当者不要是一个人。并且写测试的人要比写代码的人更加的熟悉详细设计。写测试和代码的人不一定是详细设计者，写代码的人可以看着详细设计写代码，不一定要非常的熟悉设计者的思路，完成详细设计的功能就可以了(当然，这个是相对的)。但是写测试的人却要清楚的知道每一步发生了什么，输入了什么样的对象，得到了什么样的对象，中间会有什么样的处理。
首先，测试的工作量一点也不小，绝对不是捎带手就能做了的。基本上大一点的业务出现变更的时候，原来的对于该项逻辑的单元测试代码返工量是会比较大的。如果想要做好修复BUG或者是业务变更后的单元测试，耗费的时间比修复BUG和业务变更的时间长很多。对于这个说法，我不知道其他人是否也是这样认为的?当然，在项目组长给你足够的时间的情况下，这个问题不是问题。
其次，当测试和功能代码的担当者分开之后，在项目里面，对于同一块业务，就有了至少两个人熟悉，不会出现只有一个人很明白，其他人都不清楚的尴尬局面。
第三，旁观者清的道理。写测试的和写功能代码的人互相都会有想不全面的地方，有一定的互补性。这样的测试，比较能够测试出代码中的冗余代码。
基本上我现在接触到的项目没有一个符合TDD的要求。有了解TDD的前辈请对我前面的观点进行无情的批判和打击，谢谢。
4、 在任务分配中，测试代码做成需要的时间和功能代码做成需要的时间比例多少是合适的?
个人认为测试和功能代码的时间配比成2:1是一点也不过分的。在大的业务逻辑里面，测试数据的准备需要花很长的时间。
文章来源于领测软件测试网 https://www.ltesting.net/
