接口测试在淘宝的应用（转）

　　目前的BS结构的软件层级体系大致如下，对此的功能测试也主要是针对表现层的内容，下图灰色的部分是未测试的内容（占80%的比例）。

　　对于较小型的网站，通过表现层的测试，路径会大致渗透到下面各个层级。但是一个超大型的网站，其层级会有4层甚至更多，每一个层级又可能包含相互关联的不同业务。如同一个城市的自来水系统，如果只测试水龙头里面是否有水，水质是否优良，这显然远远不够。要想点办法对此进行改进，设想如下图。

　　对于底下几层，采用单元测试，持续集成；对于表现层，采用QTP和类似的工具，编写测试代码，设计测试条件，做到大部分的自动化测试。这样以来，测试的覆盖率会大大提升（灰色部分占20%左右）。如此测试，从技术上来看并没有太大的障碍，从成本上来讲，就是需要大批的能写测试代码的技术人员，这些人员的技能丝毫不逊于开发人员，他们需要完成的测试代码量要高于软件本身的代码量。而一旦自动化的功能测试体系建立起来，在软件的重构和发展的过程中，测试的效率会大大提高。一个成熟的测试体系运转起来就像下图所示了。前图是测试的几个纬度，后图是功能测试的几个组成部分。

　　而整个测试的流程大致如下：（其中安全测试是功能测试的一部分）

二、选用什么样的测试工具

　　基于Java技术的软件代码，有一些比较成熟的测试框架，Junit、Dbunit等等。Junit已经有了很长时间的应用，在JDK1.5之后，其推出了基于annotation的Junit4.4版，使单元测试的代码更加简洁，开发人员可以更加专注于对接口中业务逻辑的校验。Dbunit是一个测试数据的框架，它能够使用excel或xml文件里的数据来对数据库做插入，对比，删除等逻辑，可以完成数据的生成和校验。Junit和Dbunit结合使用就可以完成业务逻辑和数据方面的校验。

　　当一个项目的测试代码编写完毕的时候，我们需要对此进行持续集成，业界总是有一些慷慨无私的人来帮助可爱的开发人员，CruiseControl是一个不错的持续集成工具。每当有代码提交到版本管理工具的时候，它都不知疲倦的执行测试代码，通过邮件和IM软件告诉我们，哪些通过测试了，哪些发现问题了。这个时候你可以相当有自信的说“一切尽在掌握”，这神情会比刘德华都要帅。

　　但对于一个大型的网站来说，其单元测试也非测试“helloWorld”一样如此简单，最大的难题是解决代码之间的依赖性。淘宝网主演主要的架构是基于 Spring的，一般的系统分至少三层，业务层、逻辑层、持久层。spring架构下这三层通过配置文件来装载起来，持久层依赖于自己的配置文件、逻辑层依赖于自己的和持久层的、业务层依赖于三种配置文件。如果有发送邮件，调用外部接口等，还需要相应的配置文件和接口服务器。这种情况下，要做一个单元测试，需要配置很多东西，任何一个配置有误都无法启动spring容器，而且这些配置都在xml文件里面，内容是否正确无法自动检测。要做业务层的测试，不是一个容易的事情。其中持久层的东西相对固定，需要配置的文件也较少，相比较而言，这一层测试很容易完成，逻辑层和业务层的测试难度成指数性增长。

　　三、需要什么样的工作流程

　　我们不要提测试驱动开发，或者TDD之类的名词，适合我们的就是最好的，或许我们可以成为测试开发并驾齐驱。接口测试的工程师我们叫做测试开发工程师，在项目启动的时候就要参与进来，要做需求的分析，系统设计，在开发人员编写功能代码的同时，我们在编写测试代码，无所谓谁快谁慢，写好功能代码就测试，或者写好测试代码就写功能实现。当编码完毕的时候，也是接口测试完毕的时候，然后测试开发工程师写一份测试报告，送给功能测试工程师，告诉他们哪些东西我们测试过，哪些东西需要重点关注。

　　当系统发布运行之后，功能修改的时候我们修改测试代码，平时我们就重点关注CruiseControl，一旦它报错，那一定是有些代码出问题了，Just fix it！

　　四、需要什么样的规范

　　Java编码规范想必都比较清楚，OK，去做好它。另外请在注释里面写清楚测试的场景，输入输出，异常情况。测试代码的可读性一定要高于功能代码。

　　五、到底是单元测试还是接口测试

　　OK，看这么多想必都搞糊涂了，我们测的是接口，写的是单元测试的代码，爱叫什么是什么吧。