我有一个具有许多依赖项的 Delphi 应用程序，并且很难重构它以使用 DUnit（它很大），因此我正在考虑使用 AutomatedQA 的 TestComplete 之类的东西从前端 UI 进行测试。
我的主要问题是错误修复或新功能有时会破坏之前（手动）测试并用于工作的旧代码。
我已将应用程序设置为使用命令行开关来打开可以测试的特定表单，并且我可以创建一组需要完成的值和单击。
但在我做任何激烈的事情之前我有几个问题......（以及在购买任何东西之前）
- 值得吗？
- 这是一个很好的测试方法吗？
- 测试的结果应该在我的数据库（Oracle）中，testcomplete中有没有一种简单的方法来检查这些值（多个表中的多个字段）？
- 我需要设置一个测试数据库来完成所有自动化测试，是否有一种简单的方法可以自动重新设置测试数据库？ 除了删除用户级联、创建用户、...、impdp。
- testcomplete 中有没有办法为 exe 指定命令行参数？
- 有没有人有类似经历。
I have a Delphi application that has many dependencies, and it would be difficult to refactor it to use DUnit (it's huge), so I was thinking about using something like AutomatedQA's TestComplete to do the testing from the front-end UI.
My main problem is that a bugfix or new feature sometimes breaks old code that was previously tested (manually), and used to work.
I have setup the application to use command-line switches to open-up a specific form that could be tested, and I can create a set of values and clicks needed to be done.
But I have a few questions before I do anything drastic... (and before purchasing anything)
- Is it worth it?
- Would this be a good way to test?
- The result of the test should in my database (Oracle), is there an easy way in testcomplete to check these values (multiple fields in multiple tables)?
- I would need to setup a test database to do all the automated testing, would there be an easy way to automate re-setting the test db? Other than drop user cascade, create user,..., impdp.
- Is there a way in testcomplete to specify command-line parameters for an exe?
- Does anybody have any similar experiences.
发布评论
评论（7）
我建议您计划同时使用 DUnit 和 TestComplete 之类的东西，因为它们各自有不同的用途。
DUnit 非常适合单元测试，但很难用于整体应用程序测试和 UI 测试。
TestComplete 是少数真正支持 Delphi 的自动化测试产品之一，我们的 QA 工程师告诉我他们的支持非常好。
但请注意，设置自动化测试是一项庞大且耗时的工作。 如果您严格应用单元测试和自动化 UI 测试，您很可能会得到比生产代码更多的测试代码。
对于大型（现有）应用程序，您在实施自动化测试方面会遇到困难。
我的建议是首先设置单元测试，并结合自动构建服务器。 每当有人将任何内容签入源代码管理时，单元测试就会自动运行。 不要尝试直接为所有内容设置单元测试 - 对于现有应用程序来说，这工作量太大了。 只要记住每当您添加新功能以及每当您要进行更改时就创建单元测试。 我还强烈建议，每当报告错误时，您都应创建一个单元测试来重现该错误，然后再修复该错误。
I would suggest you plan to use both DUnit and something like TestComplete, as they each serve a different purpose.
DUnit is great for Unit Testing, but is difficult to use for overall application testing and UI testing.
TestComplete is one of the few automated testing products that actually has support for Delphi, and our QA Engineer tells me that their support is very good.
Be aware though that setting up automated testing is a large and time-consuming job. If you rigourously apply unit testing and auomated UI testing, you could easily end up with more test code than production code.
With a large (existing) application you're in a difficult situation with regards to implementing automated testing.
My recommendation is to set up Unit Testing first, in conjunction with an automated build server. Every time someone checks anything in to source control, the Unit Tests get run automatically. DO NOT try to set up unit tests for everything straight up - it's just too big an effort for an existing application. Just remember to create unit tests whenever you are adding new functionality, and whenever you are about to make changes. I also strongly suggest that whenever a bug is reported that you create a unit test that reproduces the bug BEFORE you fix it.
我也有类似的情况。 （具有大量依赖项的大型应用程序）。 几乎没有自动化测试。 但人们非常希望解决这个问题。 这就是为什么我们要解决每个新版本中的一些问题。
我们即将发布新产品的第一个版本。 初步迹象是好的。 但这是一项繁重的工作。 因此，下一个版本我们肯定需要某种方法来自动化测试过程。 这就是我已经引入单元测试的原因。 尽管由于依赖关系，这些不是真正的单元测试，但您必须从某个地方开始。
我们所做的事情：
但要求清单上还有更多，确保整个团队有足够的工作直到退休。
也许我有点奇怪，但清理代码可能很有趣。 没有单元测试的重构是一项危险的工作，特别是如果有很多副作用的话。 我们使用结对编程来避免愚蠢的错误。 还有很多测试课程。 但最终我们有了更干净的代码，并且引入的新错误数量极少。
哦，请确保您知道这是一个昂贵的过程。 这需要很多时间。 而且你必须抵制连续解决多个问题的倾向。
I'm in a similar situation. (Large app with lots of dependencies). There is almost no automated testing. But there is a big wish to fix this issue. And that's why we are going to tackle some of the problems with each new release.
We are about to release the first version of the new product. And the first signs are good. But it was a lot of work. So next release we sure need some way to automate the test process. That's why I'm already introducing unit tests. Although due to the dependencies, these are no real unit tests, but you have to start somewhere.
Things we have done:
But there is far more on the list of requirements, ensuring enough work for the entire team until retirement.
And maybe I'm a bit strange, but cleaning up code can be fun. Refactoring without unit tests is a dangerous undertaking, especially if there are a lot of side effects. We used pair programming to avoid stupid mistakes. And lots of test sessions. But in the end we have cleaner code, and the amount of new bugs introduced was extremely low.
Oh, and be sure that you know this is an expensive process. It takes lots of time. And you have to fight the tendency to tackle more than one problem in a row.
我无法回答所有问题，因为我从未使用过 testcomplete，但我可以回答其中一些。
1 - 是的。 回归测试是值得的。 当你破坏了以前可以工作的东西时，当客户回来找你时，作为一名开发人员，你会感到非常尴尬。 确保所有曾经有效的东西仍然有效总是一个好主意。
4 - Oracle 有一个名为 Flashback 的东西，它可以让您创建一个数据库中的还原点。 完成测试后，您可以跳回到该还原点。 您也可以编写脚本来使用它，
FLASHBACK DATABASE TO TIMESTAMP (FEB-12-2009, 00:00:00);等I can't answer everything, as I've never used testcomplete, but I can answer some of those.
1 - Yes. Regression testing is worth it. It's quite embarrassing to you as a developer when the client comes back to you when you've broken something that used to work. Always a good idea to make sure everything that used to work, still does.
4 - Oracle has something called Flashback which lets you create a restore point in the database. After you've done your testing you can just jump back to this restore point. You can write scripts to use it too,
FLASHBACK DATABASE TO TIMESTAMP (FEB-12-2009, 00:00:00);, etc我们正在考虑使用 VMWare 来隔离我们的一些测试。
您可以从保存的快照开始，因此您始终拥有一致的环境和本地数据库状态。
VMWare 操作可以编写脚本，因此您可以从网络位置自动安装最新版本，启动测试并随后关闭。
We're looking at using VMWare to isolate some of our testing.
You can start from a saved snapshot, so you always have a consistent environment and local database state.
VMWare actions can be scripted, so you can automatically install your latest build from a network location, launch your tests and shut down afterwards.
大概。 设置和维护测试可能是一项艰巨的工作，但是当您拥有它们时，可以非常轻松且一致地执行测试。 如果您的项目正在发展，某种测试套件会非常有帮助。
我想说，正确的 DUnit 测试套件是更好的第一步。 但是，如果您有大型代码库，但不是为测试而设计的，那么设置功能测试比设置 GUI 测试更加痛苦。
TestComplete具有ADO和BDE接口。 或者您可以使用 VBScript 中的 OLE 接口来访问所有可用的内容。
是的。
Probably. Setting up and maintaining tests can be a big job, but when you have them, tests can be executed very easily and consistently. If your project is evolving, some kind of test suite is very helpful.
I would say that proper DUnit test suite is better first step. However if you have large codebase which is not engineered for testing, setting up functional tests is even bigger pain than setting up GUI tests.
TestComplete has ADO and BDE interface. Or you can use OLE interface in VBScript to access everything that's available.
Yes.
在（旧）应用程序中引入单元测试的一种方法是拥有一个“启动数据库”（如 Rich Adams 描述的“闪回”功能）。
该程序 som unittest 使用 DUnit 来控制 GUI。
请参阅 http://delphixtreme.com/wordpress/?p=181 上的“使用 DUnit 进行 GUI 测试”
每次测试都通过恢复到“启动数据库”来开始，因为这样就可以使用一组已知的数据。
One way to introduse unittesting in an (old) application could be to have a "Start database" (like the "Flashback" feature described by Rich Adams).
The program som unittest using DUnit to control the GUI.
Se the "GUI testing with DUnit" on http://delphixtreme.com/wordpress/?p=181
Every time the test is started by restoring to "Start database", because, then a known set of data, can be used.
使用事务：测试完成后执行回滚。 这应该将所有内容恢复到初始状态。
推荐阅读：
http://xunitpatterns.com/
Use transactions: perform a rollback when the test completed. This should revert everything to the initial state.
Recommended reading:
http://xunitpatterns.com/