做SAP开发这些年最怕听到一句话就是“这接口之前明明调通了怎么一到生产就出问题”。去年我们团队接了个订单同步项目ABAP端需要调用某外部仓储系统的RESTful API真正跑下来才发现SAP ABAP调用RESTful API本身不算难难的是把测试用例设计得足够稳。后来我重新梳理了一遍调用逻辑、异常分支和模拟调试方式才把这块彻底吃透。这篇就把我的完整思路写出来从类结构、用例维度、本地模拟调试到踩坑记录一次性讲清楚。如果你是刚开始写HTTP客户端的ABAP顾问或者已经被各种异常返回搞到头疼这篇应该能帮你少走不少弯路。1. 从RFC到RESTful测试逻辑完全变了的三个原因1.1 一次生产事故问题出在“我以为调通了”先讲个真实教训。之前某个项目里我们做一个库存查询接口的对接开发阶段我用Postman和ABAP分别调了一遍对方返回200数据也能正常显示于是草草提交了测试结论。结果上线不到两周生产环境每隔几小时就报一次“连接失败”系统重启后能好一阵然后又复发。查到最后才发现问题根本不在接口逻辑而在ABAP端的HTTP客户端连接没有被正确释放。每次调用都会创建新的连接正常返回时走了关闭逻辑但一旦遇到超时或异常连接就残留下来了。对方网关对单IP连接数有限制累积到一定数量就开始拒绝新请求。这个事故让我彻底改变了习惯凡是涉及HTTP调用必须把测试用例当正经设计来做而不是“能通就行”。尤其是RESTful接口只测正常路径的代价就是漏掉所有真实环境里的“暗礁”。1.2 强类型变弱类型测试策略必须跟着变RFC和BAPI是强类型接口有ABAP数据字典兜底。字段缺失、参数类型不匹配基本在编译期甚至激活阶段就会报错。但RESTful API是文本协议请求和响应的核心载体是JSON字符串ABAP侧编译时根本不知道对方会返回什么。同样是漏了一个字段RFC里你少传一个必输参数系统直接拒绝执行RESTful里你少传一个字段对方服务可能照样返回200只是业务字段全是空值。更麻烦的是数据类型映射——外部系统返回的quantity: 2.0和quantity: 2在JSON解析后的结果就完全不同前者如果硬塞进整数变量直接抛异常或者被截断。这就导致RESTful调用的测试重点不一样了不仅要知道“接口能不能通”还得确认“字段映射对不对”“边界值怎么处理”“异常分支是否被正确捕获”。这些都不是靠一次冒烟测试能覆盖的。1.3 网络和中间件成了不可控变量RFC调用大多发生在SAP系统之间网络环境相对可控。RESTful调用则完全不同中间隔了API网关、负载均衡、限流策略、DNS解析每一层都可能出问题。同一个接口在测试网络调得好好的到了生产环境因为网关超时配置不一样直接504。这种场景下测试用例必须主动覆盖“非业务类”异常连接超时、接收超时、429限流、502网关错误、连接被对端关闭。单独调一次接口发现不了这些只有成体系的用例才能把问题提前暴露出来。2. 先把可测试的调用类搭起来2.1 配置与调用动作解耦很多同行写RESTful调用喜欢用Function直接拽URL、用户名、密码全写死在代码里。这写demo可以做正式接口对接就不合适了因为没法替换、没法模拟、没法在不同环境切换。我的做法是定义一个独立的调用类把“基础配置”和“调用动作”分开。基础URL、超时时间、认证信息都作为构造参数或者方法参数传入类内部只负责组装请求、发送、接收、解析。这样测试的时候才能用测试替身替换真实的HTTP客户端。下面是一个简化但完整的类骨架CLASS zcl_rest_demo DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. METHODS: constructor IMPORTING iv_base_url TYPE string, call_api IMPORTING iv_path TYPE string iv_method TYPE string DEFAULT GET iv_body TYPE string OPTIONAL EXPORTING ev_status TYPE i ev_response TYPE string RAISING zcx_rest_demo_error. PRIVATE SECTION. DATA mv_base_url TYPE string. METHODS get_http_client IMPORTING iv_path TYPE string RETURNING VALUE(ro_client) TYPE REF TO if_http_client. ENDCLASS.这个设计关键点在于get_http_client方法单独拆出来。测试时子类可以重写它返回一个mock对象而不是真的发网络请求。如果不拆这个方法每次测试都会打到外部系统用例就没法稳定跑了。2.2 URL组装和参数转义别把简单事做复杂URL组装看起来简单其实坑不少。完整URL最好拆成BASE_URL PATH不要整体写死。BASE_URL对应环境PATH对应资源环境切换时只改一个变量就行。METHOD call_api. DATA(lo_client) get_http_client( iv_path ). lo_client-request-set_method( iv_method ). lo_client-request-set_header_field( name Content-Type value application/json ). lo_client-request-set_header_field( name Accept value application/json ). IF iv_body IS NOT INITIAL. lo_client-request-set_cdata( iv_body ). ENDIF. ENDMETHOD.注意一个细节query string里的参数值必须做URL编码但不要对整个URL做escape_url因为那会把冒号和斜杠也转义掉。正确做法是只对单个参数值调用cl_http_utilityescape_url( )然后自己拼接。比如订单号里如果包含特殊字符不编码的话对方网关很可能直接返回400。2.3 JSON序列化和解析的标准姿势ABAP侧和外部系统交互JSON的序列化/反序列化我基本都用/UI2/CL_JSON。老版本有人用CALL TRANSFORMATION但结构复杂数据维护起来太痛苦。序列化时注意字段名大小写映射。外部系统通常用camelCaseABAP结构体默认大写如果直接用默认序列化出来的JSON可能是ORDER_ID对方解析不了。标准做法是用漂亮模式DATA(lv_json) /ui2/cl_jsonserialize( data ls_request pretty_name /ui2/cl_jsonpretty_mode-camel_case ).反序列化同理/ui2/cl_jsondeserialize( EXPORTING json lv_response pretty_name /ui2/cl_jsonpretty_mode-camel_case CHANGING data ls_response ).这里有个版本差异要留意在部分旧版本SAP_BASIS上serialize用的是compress参数而不是pretty_name同一套代码跨版本跑的时候行为不一样。做项目前先确认一下当前系统的/UI2/CL_JSON支持哪种写法否则同样是camelCase在不同环境可能一个成功一个静默失败。2.4 响应读取和连接关闭不能分家响应读取用get_cdata( )这没悬念。但连接关闭的时机很多人处理不好。HTTP客户端用完之后必须显式close( )释放资源而且要在所有分支都能执行到的地方做这件事。我是这么处理的TRY. lo_client-send( ). lo_client-receive( ). ev_status lo_client-response-get_status( )-code. ev_response lo_client-response-get_cdata( ). CATCH cx_root INTO DATA(lx_root). RAISE EXCEPTION TYPE zcx_rest_demo_error EXPORTING text lx_root-get_text( ). FINALLY. IF lo_client IS NOT INITIAL. lo_client-close( ). ENDIF. ENDTRY.FINALLY这里的意义就在于无论前面是正常返回、超时、还是解析异常连接都能被释放。我那次生产事故缺的恰恰就是这个FINALLY。3. 我实际执行过的用例清单从200到429之间的所有分支3.1 正常路径只断言HTTP 200远远不够正常路径测试不应该是“返回200就行”必须把断言做到业务数据层。我给每个接口设计的正常用例至少包含这几类断言断言项具体做法HTTP状态码断言等于200或201而不是只要不是5xx就算过顶层业务字段如status字段等于预期的READY且不能为空明细数量返回列表的条目数要和查询条件对应防止接口版本变更导致字段被舍弃关键ID回读POST创建后返回的ID必须能用GET再查出来幂等性对GET接口用相同参数连调两次结果一致如果对方支持幂等POST也要验证重复提交不产生重复数据我之前遇到过一个真实案例接口调用正常返回200但items数组一直为空。开发说“接口能通”业务说“数据不对”两边吵了半天。最后发现是对方把items改名成了itemListABAP侧映射字段还是旧的解析出来自然全是空。如果正常路径用例里带上了“断言明细不为空”这一条这个问题在测试阶段就能暴露。3.2 边界数据和格式的魔鬼细节RESTful接口测试最容易翻车的就是边界数据。我建议至少覆盖这些场景空请求体POST接口传一个空JSON看返回是400还是200错误信息是否可读。字段长度上下限对方限制remark最多200字符ABAP侧如果不校验直接传500字符部分服务端会直接500而不是友好提示。特殊字符中文字符、单双引号、反斜杠、换行符混在字段里发送和接收是否出现转义错误。大量数据比如一次返回5000条记录响应体可能几百KB甚至几MBABAP侧解析是否有性能瓶颈、传输是否会超时。数字精度金额、数量类字段外部返回浮点数ABAP若用P类型接收要做好舍入规则确认用STRING接收虽然不会报错但下游做计算时必须再转换这一步在测试用例里要写清楚。这些边界用例的价值在于它们不依赖业务逻辑却决定了接口在真实环境下的健壮性。3.3 异常分支把错误读“对”比调通更重要异常分支是我个人认为RESTful测试里最值得投入的部分我针对常见状态码都设计过对应用例状态码可能原因用例动作期望行为400请求体格式错误、必填字段缺失故意传错误JSON记录错误日志且错误信息可读401Token缺失或过期不传Authorization头系统提示认证失败不允许继续业务流程403无权限用无权限的账号调有权限接口返回明确无权限提示404路径不存在故意拼错资源路径不能当成成功处理也不该抛未捕获异常408 / 504网关超时用mock延迟响应ABAP侧能捕捉到超时异常并分类处理429被限流mock连续返回429有重试或退避策略不把错误直接抛给用户500服务端内部错误mock返回500记录完整请求ID日志中包含请求体和响应体便于排查这里我特别强调429的处理。很多ABAP顾问没写过限流逻辑但真实网关几乎都有限流策略尤其批量同步类接口特别容易被限。我的建议是收到429后不要立刻重试等待几秒后再重新调用重试次数要有限制比如最多3次如果还是429就必须走告警和人工介入流程。这个逻辑写起来没几行代码但测试起来要反复验证mock服务这时候就特别有用。3.4 认证和安全相关用例认证用例经常被忽略因为连接外部系统时“第一次能通”就默认账号没问题。但Token过期、账号被锁、证书变更都会导致突然的401或握手失败这些场景如果不先测试上线当天就可能是事故现场。我的经验是要覆盖Token过期后调用失败、刷新Token后调用成功、无认证信息时系统不会泄露内部错误细节、日志中不打印Authorization头和完整请求体。尤其是日志脱敏很多项目在排错时喜欢把整个请求对象打出来但请求体里往往包含业务敏感数据这个习惯要尽早纠正。4. 用本地模拟服务把调试成本降下来4.1 用Python搭一个可复现的Mock服务真实外部接口往往不稳定测试环境加白名单、数据造数都费劲。我的做法是在本地或者内网虚拟机里搭一个轻量Mock服务用Python的Flask就能实现不需要额外重型框架。from flask import Flask, request, jsonify app Flask(__name__) app.route(/api/orders/order_id, methods[GET]) def get_order(order_id): if request.headers.get(Authorization) ! Bearer test-token: return jsonify({error: unauthorized}), 401 if order_id 999999: return jsonify({error: order not found}), 404 if order_id 888888: return jsonify({error: too many requests}), 429 return jsonify({ orderId: order_id, status: READY, items: [ {sku: A100, qty: 2}, {sku: B200, qty: 1} ] }) if __name__ __main__: app.run(host0.0.0.0, port8098, debugTrue)这个Mock服务能随意控制返回结果想测404就传指定ID想测401就不带Token想测429就触发指定路径。ABAP端只需要把BASE_URL指到http://虚拟机IP:8098完全不用等对方联调环境。4.2 Mock服务带来的三方面收益第一是稳定性。真实外部系统经常半夜升级、白天限流测试跑着跑着就挂了Mock服务不存在这个问题用例执行结果可复现。第二是负向测试。故意返回500、429、延迟响应验证ABAP端的分支处理逻辑这是真实接口很难模拟的。你不能要求对方“你们故意挂一下让我看看处理逻辑对不对”但Mock服务随时可以。第三是回归效率。真实联调环境数据会变化今天返回3条明细明天可能返回30条测试断言很难稳定Mock服务返回固定数据用例跑完就能对比结果。4.3 借助测试替身做ABAP侧单元测试对更底层的ABAP单元测试我还会用测试替身的方式。核心思路就是前面类设计里提到的get_http_client方法真实代码返回if_http_client实例测试代码返回一个手动构造的假对象通过设置假对象的响应内容来模拟各种返回。用SAP标准框架cl_abap_testdouble可以创建测试替身然后配置方法行为。这样用例跑在开发系统里不依赖任何外部网络速度极快适合代码提交前的快速验证。真正的端到端联调再交给上面那个Mock服务去做。5. 踩过最深的四个坑与完整排查链路5.1 JSON字段大小写问题同一套代码在不同版本表现不一样接手某项目时代码在开发机跑得好好的预览环境的同一个接口返回的数据却全是空。查了半天字段名映射对不上。问题出在/UI2/CL_JSON的camelCase参数在版本之间有过调整同一个pretty_mode-camel_case写法在某个版本下对orderId这种多段命名映射正常在另一个版本下却完全没效果。排查这类问题的链路我总结为三步先打印实际返回JSON字符串确认外部系统返回的字段名到底长什么样再用/UI2/CL_JSON单独做一次反序列化测试把解析结果和原始JSON对比定位是映射问题还是数据类型问题最后确认目标环境的SAP_BASIS版本找到对应的兼容写法并在代码里加注释说明版本差异避免后续维护的人再踩。5.2 连接未释放从“偶发失败”到“系统瘫痪”的完整定位过程前面提到的那次生产事故完整的排查链路其实很有代表性我在这里再梳理一遍。第一步现象层。业务反馈“系统时不时的查不到数据”但重启后马上恢复。这时候不能只查接口要看整个调用链路的状态。第二步日志层。拉出ABAP应用日志发现大量CX_SY_CONNECTION_CLOSED异常但看不出规律。第三步资源层。到系统里查进程和连接状态发现HTTP连接数持续上涨稳定在一个高位。GC和内存看着正常但连接数明显不对。第四步定位代码。排查所有分支路径发现只有当调用超时或返回异常时代码会提前RETURN或抛异常跳过了释放连接的逻辑。这个问题的本质不是“连接没关”而是“所有分支都必须关连接”。所以后来我写所有HTTP调用一律强制使用TRY...CATCH...FINALLY结构并且把连接释放放在FINALLY里。这是一个很小的代码习惯但能从根本上避免连接泄漏。5.3 字符编码ABAP系统代码页和UTF-8之间的乱码坑外部接口返回的JSON绝大部分是UTF-8编码而SAP系统内部有自己的一套代码页体系。如果在老系统里直接用get_cdata( )读取响应遇到中文长文本或者特殊字符经常会出现乱码或者奇怪的替换符。推荐的处理方式是用转换类显式处理编码而不是依赖系统默认行为DATA(lo_conv) cl_abap_conv_in_cecreate( encoding UTF-8 ). lv_text lo_conv-convert( lv_raw ).发送方向同样要注意构造请求体之后如果请求体里有中文最好在set_cdata前用UTF-8转换一遍确保对方服务端收到的数据完整。很多“对方说我传过去的中文乱码”的问题问题往往出在这一步。5.4 超时参数和登录语言两个特别容易被忽略的默认行为超时参数属于那种“平时没人管出事就背锅”的配置。if_http_client的连接超时和接收超时默认值并不激进在异常场景下界面可能会卡很长时间。我的建议是生产环境显式设置连接超时10秒、接收超时30秒具体值按接口耗时特征调整然后把这个参数放到测试用例清单里用mock延迟响应验证超时后的行为是否符合预期。登录语言这类问题更隐蔽。ABAP端调用HTTP接口时请求头里会默认带出系统的登录语言如果对方服务端根据Accept-Language返回本地化错误提示同一段错误信息在不同客户端语言下可能完全不同。测试用例里的断言如果写死了错误文本换台电脑跑就会挂。解决办法是显式设置要发送的语言头保持各环境一致lo_client-request-set_header_field( name Accept-Language value en-US ).这个小配置在标准文档里很少会被提到但实际联调时遇到“同样的错误不同环境提示不一样”的情况多半就是它引起的。我现在的习惯是每写一个RESTful调用类先花半小时把需要覆盖的分支整理出来把Mock服务和测试替身搭好再写真实调用逻辑。看起来多花了一点时间但省下的排查时间绝对不止一倍。最后再分享一个实用小技巧把每轮测试用到的请求体和响应体完整留存成文件出了问题直接对比前后差异很快就能判断到底是对方改了字段还是我们传错了参数。这个方法帮我处理过好几次跨团队扯皮的事故比任何调试工具都好用。
做SAP开发这些年最怕听到一句话就是“这接口之前明明调通了怎么一到生产就出问题”。去年我们团队接了个订单同步项目ABAP端需要调用某外部仓储系统的RESTful API真正跑下来才发现SAP ABAP调用RESTful API本身不算难难的是把测试用例设计得足够稳。后来我重新梳理了一遍调用逻辑、异常分支和模拟调试方式才把这块彻底吃透。这篇就把我的完整思路写出来从类结构、用例维度、本地模拟调试到踩坑记录一次性讲清楚。如果你是刚开始写HTTP客户端的ABAP顾问或者已经被各种异常返回搞到头疼这篇应该能帮你少走不少弯路。1. 从RFC到RESTful测试逻辑完全变了的三个原因1.1 一次生产事故问题出在“我以为调通了”先讲个真实教训。之前某个项目里我们做一个库存查询接口的对接开发阶段我用Postman和ABAP分别调了一遍对方返回200数据也能正常显示于是草草提交了测试结论。结果上线不到两周生产环境每隔几小时就报一次“连接失败”系统重启后能好一阵然后又复发。查到最后才发现问题根本不在接口逻辑而在ABAP端的HTTP客户端连接没有被正确释放。每次调用都会创建新的连接正常返回时走了关闭逻辑但一旦遇到超时或异常连接就残留下来了。对方网关对单IP连接数有限制累积到一定数量就开始拒绝新请求。这个事故让我彻底改变了习惯凡是涉及HTTP调用必须把测试用例当正经设计来做而不是“能通就行”。尤其是RESTful接口只测正常路径的代价就是漏掉所有真实环境里的“暗礁”。1.2 强类型变弱类型测试策略必须跟着变RFC和BAPI是强类型接口有ABAP数据字典兜底。字段缺失、参数类型不匹配基本在编译期甚至激活阶段就会报错。但RESTful API是文本协议请求和响应的核心载体是JSON字符串ABAP侧编译时根本不知道对方会返回什么。同样是漏了一个字段RFC里你少传一个必输参数系统直接拒绝执行RESTful里你少传一个字段对方服务可能照样返回200只是业务字段全是空值。更麻烦的是数据类型映射——外部系统返回的quantity: 2.0和quantity: 2在JSON解析后的结果就完全不同前者如果硬塞进整数变量直接抛异常或者被截断。这就导致RESTful调用的测试重点不一样了不仅要知道“接口能不能通”还得确认“字段映射对不对”“边界值怎么处理”“异常分支是否被正确捕获”。这些都不是靠一次冒烟测试能覆盖的。1.3 网络和中间件成了不可控变量RFC调用大多发生在SAP系统之间网络环境相对可控。RESTful调用则完全不同中间隔了API网关、负载均衡、限流策略、DNS解析每一层都可能出问题。同一个接口在测试网络调得好好的到了生产环境因为网关超时配置不一样直接504。这种场景下测试用例必须主动覆盖“非业务类”异常连接超时、接收超时、429限流、502网关错误、连接被对端关闭。单独调一次接口发现不了这些只有成体系的用例才能把问题提前暴露出来。2. 先把可测试的调用类搭起来2.1 配置与调用动作解耦很多同行写RESTful调用喜欢用Function直接拽URL、用户名、密码全写死在代码里。这写demo可以做正式接口对接就不合适了因为没法替换、没法模拟、没法在不同环境切换。我的做法是定义一个独立的调用类把“基础配置”和“调用动作”分开。基础URL、超时时间、认证信息都作为构造参数或者方法参数传入类内部只负责组装请求、发送、接收、解析。这样测试的时候才能用测试替身替换真实的HTTP客户端。下面是一个简化但完整的类骨架CLASS zcl_rest_demo DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. METHODS: constructor IMPORTING iv_base_url TYPE string, call_api IMPORTING iv_path TYPE string iv_method TYPE string DEFAULT GET iv_body TYPE string OPTIONAL EXPORTING ev_status TYPE i ev_response TYPE string RAISING zcx_rest_demo_error. PRIVATE SECTION. DATA mv_base_url TYPE string. METHODS get_http_client IMPORTING iv_path TYPE string RETURNING VALUE(ro_client) TYPE REF TO if_http_client. ENDCLASS.这个设计关键点在于get_http_client方法单独拆出来。测试时子类可以重写它返回一个mock对象而不是真的发网络请求。如果不拆这个方法每次测试都会打到外部系统用例就没法稳定跑了。2.2 URL组装和参数转义别把简单事做复杂URL组装看起来简单其实坑不少。完整URL最好拆成BASE_URL PATH不要整体写死。BASE_URL对应环境PATH对应资源环境切换时只改一个变量就行。METHOD call_api. DATA(lo_client) get_http_client( iv_path ). lo_client-request-set_method( iv_method ). lo_client-request-set_header_field( name Content-Type value application/json ). lo_client-request-set_header_field( name Accept value application/json ). IF iv_body IS NOT INITIAL. lo_client-request-set_cdata( iv_body ). ENDIF. ENDMETHOD.注意一个细节query string里的参数值必须做URL编码但不要对整个URL做escape_url因为那会把冒号和斜杠也转义掉。正确做法是只对单个参数值调用cl_http_utilityescape_url( )然后自己拼接。比如订单号里如果包含特殊字符不编码的话对方网关很可能直接返回400。2.3 JSON序列化和解析的标准姿势ABAP侧和外部系统交互JSON的序列化/反序列化我基本都用/UI2/CL_JSON。老版本有人用CALL TRANSFORMATION但结构复杂数据维护起来太痛苦。序列化时注意字段名大小写映射。外部系统通常用camelCaseABAP结构体默认大写如果直接用默认序列化出来的JSON可能是ORDER_ID对方解析不了。标准做法是用漂亮模式DATA(lv_json) /ui2/cl_jsonserialize( data ls_request pretty_name /ui2/cl_jsonpretty_mode-camel_case ).反序列化同理/ui2/cl_jsondeserialize( EXPORTING json lv_response pretty_name /ui2/cl_jsonpretty_mode-camel_case CHANGING data ls_response ).这里有个版本差异要留意在部分旧版本SAP_BASIS上serialize用的是compress参数而不是pretty_name同一套代码跨版本跑的时候行为不一样。做项目前先确认一下当前系统的/UI2/CL_JSON支持哪种写法否则同样是camelCase在不同环境可能一个成功一个静默失败。2.4 响应读取和连接关闭不能分家响应读取用get_cdata( )这没悬念。但连接关闭的时机很多人处理不好。HTTP客户端用完之后必须显式close( )释放资源而且要在所有分支都能执行到的地方做这件事。我是这么处理的TRY. lo_client-send( ). lo_client-receive( ). ev_status lo_client-response-get_status( )-code. ev_response lo_client-response-get_cdata( ). CATCH cx_root INTO DATA(lx_root). RAISE EXCEPTION TYPE zcx_rest_demo_error EXPORTING text lx_root-get_text( ). FINALLY. IF lo_client IS NOT INITIAL. lo_client-close( ). ENDIF. ENDTRY.FINALLY这里的意义就在于无论前面是正常返回、超时、还是解析异常连接都能被释放。我那次生产事故缺的恰恰就是这个FINALLY。3. 我实际执行过的用例清单从200到429之间的所有分支3.1 正常路径只断言HTTP 200远远不够正常路径测试不应该是“返回200就行”必须把断言做到业务数据层。我给每个接口设计的正常用例至少包含这几类断言断言项具体做法HTTP状态码断言等于200或201而不是只要不是5xx就算过顶层业务字段如status字段等于预期的READY且不能为空明细数量返回列表的条目数要和查询条件对应防止接口版本变更导致字段被舍弃关键ID回读POST创建后返回的ID必须能用GET再查出来幂等性对GET接口用相同参数连调两次结果一致如果对方支持幂等POST也要验证重复提交不产生重复数据我之前遇到过一个真实案例接口调用正常返回200但items数组一直为空。开发说“接口能通”业务说“数据不对”两边吵了半天。最后发现是对方把items改名成了itemListABAP侧映射字段还是旧的解析出来自然全是空。如果正常路径用例里带上了“断言明细不为空”这一条这个问题在测试阶段就能暴露。3.2 边界数据和格式的魔鬼细节RESTful接口测试最容易翻车的就是边界数据。我建议至少覆盖这些场景空请求体POST接口传一个空JSON看返回是400还是200错误信息是否可读。字段长度上下限对方限制remark最多200字符ABAP侧如果不校验直接传500字符部分服务端会直接500而不是友好提示。特殊字符中文字符、单双引号、反斜杠、换行符混在字段里发送和接收是否出现转义错误。大量数据比如一次返回5000条记录响应体可能几百KB甚至几MBABAP侧解析是否有性能瓶颈、传输是否会超时。数字精度金额、数量类字段外部返回浮点数ABAP若用P类型接收要做好舍入规则确认用STRING接收虽然不会报错但下游做计算时必须再转换这一步在测试用例里要写清楚。这些边界用例的价值在于它们不依赖业务逻辑却决定了接口在真实环境下的健壮性。3.3 异常分支把错误读“对”比调通更重要异常分支是我个人认为RESTful测试里最值得投入的部分我针对常见状态码都设计过对应用例状态码可能原因用例动作期望行为400请求体格式错误、必填字段缺失故意传错误JSON记录错误日志且错误信息可读401Token缺失或过期不传Authorization头系统提示认证失败不允许继续业务流程403无权限用无权限的账号调有权限接口返回明确无权限提示404路径不存在故意拼错资源路径不能当成成功处理也不该抛未捕获异常408 / 504网关超时用mock延迟响应ABAP侧能捕捉到超时异常并分类处理429被限流mock连续返回429有重试或退避策略不把错误直接抛给用户500服务端内部错误mock返回500记录完整请求ID日志中包含请求体和响应体便于排查这里我特别强调429的处理。很多ABAP顾问没写过限流逻辑但真实网关几乎都有限流策略尤其批量同步类接口特别容易被限。我的建议是收到429后不要立刻重试等待几秒后再重新调用重试次数要有限制比如最多3次如果还是429就必须走告警和人工介入流程。这个逻辑写起来没几行代码但测试起来要反复验证mock服务这时候就特别有用。3.4 认证和安全相关用例认证用例经常被忽略因为连接外部系统时“第一次能通”就默认账号没问题。但Token过期、账号被锁、证书变更都会导致突然的401或握手失败这些场景如果不先测试上线当天就可能是事故现场。我的经验是要覆盖Token过期后调用失败、刷新Token后调用成功、无认证信息时系统不会泄露内部错误细节、日志中不打印Authorization头和完整请求体。尤其是日志脱敏很多项目在排错时喜欢把整个请求对象打出来但请求体里往往包含业务敏感数据这个习惯要尽早纠正。4. 用本地模拟服务把调试成本降下来4.1 用Python搭一个可复现的Mock服务真实外部接口往往不稳定测试环境加白名单、数据造数都费劲。我的做法是在本地或者内网虚拟机里搭一个轻量Mock服务用Python的Flask就能实现不需要额外重型框架。from flask import Flask, request, jsonify app Flask(__name__) app.route(/api/orders/order_id, methods[GET]) def get_order(order_id): if request.headers.get(Authorization) ! Bearer test-token: return jsonify({error: unauthorized}), 401 if order_id 999999: return jsonify({error: order not found}), 404 if order_id 888888: return jsonify({error: too many requests}), 429 return jsonify({ orderId: order_id, status: READY, items: [ {sku: A100, qty: 2}, {sku: B200, qty: 1} ] }) if __name__ __main__: app.run(host0.0.0.0, port8098, debugTrue)这个Mock服务能随意控制返回结果想测404就传指定ID想测401就不带Token想测429就触发指定路径。ABAP端只需要把BASE_URL指到http://虚拟机IP:8098完全不用等对方联调环境。4.2 Mock服务带来的三方面收益第一是稳定性。真实外部系统经常半夜升级、白天限流测试跑着跑着就挂了Mock服务不存在这个问题用例执行结果可复现。第二是负向测试。故意返回500、429、延迟响应验证ABAP端的分支处理逻辑这是真实接口很难模拟的。你不能要求对方“你们故意挂一下让我看看处理逻辑对不对”但Mock服务随时可以。第三是回归效率。真实联调环境数据会变化今天返回3条明细明天可能返回30条测试断言很难稳定Mock服务返回固定数据用例跑完就能对比结果。4.3 借助测试替身做ABAP侧单元测试对更底层的ABAP单元测试我还会用测试替身的方式。核心思路就是前面类设计里提到的get_http_client方法真实代码返回if_http_client实例测试代码返回一个手动构造的假对象通过设置假对象的响应内容来模拟各种返回。用SAP标准框架cl_abap_testdouble可以创建测试替身然后配置方法行为。这样用例跑在开发系统里不依赖任何外部网络速度极快适合代码提交前的快速验证。真正的端到端联调再交给上面那个Mock服务去做。5. 踩过最深的四个坑与完整排查链路5.1 JSON字段大小写问题同一套代码在不同版本表现不一样接手某项目时代码在开发机跑得好好的预览环境的同一个接口返回的数据却全是空。查了半天字段名映射对不上。问题出在/UI2/CL_JSON的camelCase参数在版本之间有过调整同一个pretty_mode-camel_case写法在某个版本下对orderId这种多段命名映射正常在另一个版本下却完全没效果。排查这类问题的链路我总结为三步先打印实际返回JSON字符串确认外部系统返回的字段名到底长什么样再用/UI2/CL_JSON单独做一次反序列化测试把解析结果和原始JSON对比定位是映射问题还是数据类型问题最后确认目标环境的SAP_BASIS版本找到对应的兼容写法并在代码里加注释说明版本差异避免后续维护的人再踩。5.2 连接未释放从“偶发失败”到“系统瘫痪”的完整定位过程前面提到的那次生产事故完整的排查链路其实很有代表性我在这里再梳理一遍。第一步现象层。业务反馈“系统时不时的查不到数据”但重启后马上恢复。这时候不能只查接口要看整个调用链路的状态。第二步日志层。拉出ABAP应用日志发现大量CX_SY_CONNECTION_CLOSED异常但看不出规律。第三步资源层。到系统里查进程和连接状态发现HTTP连接数持续上涨稳定在一个高位。GC和内存看着正常但连接数明显不对。第四步定位代码。排查所有分支路径发现只有当调用超时或返回异常时代码会提前RETURN或抛异常跳过了释放连接的逻辑。这个问题的本质不是“连接没关”而是“所有分支都必须关连接”。所以后来我写所有HTTP调用一律强制使用TRY...CATCH...FINALLY结构并且把连接释放放在FINALLY里。这是一个很小的代码习惯但能从根本上避免连接泄漏。5.3 字符编码ABAP系统代码页和UTF-8之间的乱码坑外部接口返回的JSON绝大部分是UTF-8编码而SAP系统内部有自己的一套代码页体系。如果在老系统里直接用get_cdata( )读取响应遇到中文长文本或者特殊字符经常会出现乱码或者奇怪的替换符。推荐的处理方式是用转换类显式处理编码而不是依赖系统默认行为DATA(lo_conv) cl_abap_conv_in_cecreate( encoding UTF-8 ). lv_text lo_conv-convert( lv_raw ).发送方向同样要注意构造请求体之后如果请求体里有中文最好在set_cdata前用UTF-8转换一遍确保对方服务端收到的数据完整。很多“对方说我传过去的中文乱码”的问题问题往往出在这一步。5.4 超时参数和登录语言两个特别容易被忽略的默认行为超时参数属于那种“平时没人管出事就背锅”的配置。if_http_client的连接超时和接收超时默认值并不激进在异常场景下界面可能会卡很长时间。我的建议是生产环境显式设置连接超时10秒、接收超时30秒具体值按接口耗时特征调整然后把这个参数放到测试用例清单里用mock延迟响应验证超时后的行为是否符合预期。登录语言这类问题更隐蔽。ABAP端调用HTTP接口时请求头里会默认带出系统的登录语言如果对方服务端根据Accept-Language返回本地化错误提示同一段错误信息在不同客户端语言下可能完全不同。测试用例里的断言如果写死了错误文本换台电脑跑就会挂。解决办法是显式设置要发送的语言头保持各环境一致lo_client-request-set_header_field( name Accept-Language value en-US ).这个小配置在标准文档里很少会被提到但实际联调时遇到“同样的错误不同环境提示不一样”的情况多半就是它引起的。我现在的习惯是每写一个RESTful调用类先花半小时把需要覆盖的分支整理出来把Mock服务和测试替身搭好再写真实调用逻辑。看起来多花了一点时间但省下的排查时间绝对不止一倍。最后再分享一个实用小技巧把每轮测试用到的请求体和响应体完整留存成文件出了问题直接对比前后差异很快就能判断到底是对方改了字段还是我们传错了参数。这个方法帮我处理过好几次跨团队扯皮的事故比任何调试工具都好用。
