问QuickTest专业版自动化测试

EN

有几个关于测试自动化的线索：

• Which is better for web testing? Record-Play automation or coding?
• User Interface Testing
• Automated testing of GUI

我从未使用过Quick Test Pro，但我参与了几个使用了不同自动化测试工具的项目: Silk Test，Rational Robot，WinRunner。这些工作中最成功的是使用Rational Robot和RRAFS框架来将应用程序更改从测试脚本中隔离出来。我们还使用STAF框架来自动化和管理我们的测试基础设施。

自动化测试是测试应用程序各个方面的一种很好的技术，但它不能取代人工测试人员。像所有的工具一样，你可以使用它，也可以滥用它。只要你正在测试的东西是稳定的，重复的，有可预测的或可计算的结果，并且你足够频繁地测试它，那么自动化的成本最终会得到回报。

我是一个使用QTP的自动化团队的负责人，我讨厌它。录制/回放功能很糟糕，它经常会被弄糊涂，导致奇怪的测试结果。记录只能用来建立对象数据库，即使这样，为了让它在某种程度上可靠地工作，还必须进行各种黑客攻击。

QTP/QC是基于ActiveX/COM的，只能用VBScript编写脚本，这是另一种火热的狗便便。为了获得任何类型的可扩展性，我们必须使用所有这些技巧和技巧。我们正在做的事情包括运行一个测试，该测试动态地将QTP测试添加到测试套件中，编辑输入参数，更改对象存储库以使其与环境相匹配，保存测试，生成调度程序实例以运行测试。测试完成后，将所有结果复制到父测试，然后从测试集中删除QTP测试。最后，我们最终发布了定制的COM组件，VBScript调用了这些组件，并使用QTP/Quality Center作为一个半途而废的报告引擎，它并没有真正提供足够的灵活性来获得我们真正需要的报告类型。

水星/惠普的另一个问题是，他们将所有的技术支持外包给了印度，而没有对他们进行培训。在你可以与任何有API技术知识的人交谈之前，在底层支持炼狱中花费两周的时间是很常见的，结果却被告知，是的，这是一个bug，但不，我们不会修复它。

我很抱歉我的粗鲁的语言，但我发现整个事件的精神创伤，再也不会在一个项目或使用QTP/QC的团队工作。

我发现对非UI的自动化测试绝对是值得的。

UI的自动化测试也是值得的，但不是很多。对于我的项目，UI不到代码的10%。UI的自动化测试还有一堆其他问题，比如定时和线程访问，这使得它比预期的更加困难。我使用nunitforms进行UI测试。

我建议如果可能的话，先测试UI背后的逻辑，然后再测试UI。通过非UI测试，您可以获得更好的回报。

我评估了Automated QA的测试程序，它看起来很好，但我选择了nunitforms，因为它更类似于我为非UI测试所做的事情。