聊一聊低代码自动化测试平台的设计思路

自 18 年起，一直在思考如何把自动化测试框架转化为测试平台，让自动化测试告别代码。中间搁置两年，20 年底于上家单位尝试在做，最后效果还算不错，但是很多设计在使用中发现仍不完善，因此后来下定决心自己一个人重做一版。

通常来说，设计自动化测试框架时模块大概可以拆分为：测试对象（API/UI）、测试用例、测试数据、测试环境、测试计划、测试日志、测试报告以及一些辅助功能如公共参数、测试文件等。那么我们将其平台化后，也可以参考这个思路来做，但是有些功能需要做适当的变更：

1. 首先是测试用例和测试数据，常规的测试框架遵循 POM 设计模式，用例代码和数据是分离的，从而方便管理。平台化后，理论上也该如此，最早我也是这么做的，采用用例模板和用例数据分离的模式，但最终发现写用例时极为不便，而且也有各种各样的问题。其实平台化后，没有必要再做用例和数据分离，框架做分离是为了数据管理更加直观，不受代码影响，更加容易维护，但是平台化后，代码几乎为 0，用例采用配置化来写，因此用例步骤与数据结合在一起维护反而更加直观。

2. 其次，平台化后虽然不用写代码，但也会带来很多局限性，一些特殊的处理不易实现。比如说参数加密，框架只需要写一个公共加密函数，用例步骤中调用。平台化后，要想支持这一点，那么就应该有函数管理功能，支持统一维护函数，并在用例调用。函数管理应该有常用的内置函数，同时也要支持自定义。

3. 还有就是 UI 自动化的实现，我们可以将驱动代码翻译成关键字，其实 UI 测试脚本每一步无非就是包含三个内容：