技术分享 | 接口自动化的高复用测试方案

一 探索新测试方案的初衷我们对近期有信创或上云改造计划的多个系统进行调研分析发现相关系统具有接口参数多、关联条件复杂、请求返回格式不统一的共同特点在尝试使用常规自动化测试方案建设时发现了以下急需攻克的难关1.系统接口参数多、组合复杂。系统的接口请求参数多单个接口可能需要上百次的请求调用来完成测试覆盖同时所需的业务数据具有时效性往往需要频繁更新维护。而常规方案将请求调用转化为脚本步骤脚本复用率低、重复工作量大、业务数据不便维护。2.系统流程前置条件多、关系复杂。交易流程间互相依赖而常规方案按顺序执行脚本步骤上一步骤的返回结果检查通过后会作为下一步骤的输入条件这种逻辑结构处理不当时会出现步骤冗长、整体失败率高的问题。3.交易返回报文格式不一。待测系统与关联系统联系紧密各交易返回报文格式不一、同一交易不同数据返回结果不同而常规方案将断言内容与执行步骤固化缺乏合理的重试机制和灵活丰富的断言方式难以保证接口自动化测试的健壮性。上述问题带来的测试痛点是不是恰好戳中了你们那么如何解决这些痛点并减少测试工作量和测试压力呢别着急接下来就给大家具体讲讲我们的解决方案。二 高复用测试方案的构成我们经技术调研实践后“对症下药”探索出了一套以参数案例集为数据驱动的高效、通用、灵活、易迁移的高复用自动化测试方案。该方案结合了自动化测试平台既有功能模块由案例管理、业务数据、执行解析和结果报告四部分构成。高复用测试方案框架图案例管理对参数案例集统一管理。案例内容包括预留列、案例名称、预期结果、参数列、条件标识列等。业务数据一组全局化的变量值通常由查询数据库、请求接口返回、手动录入等方式而来。执行解析逻辑处理单元包括案例文件读取、请求报文组装及参数化、请求调用和返回报文解析、结果断言等功能。结果报告用于执行结果记录并生成报告。三 高复用测试方案的实现只看上面四个模块是不是还不太清楚具体如何实现再上一个实施流程图我们结合具体步骤细细道来测试方案流程图第一步参数案例设计梳理待测功能的测试点和接口参数通过参数案例模板编写参数案例集填写测试参数数据其中正例参数数据用我们事先约定的占位符代替。参数案例模板图第二步业务数据初始化通过SQL语句查询或交易接口请求获取一个或一组业务数据并统一初始化 为全局变量。第三步脚本编写并参数化利用自动化测试平台进行请求执行、解析脚本编写和逻辑控制设计同时将请求报文体中各参数进行参数化执行时通过读取指定案例行内容将请求参数替换。参数化实现示意图第四步结果断言设计为每次请求指定成功结果的预期值即断言可使用参数案例集中预期结果字段断言也可使用测试平台原有断言类型。第五步调试执行生成报告调试或执行案例时执行解析模块会自动读取参数案例集内容并记录案例总数根据案例总数循环遍历执行所有案例遍历过程中通过逻辑控制来实现如跳过执行、流程分支控制、执行前置交易等操作。执行完成后记录日志并生成测试报告。四 高复用测试方案的优势通过上述步骤详解大家可以看出该方案中参数案例、业务数据、执行模块相互独立这就使得自动化建设工作各环节层次更加清晰同时该方案提高了执行模块的复用性降低了自动化测试实施难度解决了之前的自动化测试痛点。具体说来该方案还有以下优势效能提升方面将单次请求简化为参数案例集无需重复编写请求脚本。每条案例中均涵盖“测试描述、预期结果、参数列表”等请求的关键要素接口下所有案例支持批量调试并格式化输出结果。高复用自动化测试方案目前已在多个系统进行实践累计产出自动化场景案例2000条覆盖业务交易100支发现系统接口问题30处系统平均自动化测试建设效率提升约40%。维护扩展方面分层解耦独立性强。参数案例、业务数据独立对案例的扩展或修改只需调整参数案例集而无需修改所有的请求脚本。用户体验方面文本形式的参数案例可离线保存便于检查审阅和统计数据测试报告展示也更加清晰直观。环境适配方面将系统环境信息、SQL语句抽离进行集中管理。环境切换时只需调整环境配置信息案例和接口脚本无需改动。了解完我们的高复用测试方案大家是不是心痒痒想上手到项目上试一试呢我们的方案与大多数事务处理型系统尤其是单接口参数多、交易链路短、需要设计大量正反向场景案例进行测试覆盖的系统非常适配喔希望大家之后可以积极尝试体会接口自动化带来的乐趣~~最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。