由单元测试看功能自动化测试

最近，在看单元测试框架和研究Junit4的源码，看单元测试框架的目的是为了研究单元测试的测试方法是否可以应用到功能自动化测试上，看Junit源码的目的是写了一段时间的java代码了，可惜现在总感觉无法有一个很好的上升，特别是在接口以及代码规范、模式上面没有很好提高，所以只能通过读源代码的方式提高了，之前读过JDK的源码，但因为不是一个纯粹的产品，所以从根本上也提高不大。

一、Junit的框架分析

Junit应用上而言，没有什么太大的难度，其思想确实值得借鉴：

1、 测试执行模块：Junit的测试单位有：

测试集合(testsuite)：测试集合可以包含若干个测试用例，按顺序排列执行。

测试用例（testcase）:可以说一个测试类就是一个测试用例，每个测试用例，包括若干个测试方法。每个测试用例可以包括：BeforeClass与AfterClass，即用例测试前配置和测试后的清除。

测试方法（testMethod）：测试方法是具体的执行测试的函数。每个方法可以包括before与after，即方法测试前的配置和清除。

分析：在做功能测试框架的时候，也可以采用这种方式，即测试集合+测试用例+测试功能封装。而且测试前配置和清除很重要，在功能测试可以是环境配置和环境恢复等。

   2、测试结果模块：可以从测试集合与单个测试用例为入口执行测试，测试完成后，可以看到测试执行的结果和时间，即执行用例的个数、error的个数和fail的个数，并且能够快速跳转到错误方法的位置。Error和fail的区别在于error是被测试程序的异常。Fail是验证被测试程序的期望结果的失败。

        分析：自动化测试中，结果部分是非常重要的，最好能够有结果统计以及具体结果的链接功能，一定要区分出error和fail，帮助快速定位问题。

        3、测试异常模块：Junit可以使用expected=Exception.class来期待一个预期的异常，即监测输入异常数据，是否能使被测试方法抛出异常。而且我测试了下，当被测试方法中有异常的时候，当前测试方法跳出，但是不影响下面的当前测试方法的测试恢复方法和下面的其他的测试方法。

        分析：在功能框架，测试的稳定性很重要，测试框架的一个作用就是保证一个测试用例执行错误后不会影响到后面的测试用例的执行。测试执行的稳定性是自动化测试的基础。

        4、参数化测试模块：@Parameters指定一个集合存储测试数据列表，主要包括期望值与实际值，然后测试方法遍历列表，这种方式适用于测试方法一样，但参数不一样的形式，理论上是一种数据驱动的思想。

二、让脚本具有“可信赖性”

在单元测试中，有一个很重要的技术是mock与Stub技术，他们的原理都是去替代那些被测试代码所依赖的，但确实不可信赖的东西，例如：你写的一行代码中需要与数据库或者配置文件连接，你是否能保证数据库的连接类与外部资源都没有问题。或者你是否能保证引入的其他的class是没有问题的。如果不能保证的话，这些都是属于测试代码不可信赖。

所以，有一句话说的很好：一个好的测试必须是“值得信赖“的测试，而值得信赖包含两层意思：

1、 当它通过时，我们有信心说被测试代码一定正常工作。

2、 当它失败时，它一定证明被测试代码是错误的。

在功能自动化测试中，我对照“可信赖性”的原则，进行了反思：

1、 外部环境的影响；由于我的自动化测试不仅与软件环境有关，还与硬件设备测试环境有关，所以，这些环境是否能够保证是值得信赖的，即不会影响脚本的运行状况。

2、 封装的应用；我们包括命令行封装和关键字功能封装，命令行封装的好处是防止命令行接口变化导致脚本失败。业务脚本是由关键字功能封装组合而成，是所有脚本公用的，因此保证一定的正确性。其实，从另一个角度说，这也是让自动化测试变得更可控制性。

3、 环境参数与业务逻辑脚本的分离；最近帮软件开发部门搭建自动化测试环境的过程中，遇到的最大一个难题是脚本的移植性问题，很多脚本由于以前涂一时方便，将环境参数写在了脚本里，所以移植的过程，由于拓扑环境差异造成的错误大大增加。

其实，总的来说，我觉得用一句话概括：拥抱变化，让自动化测试变得更可控和更信赖。

总结：个人浅见，知识是相通的，存在即合理，互相借鉴，也许会收到不小的启发。作为一个技术人员，不能局限与技术，如果能够在精于技术的基础上再学习点别的知识，那么技术创造性也许才会提高一些。共勉之~         

——散步的SUN