接口自动化测试

本文只讲方法，不会太多关注具体实用细节。

为什么要做自动化测试？

当接口的功能很复杂、很灵活、频繁变更时，代码稍微有些变更，影响范围很难短时间内确定，系统质量无法保证，能够最快想到的办法就是做好自动化测试用例的编写，一般大厂都有测开的岗位对接口进行测试，甚至定时对所有接口进行自动化测试，在测试环境测试接口的可用性以及正确性。经过自动化测试的系统是否一定没有问题呢？答案否。这和设计的用例，以及用例覆盖多少功能有关。但至少能确保不会出现大问题，不会和实际可用性功能偏离太多。

优秀的测试在测试前会了解系统的功能用例有哪些、需要测试的覆盖范围、以及系统是如何设计的、准备测试数据等，通过全方位的思考，针对主业务流程，以及可能存在问题的地方设计测试用例。类似程序代码的复用性一样，测试用例是否可以毫不费力的重复使用，那就需要使用到专业的技术了，相比较手动测试，自动化测试用例一次编写，只要系统长期使用，随时测试。

如何做自动化测试

如果站在系统测试的角度，整体的系统测试必不可少。但是通常在开发过程中，每个开发会针对自己开发的代码做单元测试，如果没有系统开发owner, 每个开发只顾自己的代码，系统整体测试bug不可避免。
最近本人开发一个接口很灵活的系统，接口的入参和出参都是动态变化的，和用户的人机交互的对话数据、以及用户自有属性数据集相关。这个横向项目虽然系统本身不复杂，但是交叉了太多的业务领域，导致笔者无法从中抽身，犹如陷入了沼泽地大坑，越陷越深；我很想从中爬出来，这就是写本文的真正原因。
测试前无他，设计测试用例，一个测试用例主要包含了前提条件、操作步骤、预期结果等。
设计用例需要考虑到系统之间是有相互依赖的，数据与数据之间有属性的关联。通过合理的数据管理、数据模拟、测试用例设计、执行顺序管理、前置条件设置、清理和恢复操作以及并行执行等方法，可以有效地解决自动化测试中的测试用例依赖问题。

针对测试数据依赖的问题，有不同的测试方式：

1. 单系统测试
2. 系统集整体测试

单系统测试比较简单，只需要关注此系统的功能逻辑是否正常即可，对于其他系统和数据的依赖，完全可以采用mock的方法，否则核心和入口强相关功能就需要系统集测试。
系统集群测试表示一个功能用例需要涉及到多个系统之间的交互，影响测试结果的变量非常多。

相比较系统集群测试，单系统只需要考虑此系统的输入和输出即可，测试过程中，最复杂的事情是构造测试用例的前置条件，以下是不同方法可能造测试工具轮子的方向，区别在于测试前的数据依赖是如何解决的：

1. mock依赖接口
2. 使用切面mock方法
3. 修改db数据
   单系统的数据来源无非是接口、配置或者db，通过修改或者mock数据满足测试用例的前置条件。
   最有难度的是切面mock方法，可能只有程序员自己才了解自己写了什么代码，针对自己写的方法专门做方法mock。

测试工具

系统测试工具有很多，有很老的测试工具loadRunner，也有一部分公司使用编程工具进行测试，这需要了解更多的系统设计细节。

1. 接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；
2. web自动化测试方向：Python+selenium4+pytest+POM+allure+Jenkins；

大部分测试工具使用到python，python是一门封装性和自然语言程度很强的编程语言，语言都是相通的，学过任何一门OO语言的人都可以很快的上手。使用测试框架后，只需要专注测试用例程序编写，运用好测试工具，随时出测试报告结果