如何对Windows桌面应用（WPF）执行API测试？

你之前接触的GET/PUT/POST/DELETE本质是资源操作的语义约定，不是HTTP协议独有的东西——HTTP只是把这套“对资源做什么动作”的规则标准化成了请求方法字段。Windows桌面应用的API（不管是进程内调用、跨进程通信、还是对外暴露的本地调用接口），完全不依赖HTTP传输，所以不存在同名的四个方法，但是操作语义是可以一一对应的：

• 语义对等GET：所有读取类操作，作用是获取目标资源状态、不会修改任何数据，常见命名前缀有Get/Query/Enum/Read，比如Windows原生接口GetWindowText、业务程序里读配置的GetAppConfig，和GET一样要求无副作用、幂等。
• 语义对等PUT：所有全量更新类操作，作用是用传入的完整内容替换目标资源的全部状态，常见命名前缀有Set/Replace/全量场景下的Update，比如覆盖写配置的SetUserConfig、替换文件内容的ReplaceDocument，和PUT一样要求幂等，调用完成后资源状态和传入参数完全一致。
• 语义对等POST：所有新增、自定义动作类操作，作用是创建新资源、或者触发没有明确资源映射的复杂动作，常见命名前缀有Create/Add/Execute/Submit，比如新建本地记录的CreateDataItem、触发导出的RunExportTask，和POST一样不保证幂等，重复调用可能产生重复数据、重复触发动作。
• 语义对等DELETE：所有删除类操作，作用是移除目标资源，常见命名前缀有Delete/Remove/Clear/Unregister，比如删缓存的DeleteTempFile、注销回调的UnregisterHook，语义和DELETE完全一致。

别死套命名规则，很多遗留Windows接口尤其是历史比较久的C++接口，会用SendMessage传不同消息值实现所有操作，光看函数名根本分不出来操作类型，必须以接口文档标注的实际功能为准。

你之前学的Web API测试思路90%都能复用，核心都是“校验输入、输出、系统状态变化是否符合预期”，不用从零搭建知识体系，按下面的步骤走就行：

第一步：先明确测试范围，别上来就找工具瞎抓 #

Windows桌面API是个很泛的概念，先找开发确认你要测的接口属于哪一类，不同类型的测试方式差很多：

• 应用对外暴露的供第三方/插件调用的接口：比如COM接口、命名管道接口、RPC接口、DLL导出函数
• 应用内部模块间的调用接口：比如UI层和业务逻辑层之间的类方法、主程序和辅助进程之间的通信接口
• 应用封装的系统调用接口：比如操作注册表、文件、系统权限的封装层

第二步：按语义分类设计用例，补全桌面端特有的测试点 #

先把所有接口按上面说的读/全量更新/新增动作/删除四类分好，直接复用Web API的用例设计逻辑：

• 读接口：重点测返回值正确性、无副作用（连续调用不修改数据、不内存泄漏）、边界场景（读不存在/被占用/超大资源的报错逻辑）、权限控制
• 全量更新接口：重点测幂等性、参数校验（缺字段、错类型、超长值的拦截逻辑）、全量覆盖逻辑（未传字段的处理是否符合预期）
• 新增/动作接口：重点测重复提交的结果、异常场景（磁盘满、资源被占用时的容错性）、返回值和实际执行结果是否一致
• 删除接口：重点测删不存在/被占用资源的报错逻辑、删除后是否有残留、删后重建同名资源是否正常
  额外补桌面端必须测的特殊场景：
• 权限：分别用标准用户、管理员、系统服务权限调用接口，检查有没有越权、提权漏洞
• 鲁棒性：传畸形参数、非法内存指针时，会不会出现进程崩溃、无响应
• 兼容性：在不同Windows版本、不同系统语言环境下，接口返回和行为是否一致

第三步：选对应工具上手，不用一开始就写复杂自动化 #

入门阶段先用现成工具跑通用例，熟了再做自动化：

• 测DLL导出函数：先用工具查看导出函数列表，用Python/C#写几行简单的调用代码就能传参测试
• 测COM接口：先用系统自带的工具查看接口定义，支持直接创建实例调用方法
• 测跨进程通信接口：用进程监控工具抓正常调用时的参数、返回值格式，再模拟构造请求测试
• 测.NET类库接口：直接用反射加载对应DLL，写简单控制台程序就能调用传参

第四步：从最小闭环做测试计划，别搞大而全 #

你刚入门不用一开始就覆盖所有接口，按优先级排期就行：

1. 第一阶段：找开发对齐接口文档，把所有接口按四类语义分类，标记出和核心业务流程（比如保存文件、数据提交、用户鉴权）相关的高优先级接口
2. 第二阶段：先跑通高优先级接口的正向用例，确认正常场景下功能符合预期
3. 第三阶段：补全异常、边界、权限、兼容性场景的用例，按崩溃/功能错误/体验问题分级提bug
4. 第四阶段：逐步覆盖低优先级接口，再把高频调用的核心接口用例做成自动化脚本，减少回归工作量

内容的提问来源于stack exchange，提问作者Wendy V Sw