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