我在大型政府部门做了 20 多年的质量过程改进服务，结合多年的实践经验，最近在天工 AI 助力下，使用 Python 写了一个接口和灰盒自动化测试工具 DATF（Daniel Auto Test?Framework）。

　　下边介绍一下 DATF 这个轻量化自动化测试工具的特性，欢迎有需求的测试人员试用，希望能对提高项目的质量和测试工作效率有所帮助。

　　轻量化

　　免安装，在个人用机上开包即用，无需额外设备花销。目前市场上的接口自动化测试工具基本是 SaaS 模式，需要订阅，数据放在公有云上。如果客户有数据安全要求，就只能购买产品后部署私有云，需要专用服务器、数据库，需要部署自动化测试平台，还需要专人维护，随着使用人员的增多，可能还需扩展服务器资源。

　　上手快

　　对于使用Postman做过接口测试并懂基本的SQL的人员，借助产品包中30多页的《DATF使用手册》，1 小时内就能上手，不要求懂 Python，学习成本低。

　　想要《DATF使用手册》的童鞋可以添加下方二维码，回复关键字“DATF使用手册”；

　　无需编写自动化测试脚本

　　不用写代码，只需做配置即可生成自动化测试用例。比传统的编写接口自动化测试用例模式 Python+Request+PyTest+Allure 效率提高至少 3 倍。同时降低了对编写接口自动化测试人员的技术能力要求。让测试人员把更多的精力放到细致分析需求，深入了解系统设计上，设计出更符合要求的自动化测试用例。

　　基于测试人员视角设计

　　传统的接口自动化测试工具，大多数是基于单元测试的原理发展来的，是从开发人员的视角设计的，往往没有考虑到测试人员的实际需求和工作习惯。DATF 完全是从测试人员视角设计，能满足大部分测试人员的通用需求。

　　易用性

　　DATF 的代码行数，总计 12000 行，其中只有 3000 行是核心功能，其余 75%的代码都是为提高易用性做的开发。鉴于目前用过的工具，测试报告展示方面感觉都不是很满意，为方便使用者查看历史测试报告数据，又开发了测试报告展示工具。接着在这个工具基础上，为方便控制测试用例配置和执行，减少手工直接修改配置文件造成的人为错误，后续又开发了测试控制台。

　　版本控制

　　DATF 采用了全配置文件设计，版本管理就像代码版本管理一样容易。目前市场上的接口自动化测试工具能实现版本管理的很少。

　　全流程可视，可控，可溯

　　可视，可控，目前的接口自动化工具都能实现。DATF 的强项是可溯。因为设计了历史记录追溯和配置文件的版本管理功能。这就为防止测试用例缺失做了有力的保障。做过项目的都清楚，虽然制度上有时要求对测试用例评审，但实际工作中很难做到全面评审，顶多评审一下关键功能。

　　有了可追溯功能，项目测试管理人员就可以通过事后问题倒查追责的方式，破解了不评审测试用例又担心遗漏的难题。

　　同步开发自动化测试用例

　　通过mock方式模拟接口返回值，测试人员可以提前同步开发调试接口自动化测试用例。接口部署后切换到接口方式，一键开始接口自动化测试。上报缺陷后，等待开发人员修复缺陷期间，就可以开始手工前端操作流程测试，相当于同时有 2 倍的测试人员在干活，大幅缩短了项目开发周期。

　　辅助开发定位问题

　　对于复杂系统，大部分开发人员往往只了解自己负责的部分，对业务全流程不是很清楚；

　　定位问题时，自己也不会做符合业务规范的测试数据，常常需要测试人员帮忙准备数据，增加了测试人员工作量。

　　有了工具，开发人员就可以直接使用报错接口自动化用例的初始化脚本做测试数据，调用用例的调用参数，很快就能定位问题，而且修复后可以自己直接使用测试人员写好的测试用例。

　　运用工具，在开发环境先验证，通过后再提交测试，降低了缺陷修复中反复修改的概率，缩短了缺陷修复的时间。

　　一键切换测试环境

　　相同的数据源名称，配置时对应不同环境的数据库，不用修改测试用例，一键即可在确认和回归环境之间自由切换后执行测试用例。

　　全面的测试报告展示功能

　　· 可以展示不同时间生成的测试报告的历史数据。

　　· 对于同一个测试用例，可以比对相同测试环境下的测试执行结果的历史数据。

　　· 可以展示项目、接口、分组级的测试样例统计和通过率。

　　· 可以统计每个测试人员的工作量和通过率。

　　100% 覆盖接口需求

　　我个人认为，目前在自动化测试方面存在 2 个误区。

　　一个误区是希望尽可能通过多做 GUI 自动化测试来保证软件质量。多年的实践证实，这只是不切实际的幻想。首先，GUI 自动化测试用例无法在确认测试时就开发，否则开发人员一个简单的前端修改，就会让测试人员疲于应付，回归测试时开发又没有足够的时间。其次 GUI 自动化测试用例的维护成本是非常高的，对于人员少、任务急的项目根本不适用。而且长期项目更换几批人后，后来的人就很难再维护前边的人开发的自动化用例了。GUI 自动化测试用例只适合上线后需要版本不断迭代开发的项目，只需要把最常用的最重要业务流程以及常用的异常状态前端处理流程做自动化用例，大概占总测试用例数 10%左右的用例，用于每次新版本上线前的常规验证。其他的前端测试发现的缺陷，很多是无法通过 GUI 自动化测试发现的，需要手工测试。

　　另一个误区是尽量多做场景自动化测试。场景测试用例很唬人，看着很漂亮，特别是喜欢给领导演示时用。场景测试和接口测试的区别就是测试数据的连续性，开发维护测试用例比较麻烦，每步之间需要传输动态数据参数。但场景测试一旦第一步出错，后续步骤的测试全错，无法确认后续步骤是否真的错了，需要花费更多的时间确认错误。而接口测试每个测试用例数据是完全独立的，数据初始状态一定是没问题的，只要测试用例没通过，就说明对应的逻辑处理肯定错了。在实际项目测试中必须用场景化测试的情况非常少，完全可以手工测试替代。

　　接口和灰盒测试才是保证软件质量最有成效的方法，事半功倍。我之前参与的项目，要求都是接口和灰盒测试必须 100%全覆盖，GUI 自动化测试非必要可以不做。接口都测试通过了，界面操作再出问题就可以很快确认是前端的问题。

　　测试人员要做开发人员和业务人员之间的桥梁，要比业务更懂系统设计，要比开发更懂业务流程知识。如果一个测试人员在一个项目中，经历过接口自动化测试 100%全覆盖，项目结束后，一般都会成为至少半个业务专家，并且对系统设计和需求有更深入和全面地掌握，对提升自己是很有帮助的。即使未来 AI 会替代部分开发人员，但很难替代测试人员。

　　方便易用的控制台

作者：徐志强    

来源：http://www.51testing.com/html/78/n-7802878.html