接口自动化测试这些事儿
一、自动化测试众所周知，自动化测试已经成为软件项目中不可或缺的测试方法。基于用户交互界面（GUI）的自动化测试方法具有模拟用户行为和过程可视化的特点，因此受到了广大入门自动化人士的喜爱。诸如：QTP、Selenium等都具有强大的功能支撑和丰富的知识库，而逐渐成为自动化测试人士必备工具之一。
然而，伴随着敏捷开发和持续交付在软件开发项目中的普及和应用，测试工作的重心不得不进一步前移。而由于用户界面的开发通常处于软件开发的末端且缺陷修复成本较大，因此基于GUI的自动化测试无法很好的适用于此类项目。基于应用程序接口（API）的自动化测试却可以很好的解决了此类问题。
二、接口自动化测试
在分层测试策略中各层工作有明确的测试重心，测试工作通过逐层开展螺旋上升。这样一方面促使开发测试一体化，直接提高了测试效率；另一方面也可以尽早发现程序缺陷，降低缺陷修复成本。
API接口测试介于单元测试和界面测试之间，是一种灰盒测试方法，主要测试内部接口功能的完成性。相较于UI自动化测试，它具有自动化成本低和测试效率高的特点。
接口测试的工作原理是接口测试工具模拟客户端向服务器发送报文请求，服务器接受请求并做出响应。然后向客户端返回应答信息，接口测试工具对应答信息进行解析的一个过程。如图-2.2所示：
图-2.2 报文传输的大致流程
常用的接口测试工具有：
1、Apache JMeter：是一款基于Java的开源测试工具，主要应用于WEB应用程序的负载测试，同时也支持单元测试和接口测试；
2、Postman：是一款功能强大的网页测试工具，支持WEB API和HTTP请求，能够发送任何类型的HTTP请求（GET、HEAD、POST、PUT等）。Postwomen与其近似的一款免费开源、轻量级测试工具；
3、SoapUI，是一款用于SOAP和REST的开源API测试自动化框架，可以集成到Eclipse等开发工具中，支持用户二次开发；
4、Robot Framework，是一款基于Python3的开源自动化测试框架，具有良好的可扩展性，支持关键字驱动，运行用户二次开发。
基于这些接口测试工具，测试人员可以根据自身业务需要开发适合自己的接口自动化测试工具。有了接口自动化测试工具，我们就可以开展自动化测试工作。接口自动化测试的基本流程有：1、在测试工具中登记待测交易的接口报文格式；2、编写测试案例，向案例中添加交易接口并进行配置关联；3、准备测试数据并对测试数据进行参数化；4、测试工具自动执行自动化测试案例；5、测试工具比对预期结果和返回结果，验证案例是否执行成功。如图-2.3所示：
图-2.3 接口自动化测试流程
三、接口自动化测试要点
参照DevOps的评级标准，作者所处项目的所有交易的接口必须进行全量自动化测试覆盖。项目组为了保证项目测试达到该标准，为此做了大量的前期规划和实践探索，结合作者的自身的项目实践与大家分享几点接口自动化测试过程中的工作要点。
1、梳理交易流程做到一目了然。以税金支付账号维护交易为例，该交易包含新增/修改提交复核、复核通过、复核退回、删除四个程序接口。各接口程序之间的关系如下图-3.1所示，提交复核分为新增提交复核和修改提交复核，提交之后可以复核通过也可以复核退回，删除交易只能处理复核退回的数据。
因此我们可以整理出该交易的分支案例如下：
1）新增提交复核>复核通过>修改提交复核>复核通过；
2）新增提交复核>复核退回>修改提交复核>复核退回>删除。
由图-3.1我们可以一目了然的看出该上述两条分支案例已完全覆盖税金支付账号维护交易的所有业务分支。从而避免接口自动化测试时遗漏某一逻辑分支，造成缺陷逃逸。
图-3.1 税金支付账号维护交易流程图
2、详细的接口设计文档是成功的前提
子曰：”工欲善其事，必先利其器。”一个详细的接口设计文档是接口自动化测试顺利开展的重要前提。为了保证接口测试的顺利开展，我们要求项目组开发人员务必给出接口交易各字段的校验规则和操作步骤。如图-3.2/3示，展示了提交复核接口各输入字段的校验规则，提交复核类型不能为空，必须是old/new。同时开发人员还写出了提交复核接口程序的处理步骤，如对数据库表：税金支付账号，先进行赋值操作，然后进行了保存到数据库中。
详细的字段校验规则，有助于后续测试人员在编写接口自动化测试案例时准确的填写接口字段值。并根据校验规则和操作步骤设置检查点，比对判断程序返回结果是否正确。详细的验证方法见下一部分“案例正确性验证”。
图-3.2 提交复核接口字段校验规则
图-3.3 提交复核接口操作步骤
3、案例的正确性验证
1）程序返回信息的正确性验证。案例执行完毕，对程序返回结果的正确处理决定了自动化案例能否正确发现程序缺陷。可以说全面的正确性验证决定了自动化测试案例的质量高低与否。如：图-3.2中提交复核类型字段输入NULL/add等非法值后，我们不仅要验证程序的错误码为200，同时也要验证报错信息是否符合预期，确定该条案例确实测试到该条校验规则。
为此我们引入了关键字比对功能，提取预期错误提示信息的唯一标识关键字。以关键字为标准，检索程序反馈信息是否存在该关键字，若检索到该错误信息关键字则判定该反向案例执行通过且正确。若未检索到该错误信息关键字，则判定该反向案例设计不能覆盖此条交易规则。
2）数据库操作的正确性验证。程序执行过程中涉及到大量的数据库增删改操作，从验证完备性考虑，需要进一步验证数据库操作是否正确，避免插入、修改的数据存在错误，或数据库操作失败后回滚造成脏数据的存在。
为了验证数据库插入、修改、删除是否成功，数据是否符合预期，我们采用了以下两种验证方法：1）交易关联验证；2）数据比对验证。
交易关联验证是通过业务逻辑进行验证，使用后置交易是否能成功执行来验证前置交易数据库操作是否正确。如：录入一张金额为100元的发票，我们可以先发起领票101元的交易，再发起领票100元的交易，如果领票101元失败，领票100元成功，即可证明录入金额为100元准确无误。
数据比对验证是系统或业务需要的登记类数据，这类数据没有后续的逻辑关系，传统的处理方法是人工查询数据库或查询交易，我们开发出一个数据库查询API，通过前置交易传入的表的KEY值查询到该条记录的其他字段值，并与预期值进行比对，从而实现了自动化核对。
4、其他要点提示
除了以上3点之外，测试人员还需要关注数据是否独立、测试案例是否形成了闭环、测试数据的参数化。数据是否独立决定了测试环境对自动化案例的影响程度，数据独立性越高则环境变化造成的影响越小。测试案例能否形成闭环决定了该条测试案例是否可以被重复大量执行。测试数据参数化决定了我们的案例复用程度和后期的维护成本，对等价的数据进行参数化设置不仅有助于我们覆盖大量测试数据。同时当程序发生改变时，我们可以简单快捷的修改测试数据。常用的测试数据来源有数据库、配置文件、接口返回值、excel/txt文件。
四、结语
随着自动化测试成为测试工程师必备技能之一。拥有了该项技能在面对功能、模块日趋复杂和迭代频繁的软件开发项目时，测试人员可以从容不迫的解决和应对这些问题。本文基于此种考虑，介绍了自动化测试的相关知识。结合作者在项目中的实践分享了接口自动化测试过程中的几点感悟，希望对想要迈入和初步迈入的自动化测试领域的同志们有所帮助。
学习 现在我们用到的还只是验证接口返回正确，但是针对接口的测试还是欠缺。学习了
页:
[1]
