如何从测试框架到测试平台

测试框架应该包含哪些功能？平台化后这些功能应该作何取舍？测试平台的深度封装与拓展性应该怎么平衡？从这三个问题我们来探索一下如何从测试框架到测试平台。

通常来说，一个完整的测试框架必须包含的功能有：测试对象(API/UI)、测试用例、测试数据、测试计划、测试报告、邮件通知以及相关配置管理：环境配置、公共参数配置等。这种设计称之为POM模式，即对象模型数据三者分离。

测试对象进行统一维护，测试数据用来做数据驱动，使用者只需要在测试用例里写相关业务逻辑脚本即可。如此做的好处是，测试脚本清晰易读，并且如果遇到业务变动，能快速地修改测试用例中的逻辑代码。而如果数据出现异常不再适用时，仅仅去重新设计测试数据即可，不再需要去动测试脚本。此外，测试对象统一维护的好处更是不言而喻，当测试对象变动时，只需要一处修改，全局适用。

那么，测试平台也需要这样设计吗，答案是肯定的。不过多少需要一些变动，主要表现在以下几点：

1.测试用例与测试数据无须分离。如上述所言，测试框架中用例与数据分离的主要原因是为了测试脚本维护方便，但是平台化后没有测试脚本，直接对测试对象进行排列组合的操作，此时如果再进行操作与数据分离，形成用例模板一样的中间态，反而会增加维护成本。

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

3.UI自动化的关键字驱动。UI测试不同于接口测试，是一个个步骤组装成一条用例，要想实现自动化，必须将驱动代码翻译成能够自由排列组合的步骤。其实UI测试步骤无外乎POM三大块：操作动作、页面元素、测试数据。平台化时，可以将这些步骤封装成一个个操作控件，并赋予其言简意赅的关键字。写用例时通过选择关键字，带出其所需的元素和数据，就能完成一步步的UI测试。

4.分布式执行测试。平台化后不能再像测试框架一样，各跑各的，必须统一管理、量化结果，因此测试执行必须统一调度。但是同一调度无法避免资源拥堵、网络限制等问题，因此平台化理应考虑分布式执行，一个服务端对应多个执行端，由使用者决定在何处执行，并将结果最终统一收集起来。因此测试执行的代码可以进行封装成客户端，即前文所述的测试引擎。

5.集成CI/CD。平台化主要的目的之一是为了更好地集成到研发管理体系中去。前文作者已经叙述过这一点，要想实现这些问题，其实就是要做一些简单的研发管理：项目管理、版本管理、模块管理、覆盖率计算、缺陷上报、定时执行、触发执行、结果回传等功能。

通过上述框架与平台的不同点，再结合相同之处，大概可以得出测试平台需要包含的整体架构，我们不妨用经典房子图来描述，如下所示：

注：灰色部分是流马测试平台未实现功能

上述内容已经回答了前两个问题，那么怎样探索深度封装与拓展性的平衡点呢？这个问题作者也没有完全探索明白，目前流马测试平台的设计是只做浅中层的封装，并支持用户自定义一些业务逻辑代码。

值得一提的是，就这个问题作者最近收到许多讨论，基本都是赞成深度封装直接做无代码平台。事实上，深度封装虽然让自动化测试平台更加傻瓜式、低门槛，但肯定会带来两个问题：一是稳定性不足、二是通用性不足。其实深度封装这种设计更适合一些项目上的定制化开发，但随之而来的问题是，每个项目都单独做测试平台，那就又成了另一种形式的测试框架。

所以作者的建议是，在做测试平台时，一定要先考虑稳定性和通用性，再考虑逐步进行深度封装。一个测试平台，需要先确保大家都能用，再去考虑大家觉得好不好用。站在研发管理的角度上，首先我们要保障的是测试覆盖率、是测试质量，这取决于自动化测试平台能不能覆盖更多的场景、测试结果能不能稳定输出、与研发管理能不能形成闭环。当然在此基础上，再对测试平台进行适度的封装，让编写测试用例更加的方便便捷，提升用户的使用体验。

作者理想中的测试团队应该是一个或两个测试开发同学带着数个业务测试同学。在自动化工具平台上，由技术较好的测开通过自定义业务逻辑代码针对不同项目做二次封装，形成一个个控件。而业务测试使用时根据所需选择对应的控件进行排列组合即可。如此就可以解决业务不懂技术、技术不懂业务的尴尬场面。

综上所述，测试平台首先得是一款通用、易集成的自动化工具，它的价值是降本增效，服务于项目，而不是为了深度封装提升逼格。