windows 我可以使用什么脚本工具来对 Delphi 程序进行自动化测试？

What scripting tool can I use for automated testing of Delphi programs?

提问by Mawg says reinstate Monica

I'm looking for a tool for automated testing. I will use scripting for testing, rather than just automating, which means that it can't just send some key-presses. It needs to examine the app's window to see if it was updated correctly. The cheaper the better, with no downside limit on cost. ;-)

我正在寻找一种用于自动化测试的工具。我将使用脚本进行测试，而不仅仅是自动化，这意味着它不能只发送一些按键。它需要检查应用程序的窗口以查看它是否已正确更新。越便宜越好，成本没有下降限制。;-)

I need a real language, with functions, variables, loops, branching, etc., and the apps are developed in Delphi.

我需要一种真正的语言，具有函数、变量、循环、分支等，并且应用程序是在 Delphi 中开发的。

I need to be able to focus controls^*, wait for windows to appear, search for controls/windows, send keyboard input and check that various windows/controls have changed state (e.g a button is now disabled, a text box contains the correct text, a dialog box opens, etc.).

我需要能够聚焦控件^*，等待窗口出现，搜索控件/窗口，发送键盘输入并检查各种窗口/控件是否已更改状态（例如现在禁用按钮，文本框包含正确的文本、对话框打开等）。

I used to use AutoIt a few years ago and am now coming back to scripting. I wondered if there has been any new development while I was gone.

几年前我曾经使用过 AutoIt，现在又回到了脚本编写。我想知道我不在的时候有没有什么新的进展。

Any suggestions?

有什么建议？

* _{I do not want to move the cursor to absolute coordinates in case the app's layout changes. This quote from Wikipediaexplains why:}

*_{我不想将光标移动到绝对坐标以防应用程序的布局发生变化。维基百科的这句话解释了原因：}

Regression testing becomes a problem with GUIs as well. This is because the GUI may change significantly across versions of the application, even though the underlying application may not. A test designed to follow a certain path through the GUI may not be able to follow that path since a button, menu item, or dialog may have changed location or appearance.

回归测试也成为 GUI 的一个问题。这是因为 GUI 可能会在应用程序的各个版本之间发生显着变化，即使底层应用程序可能不会。设计为通过 GUI 遵循特定路径的测试可能无法遵循该路径，因为按钮、菜单项或对话框可能已更改位置或外观。

采纳答案by Fidel

Autoit does everything you listed. I use it for the same porpoises all the time. Also, Delphi is good in the sense that uses standard windows controls which makes it very easy to hook into.

Autoit 会执行您列出的所有操作。我一直用它来对付同样的海豚。此外，Delphi 在使用标准 Windows 控件的意义上是好的，这使得它很容易连接。

回答by Harriv

I believe you just described TestComplete by SmartBear Software.

我相信您刚刚描述了 SmartBear Software 的 TestComplete。

回答by Andrew Walker

I've had some success with sikuli, which has the advantage of being python (jython) code. It is built on top of OpenCV, and uses a full image processing engine to pattern match parts of the screen. It also contains editors and functions for screenshots, waiting on changes, as well as keystroke and mouse injection.

我在sikuli 方面取得了一些成功，它具有作为 python (jython) 代码的优势。它建立在 OpenCV 之上，并使用完整的图像处理引擎来对屏幕的各个部分进行模式匹配。它还包含用于截屏、等待更改以及击键和鼠标注入的编辑器和功能。

回答by Harriv

Something different from my other answer: PyWinAuto

与我的其他答案不同的东西：PyWinAuto

It has full scripting (because it's Python), it uses control names instead of X, Y coordinates, it waits for windows and you can send keypresses. And it's free.

它有完整的脚本（因为它是 Python），它使用控件名称而不是 X、Y 坐标，它等待窗口并且您可以发送按键。而且它是免费的。

The downsides should be obvious :)

缺点应该很明显:)

回答by user2056904

To automate a delphi application main problem i found was that the any testing tools (QTP with delphi addon , Test Complete , Testanywhere, autoit, sikuli) they all dont detect any Tlabels and Tlist and and other components, which for an application build in delphi forms a prominent part of the UI. Even to do func based testing we need to ultimately examine a component in the front end to see whether a func is giving right out. Even to right a script to automate we need to first be able to detect and add the object to the repository.

为了使 delphi 应用程序自动化，我发现任何测试工具（带有 delphi 插件的 QTP、Test Complete、Testanywhere、autoit、sikuli）都没有检测到任何 Tlabels 和 Tlist 以及其他组件，这对于在 delphi 中构建的应用程序形成了 UI 的一个突出部分。即使要进行基于 func 的测试，我们也需要最终检查前端的组件以查看 func 是否正确输出。即使要使脚本自动化，我们也需要首先能够检测对象并将其添加到存储库中。

We have an application in which we have heavy dependency on a lot of third party components. I have tried to check feasibility with almost all the tools available in market. The top two tools in market were of no use.

我们有一个应用程序，其中我们严重依赖许多第三方组件。我已经尝试使用市场上几乎所有可用的工具来检查可行性。市场上排名前两位的工具没有用。

1. QTP with Delphi addon is of no use even in there website they have openly mentioned it wont support many classes build in delphi.

2. TestComplete its better than QTP where in it detects many components menu components and if i remember correctly grid etc.

1. 即使在他们公开提到的网站上，带有 Delphi 插件的 QTP 也没有用，它不支持在 delphi 中构建的许多类。

2. TestComplete 它比 QTP 更好，它可以检测许多组件菜单组件，如果我没记错网格等。

Then after few googling i found

然后经过几次谷歌搜索我发现

1. TestAnywhere which was certainly better in detecting the thirdparty build components. Only problem i found with this was that it was not detecting Tlabel classes and some components dont remember which.

1. TestAnywhere 在检测第三方构建组件方面肯定更好。我发现的唯一问题是它没有检测 Tlabel 类，并且某些组件不记得是哪个。

When i speak of detecting components it may be partial or fully ie some tools were able to detect that there is a component at XY co-ordinates but failed to get the component classes or details (like components property name etc) without which it was difficult in automating and writing a script.

当我谈到检测组件时，它可能是部分或全部的，即某些工具能够检测到 XY 坐标处有一个组件，但无法获取组件类或详细信息（如组件属性名称等），否则很难在自动化和编写脚本方面。

Rest all was more or less combination or subset of these above there.

其余的都或多或少是上面这些的组合或子集。

Still Searching !!!!!!!!!!!

仍在搜索中 ！！！！！！！！！！！

回答by Jason Chapman

With TestComplete, if you compile your app as an open app - i.e. include their libs, it makes your app super inspectable. Great for testing, probably not best for security. Test complete was the best, it is just TOOOO expensive for my budget.

使用 TestComplete，如果您将您的应用程序编译为一个开放的应用程序 - 即包含它们的库，它会使您的应用程序成为超级可检查的。非常适合测试，但可能不适合安全性。测试完成是最好的，它对我的​​预算来说太贵了。

The scripting in it is great, the understanding of Delphi is great. The pricetag is just not great, especially if you are trying to get traction for GUI testing within an org, like it sounds like you are.

里面的脚本很棒，对Delphi的理解很棒。价格标签并不高，尤其是当您试图在组织内进行 GUI 测试时，听起来就像您一样。