余春龙-接口测试Agent在财付通微信支付的探索实践.pdf

1、接口测试Agent在财付通（微信支付）的探索实践 余春龙|腾讯余春龙腾讯金融科技 支付清算测试负责人腾讯T12技术专家/资深架构师，在互联网领域超15年工作经验，先后主导过广告/电商/智能风控等多个大型复杂业务的架构设计、AI应用工作，目前在财付通/支付质量中心探索AI大模型的落地，全面推进质量工作的智能化。目 录CONTENTSI.业界接口测试自动化的常见思路II.支付领域接口测试面临的几个难点III.接口测试Agent设计思路IV.接口测试元数据建模V.资金安全方法论在接口异常测试上的应用VI.总结与下一步计划业界接口测试自动化的常见思路PART 01背景 我们为什么要重点搞接口测试？单元

2、测试接口测试集成测试（1）接口测试，这里仅指“单接口”测试，不包括“多接口编排”。接口测试介于“单元测试”和“集成测试”之间，是开发在日常自测中使用最广的测试方式。（2）在大型分布式系统中，尤其微服务拆分很细的情况下，微服务的接口测试替代了大部分传统单体应用的单元测试，即质量与效率之间取得一个平衡（3）所以，接口测试工具的用户主要是“开发”，不是“测试”，赋能开发，提升开发自测效率工具支撑保姆式1.测试左移的频谱（测试与开发的协作模式）测试只开发测试工具，开发做版本测试测试全程参与每个版本，测试做版本测试我们在这2.接口测试的定位业界接口测试自动化的常见思路大类常见思路问题非AI方法1.流量录

3、制与回放1.只能做回归测试，新接口不行2.需要非常完善的微服务框架+公共函数库+中间件，要能mock所有外部依赖（包括下游接口/DB/KV/本地Linux函数，比如时间戳、随机数.）3.数据安全（现网敏感数据不能直接在测试环境回放，各种加密/签名/脱敏）4.边界场景在现网长时间没流量，异常场景现网没有5.录制过程可能影响现网稳定性基于AI方法2.流量=用例从数据源来说，总共就这几类：接口契约+流量+文档+代码+专家经验但普遍面临以下几类问题：（1）文档质量问题，接口契约/需求文档/技术文档，信息“缺”，“歧义”（2）大模型幻觉：尤其是让大模型读复杂的需求文档/技术文档，幻觉都很严重，不太可行，

4、完全不可控（3）从代码-用例，本身存在悖论。代码本身如果有bug，生成的用例也有bug（4）如果只是生成文本用例，文本=代码，还需要人写。3.接口契约=用例4.需求文档=用例5.业务代码=用例支付领域接口测试面临的几个难点PART 02支付领域做接口测试自动化，面临哪些问题？1.前置造数困难大部分接口都有前置依赖，单接口无法直接测试，比如：要测支付接口，依赖下单接口，下单接口又依赖用户创建接口；要测退款接口，依赖支付接口；要测分期付款/借款接口，依赖支付接口；要测分期付款/还款接口，依赖借款接口；2.测试场景想“全”了吗？测试领域的灵魂拷问之一，对于支付/金融来说，这个问题尤为被关注除了前面，

5、基于AI的方法面临的通用问题：文档质量+模型幻觉 之外，我们还面临以下几类典型问题：3.异常用例生成异常有哪些分类？异常能被穷举吗？支付领域做接口测试自动化，面临哪些问题？4.增量生成很多场景，不是新增接口，而是修改老接口。接口修改之后，新生成的一批用例不能直接覆盖老的用例，如何自动diff，自动合并？5.DB断言自动生成DB断言的准确度能做到多少？接口测试Agent设计思路PART 03措施1 通过造数平台，解藕被测接口和其前置依赖接口用例当前被测接口下游服务业务DB灌入被测接口返回值取数SDK造数平台其它业务系统方式1:取数按标签集(tag1,tag2,.tagn）查询测试数据0123断言

6、造数方式2:实时造数1.每个用例标准化为3个步骤（1）取数（2）发请求（3）断言2.造数，分为提前造和实时造（1）提前造，即屯数，基于master，适用于前置依赖稳定的场景（2）实时造，即早即用，基于特性分支，适用于前置依赖不稳定、一起变更的场景3.无论提前造，还是实时造，对于用例来说，不感知。用例感知的是一个个的“数据对象”4.造数本身的AI化，不在此项目考虑5.开发/测试的分工：测试负责造，开发负责用措施2 工作流拆解+元数据建模，精确控制模型生成质量接口元数据数据元数据算子元数据pict.txt(PICT要素)inteface_test_scenes.csv(测试场景清单）test_ca