自动化测试工具的多样化

随着自动化测试的发展，自动化测试工具、测试框架也越来越丰富，比如：

自动化测试工具：

Web自动化测试工具：Selenium、QTP
性能自动化测试工具：Loadrunner、Jmeter
接口自动化测试工具：SoapUI、Postman

自动化测试框架：

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

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

自动化测试工具的选择

框架、工具的选择是我们确认开展自动化后首先面临的问题。之前网上有个梗，泡面煮着吃是没有灵魂的，当然这是一种调侃。自动化测试开展一定要结合被测系统的特点进行选择，不顾被测系统（系统框架）特性、场景而盲目选择自动化测试框架(或工具)，它是没有灵魂的，自动化失败概率会相对高很多。

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

我们在之前文章中分享了几种常用的自动化测试框架及工具的介绍，仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强，所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么，或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。

扩展性设计策略

单一接口，不同参数组合的测试场景

类似于某宝WEB版商品筛选功能，多种类型、商品的随机组合查询，如下：

基于这种测试场景，假如我们"关键词（鞋子) +品牌（耐克）“写一条自动化用例，“关键词（鞋子）鞋子) +品牌（耐克）+发货地（南京）”又写了一条自动化用例，这种方式是否存在可以优化的地方?

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

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

复杂业务流程的测试场景

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

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

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

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

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

高扩展性的测试策略

去用例化

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

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

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

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