c#如何实现API自动化测试_c#API自动化测试项目实例附完整源码

从窗口句柄“摸进去”：EnumChildWindows 的真实玩法

EnumChildWindows 是 Windows API 里最容易被误用、但又绕不开的黑盒自动化入口点。它不依赖目标程序源码，也不需要 .NET 反射或 UIA，特别适合测试 Win32、MFC、WinForms 甚至部分 WPF（启用 Win32 子窗口模式时）的老系统。简单说：你不需要等目标程序暴露接口，只要它有窗口句柄，就能从外层“摸进去”。这一下就打开了自动化的门，但怎么“摸”得准、“摸”得稳，里边门道不少。

怎么用 EnumChildWindows 找到 TextBox 和 Button 的句柄

关键不是“枚举一次”，而是递归+条件过滤+控件识别组合。很多新手卡在第一步：只调了一次 EnumChildWindows，结果只拿到主窗体的直接子控件（比如菜单栏、状态栏），漏掉了嵌套在 Panel 或 GroupBox 里的真实控件。好比你从大门进去，只在前厅转了一圈，卧室和书房全错过了。

实际操作要分三步走：

• 先用 FindWindow 拿到目标进程主窗口句柄（靠 ClassName 或 WindowName，SPY++ 可查）
• 再用 EnumChildWindows 遍历所有子窗口，回调函数里检查 GetClassName 和 GetWindowText
• 对每个子窗口继续调 EnumChildWindows，实现深度遍历（别忘了加递归终止条件，比如深度 > 10）

常见错误是把 TextBox 识别成 EDIT 类，把 Button 识别成 Button 类——没错，Win32 下它们的原生类名就是这些，不是 .NET 的控件名。所以别按控件名去匹配，得按类名。

示例片段（简化版）：

private List _foundHandles = new();
private void EnumAllChildren(IntPtr hWndParent, int depth = 0) {
    if (depth > 8) return;
    EnumChildWindows(hWndParent, (hWnd, lParam) => {
        var className = GetClassName(hWnd);
        var text = GetWindowText(hWnd);
        if (className == "EDIT" && text.Contains("test")) {
            _foundHandles.Add(hWnd);
        }
        if (className == "Button" && text == "Submit") {
            _foundHandles.Add(hWnd);
        }
        EnumAllChildren(hWnd, depth + 1); // 继续向下
        return true;
    }, IntPtr.Zero);
}

为什么 SendMessage 发文本老是失败

SendMessage 对 EDIT 控件发 WM_SETTEXT 看似简单，但容易栽在三个地方：

• 目标控件没就绪：有些 WinForms 程序会在 Load 后延迟初始化控件句柄，直接发消息会静默失败；
• 线程上下文不对：SendMessage 必须由创建该窗口的线程调用，跨线程发会卡住或返回 0；
• 字符编码问题：.NET 字符串默认 UTF-16，但某些老程序只认 ANSI，得用 SendMessageA + Marshal.StringToHGlobalAnsi。

更稳的做法是组合使用：

• 先用 PostMessage 发 WM_KEYDOWN/WM_CHAR 模拟按键输入（绕过线程限制）
• 或用 SetForegroundWindow + keybd_event（适合简单场景，但会被用户中断）
• 对关键步骤加等待：比如发完文本后，SendMessage(hWnd, WM_GETTEXTLENGTH, ...) 检查长度是否匹配

如何避免被目标程序反自动化检测

不少工业软件（如 PowerMill、SolidWorks 插件界面）或金融客户端会主动检测鼠标/键盘模拟行为，典型表现是：按钮点了没反应、文本框输不进、甚至弹出“检测到异常操作”提示。这时别急着怀疑自己代码写错了，问题很可能出在目标程序的手段上——它可能在读 GetAsyncKeyState、监控 WH_CALLWNDPROC 钩子、或检查 GetMessagePos 是否为 (0,0)。

绕过思路很实际：

• 不用 mouse_event，改用 SendMessage 直接发 BM_CLICK 给按钮句柄（无鼠标移动痕迹）
• 避免全局钩子，所有操作基于已知句柄，不注入 DLL
• 关键操作前调 AllowSetForegroundWindow(ASFW_ANY)，防止焦点抢占失败导致输入丢失
• 加随机延时（50–300ms），避开固定节奏检测逻辑

真正难的不是“能不能点”，而是“点得像不像人”。很多项目败在最后一步：没处理好窗口激活顺序和焦点链，导致 EDIT 控件虽然拿到了句柄，却因没获得输入焦点而丢弃输入。

完整项目结构里最容易被忽略的一环

不是 API 调用，也不是句柄查找，而是进程生命周期管理。你写了个自动点击工具，跑一遍成功了；但第二遍失败——因为上一次的 FindWindow 找到了残留的旧进程窗口（比如程序崩溃后没彻底退出），句柄还在，但内部状态已损坏。

正确做法是：

• 每次操作前，用 Process.GetProcessesByName 校验目标进程是否存活且只有一个实例
• 必要时先 Terminate 旧进程（注意权限），再启动新实例
• 用 WaitForInputIdle 等待主窗口完成初始化，而不是盲目 Thread.Sleep(2000)
• 所有句柄缓存加时效标记，超 5 秒未刷新就视为失效，重新查找

这层逻辑不写进 Services 层，而是放在最外层的执行协调器里——它不关心“怎么点”，只负责“什么时候点、点谁、点失败了怎么办”。这才是工业级黑盒自动化能长期跑稳的关键。