标签: 自动化测试 、个人总结、朝花夕拾
1、对单元测试框架的理解：不理解为什么我加了@Test注解，测试用例却不会被执行？
单元测试可以分为JUNIT3.X和JUNIT4两个版本，这两个版本在那使用的时候有一定的区别。JUINT3.X需要继承Junit框架自带的TestCase类，并且所有要执行的用例必须以test开头，比如testAddUser，testUpdateUser 。通过setUp和tearDown方法执行初始化和其他工作。 而Junit4则更灵活些，主要通过@Test ，@Ignore，@Before ，@After，@AfterClass ，@BeforeClass 注解实现。
个人的建议是测试用例以** Test，方法名为test **,并且加上@Test注解。在编写用例的时候，不要把两种版本的JUNIT给搞混了，不然可能导致@Test注解失效。
2、对单元测试用例的理解：之前工作基本上不写单元测试，写的几个单元测试用例也覆盖的不是很全。没有体会到单元测试的真正含义。
一开始写的测试用例特别的简单，基本上没有封装、或者是简单的封装。认为所有的用例都不会被重用，所以只封装了一些很简单的方法。到后来的时候，发现了自己代码的弊端。有时候用例稍微有点不一样，就需要写很多代码。
后来总结除了一个适合自己的方案，就是所有的方法都尽量传入bean,并且对这个bean的每一个属性进行判断。如果这个属性为空，那么就给默认值……这个过程很是痛苦，但是实际证明这个确实给我们带来了不少的便利。
3、对于重构的理解： 自己写的垃圾代码，还是要自己含着泪去改的。从头到尾改了好几个版本，每一个版本都对重构有了更好的理解。修改了很多的魔法数字，重复代码等坏味道，是的自己的项目结构，和代码质量趋向更合理。平时在写业务代码的时候，可能项目催的急，草草了事就交付了。自动化项目不是业务代码，对时间的要求没有那么高，可以尽情的发挥自己的能力……但是也还有很大的不足，有时候业务上突然修改一点，自己的代码改动就特别大，需要好好学想一想。
4、对于StackOverFlow的的定位和解决。在执行测试用例的时候，遇到一个特别诡异的问题。代码不能向下执行一行，控制台没有任何输出，只有Test用例的圈一直转,打断点一步一步调试也没有发现问题所有。只能才有最基础的* 控制变量法 *，最后发现问题是出在构造函数上。构造行数出现了相互依赖的情况。Class B 作为Class A的属性，并且有初始化方法；Class A 作为Class C的属性，并且有初始化方法；Class C 作为Class B的属性，并且有初始化方法；没有抛出StackOverflow的主要原因是服务器的内存太大……简单的问题，以后尽量不要重犯