随着业务的逐步稳定，对于接口的改动也会逐渐变少。更多的是对业务逻辑的优化，功能实现的完善。对于测试来说，重复繁琐的功能测试不仅效率低下，而且耗费一定的人力资源。笔者支持的信息流业务下的一个图文管理平台就是一个功能较为完善，系统较为稳定的后台平台。每次平台新增一些小的功能，或者对某些模块做优化时，都会一定程度上影响其他模块。每次回归测试，甚至比新增的功能测试点还耗时，而且还不敢保证没有漏测的地方。因此，如何提升测试效率，保证回归测试的全面性和准确性，接口自动化测试是一种有效的手段。目前，有不少成熟的接口自动化测试框架可供使用，如junit4，httprunner等，不过，这些框架并不能满足所有的业务场景。因此，为了能够更灵活的将这些框架应用在具体的业务场景下，同时也进一步加深对框架的理解，这就有必要扩展这些框架，定义业务测试所需要的测试行为。基于此，笔者选择junit4框架，就如何扩展并搭建起一个自定义测试行为的接口自动化框架，和大家聊聊。
为什么是junit4框架？junit4作为一个开源的单元测试框架，正迅速成为java单元测试的标准框架。C++，python，php等语言都有了对应的xunit框架，这就便于语言之间的切换，降低了学习成本。此外，junit4便于二次开发，在其基础之上能够很容易的扩展框架。junit4的代码量也不是很大，以其高密度的设计模式和灵活性使得大家对junit框架评价很高。最后，junit开源社区也能够为初学者提供不错的学习文档以及问题解答。当然，由于笔者常使用java语言，这也缩小了选择范围。
在搭建测试框架之前，我们需要搞明白，接口自动化测试框架应该由哪些部分构建。一般情况下，接口自动化测试框架由数据驱动、接口执行驱动、调度器、结果验证以及结果报告五部分组成。接口常指应用程序编程接口，具体表现形式如：http接口请求、dubbo接口请求等。所以，接口执行驱动就是涉及http或者https协议的请求构建。那么数据驱动又是什么了，其实就是测试用例集合的管理，在测试运行时，用来加载成可执行的测试用例。接着，所谓的调度器则是将数据驱动和接口执行驱动组合起来的桥梁，简单来说，就是将http等接口的请求功能和测试数据结合起来，并执行。最后，结果验证以及结果报告不难理解，主要用于验证预期结果并将测试结果展现出来的模块。在初步了解了接口自动化测试框架搭建的五个模块后，接下来以junit4为基础框架，基于上述五个模块维度去展开讨论如何搭建接口自动化测试框架。
既然选择了junit4框架作为基础扩展框架，那么就有必要对junit4的工作原理有一定的了解。junit4工作原理本身涉及到很多知识，光从源码分析就能写出长篇大论。本文重点则在于如何扩展junit4框架，以搭建自定义的接口自动化测试框架。因此，接下来对其工作原理做出简要的介绍，以便大家快速进入状态。简单来说，junit4通过FrameworkMethod类去定义需要运行的测试用例，然后调用BlockJUnit4ClassRunner类中的computeTestMethods()方法加载出定义好的测试用例。接着，调用BlockJUnit4ClassRunner类中的methodInvoker()方法，触发测试用例的真正执行单元Statement，通过调用该执行单元类的evaluate()方法，执行具体的case。最后，调用Assert类中相关方法对测试用例中的预期结果做对比验证，获取测试用例运行结果。到此，junit4的基本原理介绍完毕。细心的朋友们会发现，上面介绍的几个基础类一定大有用处。事实上，对于上述基础类的继承与方法覆写，就可以轻松实现对junit4框架的扩展。
数据驱动作为管理测试用例并提供测试数据的源头，需要直观、便于扩展，便于维护。常见的测试用例管理有excel、xml、数据库等形式，这里，笔者选择excel作为管理测试用例数据的数据驱动源，是因为在excel上便于维护和扩展测试用例，而且，能够将测试用例更好地融入到笔者搭建的web平台中，以实现友好的前后端交互。Excel作为数据驱动的选择，如何管理测试用例了，这里提供两种方案。方案一：以每个excel文件为单元，作为一个接口的测试用例集合；在每个文件中，每行记录作为一个具体的测试用例，表示一个具体的业务测试场景；具体来说，每行记录包含接口的url、请求类型、请求参数、预期结果等。方案二：一个excel文件作为所有接口的测试用例集合，excel文件中的第一个sheet表格中每行记录表示一个接口的测试用例集，然后每个接口的测试用例集中具体的业务测试场景对应于excel中剩余每个sheet表格。当然，选择可以更多，这个大家可以自行根据需要扩展。数据驱动一个重要功能就是将excel中的具体业务测试场景加载成可执行的测试方法，这时就需要扩展junit4框架的FrameworkMethod类，自定义出我们需要执行的测试用例方法，也就是将excel中的每行记录定义成一个TestCase，每个接口对应的所有测试用例对应为一个TestSuite集。从下方源码中可以看出，TestCase即相当于junit4中的测试方法。
事实上，每个TestCase对应着一个具体的http请求，通过组合不同的参数，以期验证不同的业务场景。因此，接口执行驱动就是对不同的TestCase代表的url执行http请求。前面提到过，测试用例的真正执行单元是Statement类，因此，只需要继承Statement类，覆写唯一的evaluate()方法，在evaluate()方法中执行http请求，需要注意的是，我们需要将http请求具体分为get和post请求，具体的请求类型对应着不同的测试用例。
明确数据驱动和接口执行驱动之后，接着需要将所有的测试用例集和http请求结合起来，以执行接口测试，这里就涉及到调度器的概念了。调度器主要是将数据驱动加载的TestSuite集生成Junit4框架需要的执行器runner。通过调用runner的run()方法，遍历runnner以生成所有的TestCase。然后，针对每个TestCase执行覆写的methodInvoker ()方法，在 methodInvoker ()中生成每个TestCase所需要的所有执行单元statements，statements包含测试执行前数据准备、http请求执行以及测试执行后数据清理等工作。如上述可知，通过继承BlockJUnit4ClassRunner类自定义需要执行接口测试的runner。其中，覆写computeTestMethods()，生成需要执行的所有TestCase；然后，覆写methodInvoker，针对生成的TestCase指定需要执行的接口执行驱动XStatement。
最后，结果验证以及结果报告是很重要的环节。接口自动化测试的意义就是通过自动化测试手段，对系统进行大量回归测试，验证测试结果，从而定位出bug。对于大批量的回归测试，将测试结果统计出来，对于问题分析有很大的帮助，所以一份简单明了的结果报告很重要。对于结果验证，最简单的一种思路就是利用assertEquals去对指定字段的预期结果和实际结果做对比验证。此外，可以针对每个测试用例维护一份完整准确的运行结果，每次只需将实际运行的结果与其进行对比。结果报告需要提供运行测试用例的总数，本次执行成功的用例总数以及失败的用例总数；对于失败的用例，需要给出失败的原因；将所有的这些点透传到前端直观的展示出来即可。
是时候总结一下了，本文从数据驱动、接口执行驱动、调度器、结果验证以及结果报告五个维度讲解了如何基于junit4框架去搭建自定义化的接口自动化测试框架。逻辑不复杂，大家可以按照这个思路去动手尝试一下。为了让大家有个直观的概念，下面以流程图的形式为大家呈现出自定义的接口自动化框架扩展及运行原理。
一个接口自动化框架需要实现的东西不限于上面的五部分，包括数据准备、数据清理、请求参数的加签验签，数据库的操作与结果验证、mock的实现等等。但是，基于上面的思路，可以让大家能够轻松的搭建出自定义的测试框架，剩余的只需不断的完善。最后想要说的是：“纸上得来终觉浅，绝知此事要躬行”。
转载自 360质量效能