QuickTest Pro 自动化测试
我有三个简单的问题。
有人使用 QuickTest Pro 进行自动化测试吗？
您推荐的其他自动化测试应用程序吗？
自动化测试是个好主意吗？
谢谢
I have three easy questions.
Does anybody use QuickTest Pro for automated testing?
Any other automated testing applications that you recommend?
Is automated testing a good idea?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我是一个使用 QTP 的自动化团队的负责人，但我讨厌它。 记录/回放功能很糟糕，它经常会感到困惑，导致奇怪的测试结果。 记录只能用于构建对象数据库，即使如此，也必须进行各种黑客攻击才能使其可靠地工作。
QTP/QC基于ActiveX/COM，只能用VBScript编写脚本，这又是一袋火狗屎。 为了获得任何类型的可扩展性，我们必须做所有这些黑客和技巧。 我们正在做一些事情，比如运行一个测试，动态地将 QTP 测试添加到测试套件中，编辑输入参数，更改对象存储库以使其与环境匹配，保存测试，生成调度程序实例以运行测试。 测试完成后，将所有结果复制到父测试，然后从测试集中删除 QTP 测试。 最后，我们最终发布了 VBScript 调用的自定义 COM 组件，并使用 QTP/Quality Center 作为半成品报告引擎，该引擎并没有真正提供足够的灵活性来获得我们真正需要的报告类型。
Mercury/HP 的另一个问题是他们将所有技术支持外包给印度，并且没有对他们进行培训。 通常，您需要在较低级别的支持炼狱中度过 2 周时间，然后才能与任何具有 API 技术知识的人交谈，结果却被告知，是的，这是一个错误，但我们不会修复它。
我对这种粗鲁的语言感到抱歉，但我发现整个事件令人痛苦，并且永远不会再为使用 QTP/QC 的项目或团队工作。
I was head of an automation team that used QTP and I hated it. The record/playback functionality was horrible, it would routinely get confused resulting in weird test results. Record could only be used in order to build up the object database and even then had to result to all sorts of hacks in order to get it to work somewhat reliably.
QTP/QC is based on ActiveX/COM and can only be scripted with VBScript which is another bag of flaming dog poo. There are all these hacks and tricks we had to do in order to get any sort of extensibility. We were doing things like run a test that dynamicly adds the QTP test to the test suite, edit the input parameters, change the object repository so that it matches the enviroment, save the test, spawn a scheduler instance in order to run the test. Once the test is done copy all the results to the parent test and then remove the QTP test from the test set. In the end we ended up publishing custom COM components which the VBScript called into and used QTP/Quality Center as a half-assed reporting engine that didn't really offer enough flexibility to get the type of reports we really needed.
Another problem with Mercury/HP is that they outsourced all of their tech support to India and didn't train them. It was common to spend 2 weeks in lower level support purgatory before you could speak to anyone with any technical knowledge about the APIs only to be told that yes it's a bug but no we won't fix it.
I sorry about the strong language but I found the whole episode traumatizing and will never work on a project or for a team that uses QTP/QC ever again.
SO 上有几个关于测试自动化的线程：
我从未使用过 Quick Test Pro，但我参与过几个使用不同自动化测试的项目测试工具； Silk Test、Rational Robot、WinRunner。 这些工作中最成功的一项是使用 Rational Robot 和 RRAFS 框架来将应用程序更改与测试脚本隔离。 我们还使用 STAF 框架来自动化和管理我们的测试基础设施。
自动化测试是测试应用程序各个方面的好技术，但它并不能取代人类测试人员。 与所有工具一样，您可以使用它，也可以滥用它。 只要您所测试的内容是稳定的、重复的、具有可预测或可计算的结果，并且您测试得足够频繁，那么自动化的成本最终会收回成本。
There are several threads on SO concerning test automation:
I've never used Quick Test Pro, but I've been on several projects that have used different automated test tools; Silk Test, Rational Robot, WinRunner. The most successful of these efforts was the one that used Rational Robot with the RRAFS framework to isolate application changes from the test scripts. We also use the STAF framework for automating and managing our test infrastructure.
Automated testing is a good technique for testing facets of an application, but it doesn't replace human testers. Like all tools, you can use it or you can abuse it. As long as what you're testing is stable, repetitive, has predictable or computable results, and you test it often enough, then the cost of automating will eventually pay for itself.
我发现非 UI 的自动化测试绝对值得。
UI 的自动化测试也值得，但没有那么多。 对于我的项目来说，UI 只占代码的不到 10%。 UI 的自动化测试还存在许多其他问题，例如计时和线程访问，这使得测试比预期更加困难。 我使用 nunitforms 进行 UI 测试。
我建议如果可能的话，首先测试 UI 背后的逻辑，然后最后测试 UI。 通过非 UI 测试，您可以获得更好的经济效益。
我评估了自动化 QA 的测试程序，它看起来不错，但我选择了 nunitforms，因为它与我为非 UI 测试所做的更相似。
I've found automated testing of non-UI to be definitely worth it.
Automated testing of the UI is also worthwhile, but not as much. For my project, UI is less than 10% of the code. Automated testing of the UI has a bunch of other issues like timing and thread access that makes it more difficult than expected. I use nunitforms for UI testing.
I'd suggest that if it is possible, test the logic behind the UI first, then test the UI last. You get much better bang for buck with non-UI testing.
I evaluated Automated QA's testing program and it looked good but I went with nunitforms since it was more similar to what I was doing for non-UI testing.
“自动化测试”并不像听起来那么好。 据我所知，测试执行的自动化只是该过程的一部分。
'Automated testing' isn't as good as it sounds. As far as I can tell, it's the automation of test execution which is only part of the process.
哪种自动化测试？
我编写了一些脚本，它们是构建后过程的一部分，用于通过 API 比较一些结果，但这并不是您特别想要的。
在自动化Windows用户界面应用程序方面，我对rational robots有所了解，但不能特别推荐它。
which kind of automated testing ?
I've written a few scripts that are part of a post-build process to compare some results through the API, but this is not specially what you want.
In terms of automated windows user interface applications, I've had a glimpse on rational robot, but cannot specially recommend it.
我工作的地方不使用 QuickTest Pro，但我们正在研究自动化系统测试的选项。 就建议而言，如果不知道接受或拒绝软件工具的标准是什么，那就有点困难。 我根据以下标准来判断自动化系统工具：
这些只是能力。 成本当然是一个因素。 该工具是否需要学习专有的脚本语言是另一个因素。
自动化测试绝对是一个好主意。 自动化测试是持续集成的关键推动因素之一。
We don't use QuickTest Pro where I work, but we are in the process of researching options for automated system testing. As far as recommendations go, that's a bit difficult without knowing what your criteria are for accepting or rejecting a software tool. I'm judging automated system tools according to these criteria:
These are just capabilities. Cost is certainly a factor. Whether or not the tool requires learning a proprietary language for scripting is another factor.
Automated testing is definitely a good idea. Automated testing is one of the key enablers of continuous integration.
如果任务中有重复，则任何任务都应该自动化。例如，在模块中，如果您必须为每个构建运行回归测试用例，其中产品中进行了一些细微的改进，那么可以运行回归测试用例自动化。 在此示例中，重复测试用例的自动化将提高生产力和效率。 将使测试人员能够更加专注于手动测试。
除了qtp之外，您还可以探索qt相关项目和应用程序的squish。 Windows C++ 和 Windows 的测试伙伴 VB 项目。
Automation of any tasks should be there if there are repetition in the tasks.For e.g. in a module if you have to run regression test cases for each build in which some minor improvements are made in the product, then the regression test case run can be automated. In this example, automation of the repitive test cases will increase productivity & will enable tester to concentrate more on manual testing.
Apart from qtp, you may also explore squish for qt related projects & test partner for windows C++ & VB projects.
Dan，我使用 QTP 11 进行自动化。
让我知道您的要求，例如您想要测试哪种应用程序等。许多开源和共享软件工具可用于几乎所有类型的应用程序。
自动化测试是一个好主意，前提是您要自动化的内容不会经常更改。 如果没有，您最终将相应地修改测试脚本，而不是在需要时在应用程序上运行测试脚本。
Dan, I use QTP 11 for automation.
Let me know your requirements like what kind of application you wanna test etc. Lot of open source and shareware tools are available for almost all kind of applications.
Automated testing is a good idea, provided what you are going to automate is not gonna change very frequently. If not, you will end up modifying the test scripts accordingly more often than running it on your application when needed.