接口自动化测试的可扩展性和维护性

　　自动化测试工具的分类：Web自动化测试工具，性能自动化测试工具，接口自动化测试工具。

　　自动化测试框架：录制回放测试框架，测试库构架框架，数据驱动的自动化测试框架，关键字驱动的自动化测试框架。

　　随着测试工具的多样化发展，自动化测试的成本、周期都随之缩小，但也带来了如何选择的问题。

　　自动化测试工具的选择：

　　框架、工具的选择是我们确认开展自动化后首先面临的问题。自动化测试开展一定要结合被测系统的特点进行选择，不顾被测系统(系统框架)特性、场景而盲目选择自动化测试框架(或工具)， 它是没有灵魂的，自动化失败概率会相对高很多。

　　首先我们需要明白自动化测试框架更倾向于一种设计思想 ，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。

　　很多种自动化测试框架(或工具)都可以开展自动化， 所以在自动化框架(或工具)的选择上，以被测对象为本来选择自动化框架(或工具)。

　　结合业务特点，我们在测试库构架框架的基础上再采用数据驱动框架，将其单的查询逻辑与测试数据分离，这样我们再开发其他用例时，只需要在数据文件中增加测试数据(输入、对应期望)，避免了重复开发带来的开发、维护成本。

　　因此，可以考虑基于测试库架构框架+数据驱动的自动化测试框架实现用例(代码)与数据(参数)解耦，将数据存在配置文件中，提高“查询逻辑单一、复用性强”的测试场景下的自动化测试的可扩展性、维护性。

　　复杂业务流程的测试场景

　　业务流程场景一般指的是系统业务流程，类似于办公流程，具有强流程性。在不考虑使用mock等方式对单接口进行自动化覆盖的情况下，只考虑进行不同流程接口的集成自动化测试覆盖，该如何设计呢?

　　基于这种测试场景，假如我们继续使用测试库架构框架+数据驱动的自动化测试框架的设计思路来完成，效果会如何?

　　首先想到的一个弊端就是每条用例的代码量会很多，对于用例(代码)调试、维护成本会增加。单单这一点，该方案就不应被采用。

　　我们可以考虑基于测试库构架框架 + 数据驱动框架(参数解耦)+ 关键字驱动框架(操作解耦)。

　　采用这种框架会带来哪些变化，首先基于关键字驱动的测试框架解决的是开发、维护成本以及开发难度问题，通过对测试库函数的自然语言描述映射，对于业务人员由面向代码的开发转换为面向自然语言的设计(组合设计)， 降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试。

　　高扩展性的测试策略

　　去用例化

　　适用于场景(多接口组成的操作流程)或接口相似度较大的系统，主要设计思想基于测试库架构框架、数据驱动框架结合用例动态生成框架(通过配置数据生成对应的可执行的自动化测试用例)。

　　在实际应用中，通过该框架设计，实现了对系统的90%的接口自动化覆盖，产出4个模板用例文件(Py文件),配置文件填写每条用例参数、期望信息，主要面向这五个文件进行维护，每次运行基于此动态生成3000余条自动化用例(执行完成后，生成的用例被删除)，很大程度上提高了用例的开发效率和降低了维护成本，扩展性也得到提升。

　　自动化测试代码不随着用例增加而增加

　　适应于广泛的单接口或复杂场景的接口自动化测试，基于测试库架构框架、数据驱动框架的基础上，补充关键字驱动框架。对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，一定程度上实现了自动化代码不随用例的增长而增多。

　　以上是关于接口自动化测试的可扩展性和维护性的介绍，由多测师亲自撰写，全网独家提供!  http://www.aichudan.com/