我有三个简单的问题。
有人使用 QuickTest Pro 进行自动化测试吗?
您推荐的任何其他自动化测试应用程序?
自动化测试是个好主意吗?
谢谢
我是一个使用 QTP 的自动化团队的负责人,我讨厌它。记录/播放功能很糟糕,它经常会混淆,导致奇怪的测试结果。Record 只能用于构建对象数据库,即使这样,也不得不进行各种黑客攻击,以使其能够可靠地工作。
QTP/QC 基于 ActiveX/COM,只能使用 VBScript 编写脚本,VBScript 是另一包火焰狗屎。为了获得任何形式的可扩展性,我们必须做所有这些黑客和技巧。我们正在做一些事情,比如运行一个测试,将 QTP 测试动态添加到测试套件中,编辑输入参数,更改对象存储库以使其与环境匹配,保存测试,生成调度程序实例以运行测试。测试完成后,将所有结果复制到父测试,然后从测试集中删除 QTP 测试。最后,我们最终发布了自定义 COM 组件,VBScript 调用并使用 QTP/Quality Center 作为半成品报告引擎,它并没有真正提供足够的灵活性来获得我们真正需要的报告类型。
Mercury/HP 的另一个问题是他们将所有的技术支持外包给了印度,并且没有对他们进行培训。通常要在较低级别的支持炼狱中花费 2 周时间,然后才能与任何对 API 有任何技术知识的人交谈,结果却被告知是的,这是一个错误,但不,我们不会修复它。
我对强硬的语言感到抱歉,但我发现整个情节都令人痛苦,并且永远不会再为使用 QTP/QC 的项目或团队工作。
SO上有几个关于测试自动化的线程:
我从未使用过 Quick Test Pro,但我参与过几个使用不同自动化测试工具的项目;Silk Test,理性机器人,WinRunner。这些努力中最成功的是使用带有 RRAFS 框架的 Rational Robot 将应用程序更改与测试脚本隔离开来。我们还使用STAF框架来自动化和管理我们的测试基础设施。
自动化测试是测试应用程序方面的一种很好的技术,但它并不能取代人工测试人员。像所有工具一样,您可以使用它,也可以滥用它。只要您正在测试的内容是稳定的、重复的、具有可预测或可计算的结果,并且您测试的频率足够高,那么自动化的成本最终会收回成本。
我发现非 UI 的自动化测试绝对值得。
UI 的自动化测试也是值得的,但没有那么多。对于我的项目,UI 不到代码的 10%。UI 的自动化测试还有很多其他问题,比如时间和线程访问,这使得它比预期的更困难。我使用 nunitforms 进行 UI 测试。
我建议如果可能的话,先测试 UI 背后的逻辑,然后再测试 UI。通过非 UI 测试,您可以获得更好的收益。
我评估了自动化 QA 的测试程序,它看起来不错,但我选择了 nunitforms,因为它更类似于我为非 UI 测试所做的。
“自动化测试”并不像听起来那么好。据我所知,测试执行的自动化只是流程的一部分。
哪种自动化测试?
我已经编写了一些脚本,它们是构建后过程的一部分,以通过 API 比较一些结果,但这并不是您想要的。
在自动化的windows用户界面应用方面,我对理性机器人有所了解,但不能特别推荐。
在我工作的地方,我们不使用 QuickTest Pro,但我们正在研究自动化系统测试的选项。就建议而言,如果不知道您接受或拒绝软件工具的标准是什么,这有点困难。我根据这些标准来判断自动化系统工具:
这些只是能力。成本当然是一个因素。该工具是否需要学习用于脚本的专有语言是另一个因素。
自动化测试绝对是个好主意。自动化测试是持续集成的关键推动因素之一。
如果任务中有重复,任何任务的自动化都应该存在。例如,在一个模块中,如果您必须为每个构建运行回归测试用例,其中对产品进行了一些小的改进,那么可以运行回归测试用例自动化。在此示例中,重复测试用例的自动化将提高生产力并使测试人员能够更多地专注于手动测试。
除了 qtp,您还可以探索 qt 相关项目的 squish 和 windows C++ 和 VB 项目的测试伙伴。
Dan,我使用 QTP 11 进行自动化。
让我知道您的要求,例如您想要测试哪种应用程序等。许多开源和共享软件工具可用于几乎所有类型的应用程序。
自动化测试是一个好主意,前提是你要自动化的东西不会经常改变。如果没有,您最终会相应地修改测试脚本,而不是在需要时在应用程序上运行它。