浅谈接口自动化测试的可扩展性、维护性

随着自动化测试的发展，自动化测试工具、测试框架也越来越丰富，比如：
自动化测试工具的分类：Web自动化测试工具，性能自动化测试工具，接口自动化测试工具。
自动化测试框架：录制回放测试框架，测试库构架框架，数据驱动的自动化测试框架，关键字驱动的自动化测试框架。
随着测试工具的多样化发展，自动化测试的成本、周期都随之缩小，但也带来了如何选择的问题。
接口自动化框架
自动化测试工具的选择：
框架、工具的选择是我们确认开展自动化后首先面临的问题。自动化测试开展一定要结合被测系统的特点进行选择，不顾被测系统（系统框架）特性、场景而盲目选择自动化测试框架(或工具)， 它是没有灵魂的，自动化失败概率会相对高很多。
首先我们需要明白自动化测试框架更倾向于一种设计思想 ，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。
很多种自动化测试框架(或工具)都可以开展自动化， 所以在自动化框架(或工具)的选择上，以被测对象为本来选择自动化框架(或工具)。
结合业务特点，我们在测试库构架框架的基础上再采用数据驱动框架，将其单的查询逻辑与测试数据分离，这样我们再开发其他用例时，只需要在数据文件中增加测试数据(输入、对应期望)，避免了重复开发带来的开发、维护成本。
因此，可以考虑基于测试库架构框架+数据驱动的自动化测试框架实现用例（代码）与数据（参数）解耦，将数据存在配置文件中，提高“查询逻辑单一、复用性强”的测试场景下的自动化测试的可扩展性、维护性。
复杂业务流程的测试场景
业务流程场景一般指的是系统业务流程，类似于办公流程，具有强流程性。在不考虑使用mock等方式对单接口进行自动化覆盖的情况下，只考虑进行不同流程接口的集成自动化测试覆盖，该如何设计呢？
基于这种测试场景，假如我们继续使用测试库架构框架+数据驱动的自动化测试框架的设计思路来完成，效果会如何？
首先想到的一个弊端就是每条用例的代码量会很多，对于用例（代码）调试、维护成本会增加。单单这一点，该方案就不应被采用。
我们可以考虑基于测试库构架框架 + 数据驱动框架（参数解耦）+ 关键字驱动框架（操作解耦）。
采用这种框架会带来哪些变化，首先基于关键字驱动的测试框架解决的是开发、维护成本以及开发难度问题，通过对测试库函数的自然语言描述映射，对于业务人员由面向代码的开发转换为面向自然语言的设计(组合设计)， 降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试。
高扩展性的测试策略
去用例化
适用于场景（多接口组成的操作流程）或接口相似度较大的系统，主要设计思想基于测试库架构框架、数据驱动框架结合用例动态生成框架（通过配置数据生成对应的可执行的自动化测试用例）。
在实际应用中，通过该框架设计，实现了对系统的90%的接口自动化覆盖，产出4个模板用例文件（Py文件）,配置文件填写每条用例参数、期望信息，主要面向这五个文件进行维护，每次运行基于此动态生成3000余条自动化用例（执行完成后，生成的用例被删除），很大程度上提高了用例的开发效率和降低了维护成本，扩展性也得到提升。
自动化测试代码不随着用例增加而增加
适应于广泛的单接口或复杂场景的接口自动化测试，基于测试库架构框架、数据驱动框架的基础上，补充关键字驱动框架。对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，一定程度上实现了自动化代码不随用例的增长而增多。