如何保证单元测试的执行效果？

　　marysnow：51Testing软件测试网 IkY%TB;u6T&J$h

　　单元测试的重要性，相信大家都清楚。可是往往很多的国内的中小企业难以实施单元测试，原因是开发人员认为写测试脚本浪费时间。那么我说说我们公司的做法：51Testing软件测试网a:Iw1KH#l(fZ

　　1）对于较复杂的单元，要求写非常详细的设计文档，同时进行组内的评审，来发现设计上的缺陷。

　　2）然后开发人员依据设计文档或功能要求，来编写单元测试用例。（初期需要测试人员指导一下如何写测试用例），测试用例要经过测试人员的审查，看是否有遗漏。51Testing软件测试网|U1Rj1^[

　　3）然后开始编写代码，编写完成后，交给另一个开发人员按照用例去执行测试，类似黑盒的做法，来逐一验证每个测试项。

8\:}#ex"zD+~V0　　4）对于复杂的类需要借助工具如junit来进行单元测试，以发现更多的BUG。

8{S/B9v8z0　　5）将每个项目编写的单元脚本放到共享库中，以后再有类似的功能，只需要改里面的参数即可，非常方便。51Testing软件测试网"oB*a%I9n(@'n V_!x2l'b

　　单元测试在执行时，要交叉执行，这样效率往往比较高。

　　总结：

elax)Plf0　　在初期时，我们主要是以测试用例+黑盒为主来做单元测试，等养成习惯后，就可以直接写测试脚本来做单元测试。很多开发人员一般都认为编译通过就没有问题了，而且只考虑正常情况，不考虑异常情况，所以通过写用例的方法，可以帮助开发人员梳理思路，知道如何来验证。51Testing软件测试网7l3Y;U3wB
R

C*hW Wmx'IuvH0　　对于单元测试的缺陷要及时整理总结，大部分的BUG都是自己编程习惯或粗心造成的。所以要总结出哪类BUG最多，来出台相应的编码规范和开发规范，以便减小类似BUG再出现。

#MeS*W2w}0　　缺陷在记录时，有的开发人员觉写得麻烦，我们可以截屏的方式来保存，或者大家都能看懂的一些符号或语言来表示，等到后期测试人员再进行详细整理。51Testing软件测试网NGBl
uh

;N6I/o;@_? tIF-\0　　对于用例的格式没有拘限，只要写清楚出测试项，预期结果，实际结果就行。51Testing软件测试网"zE/c4w+y6X

　　前期在写测试用例时，测试人员多参与指导，教给开发人员怎么写用例，怎么选取测试数据（ 正常值，异常值，边界值）。（比如讲解一些测试方法等价类，边界值，分支覆盖，循环覆盖，基本路径等）

a [5V4Vfj-bLEc0　　单元测试执行时要注意的内容：

lt)d-ph p0　　1、单元测试越早进行越好。在TDD方法中，Kent甚至认为开发团队应该遵行“先写测试、再写代码”的编程途径。

RH+|x
W_'`0　　2、对于修改过的代码应该重做单元测试，以保证对已发现错误的修改没有引入新的错误。51Testing软件测试网0@r'w$m(u0Y

　　3、测试人员的测试用例应经过审核，如有必要应经过会议评审，以保证测试用例的质量。51Testing软件测试网S#Ik.cS"{ zv/jV

]0gz4_q4Z [0　　4、当测试用例的测试结果与设计规格说明上的预期结果不一致时，测试人员应如实记录实际的测试结果。

hJD7@X0　　5、单元测试应该依据《软件详细设计规格说明》进行，而不要只看代码，不看设计文档。因为只查代码，仅仅能验证代码有没有做某件事，而不能验证它应不应该做这件事。

lD*TG"F*U^go4D0　　6、单元测试应注意选择好被测软件单元的大小。软件单元划分太大，那么内部逻辑和程序结构就会变得很复杂，造成测试用例过于繁多，令用例设计和评审人员疲惫不堪；而软件单元划分太细会造成测试工作太繁琐，失去效率。工程实践中要适当把握好划分原则，不能过于拘泥。

3tv(J3oHA7M:B0　　7、注意使用单元测试工具，可以替代一些重复性的劳动。51Testing软件测试网_w9rS B e8`

H9J uBn4y]q0　　我们在实施单元测试前期遇到很多问题，但是发现其实开发人员都知道单元测试很重要，只是没有正确的引导和教给他们方法而异。现在我们的开发人员都会主动使用junit来进行测试。（习惯慢慢养成）