6.考虑用其他自动化测试类型
LAWST会议上主要集中在GUI层次上衰退测试工具，所以这篇文章主要写的是关于这方面的。在开会前我们参加会议的人主要描述了我们在测试自动化中的经验。一些人作了生动的成功的报告。更大的成功是在于和编写测试程序的人广泛的合作。在这些故事里利用这种类型测试工具成功的案例多种多样，这反映了从不同的测试工具中获取的效益是不同的。
有很多骗局，期望和希望应用基于GUI的衰退测试。他们可以幻想在没有一个独立的工具存在的情况下测试覆盖，这引起一系列的问题，它可以把它的精力更多的放到设计和维护发现更多BUG的用例上。
这些测试工具是可用的，但是他们需要有意义的投资，详细的计划，可靠的培训，和小心的警告来配合。
附录：
关于讨论范围
在最后的三分子一的美一天，我们把一些观点写道白版上，对于不能统一意见的问题通过投票决定。这么做的目标是为了达到每一个观点符合经验丰富的测试人员的经验。在一些案例中，我们不需要投票，既不是因为缺乏特殊的投票经验，也不是因为我们认为这个框架存在问题（我们跳过了很多这样的想法和观点）。
如果你试图去培训和执行自动化化的成本和风险，那么投票是解决这种讨论最好的数据。
通用原则
这些观点不能变为事实。在自动化计划中，需要很多努力，清醒的认识需要解决什么问题，在什么环境下解决。（一致同意）
GUI测试自动化是重要的软件开发，他的成功需要有体系，标准和规定为基础。通用原则适用于软件设计和执行适用于自动化设计和执行（一致同意）
对于实用和维护来说，我们首先需要开发一个包含很多变量的体系结构，来处理软件中的特性变化。我们应该开发基于GUI的自动化满足稳定的特性（一致同意）
一些人有一种应该随着公司自动化发展而变化的预感。一般决议（7 同意 1 否），在缺乏自动化经验的情况下，更多的自动化成果会发展。
扑捉回放失败。我们是否扑获到少量或者窗体部件（对象的朴捉回放）变得无关紧要。
应用个别的编程测试案例失败（个别测试用例代码没有遵守通用标准核建立共享库）
开发的共享库需要维护是必需的。这些库可能包含录制的脚本或者数据驱动测试脚本。
第二个一般决议（10个通过，1个不同意）：通用的自动化失败是原因：
建立测试用例利用扑捉回访的原则。
应用没有标准的测试永例（比如测试用例代码中不遵守通用标准，不建立共享库）
应用设计有缺陷的框架。这是普遍问题
直接回放的册实用例发现的bug率很低（一致通过）
一旦程序通过测试，不代表将来测试可以再次执行不失败。这些引出一些观点（没有人投票）：自动化测试很危险因为他给我们一个虚假模糊的程序不能失败的感觉，即使程序今天不会运行失败不是说明天就继续成功。有很多使程序失败的原因。但是你不需要找寻bug的原因除非你想那么干。
自动化测试中发现的bug 60%-80%的问题是在开发测试中发现。除非你从开始正确使用自动化工具创建和运行测试，否则更多的问题是在手工测试中发现（一致通过）。
更多的测试团队通常不是在一开始自动化工具运行册使用例。传统案例中，开始时候进行手工测试，当程序测试通过后可以把他加入自动化套件中。不管怎样，如果你决定不依靠以前扑获输出来测试，不管是程序测试成功还是测试失败，你都将更加有效的利用测试工具。例如：
运行不同的系统版本或则配置上同样的一系列测试。你可能从来没有在特殊的环境下测试程序，但是你知道怎样让他运行。
运行同等测试。在这个案例中，你运行两个程序，输入相同的序列。如果程序的结果相同那么程序测试成功。
代码经过测试，所以会产生一些系列程序运行日志目录，如异常状态，，状态转变，内存管理，堆空间，或者其他的异常，或者另外定义的程序错误。测试工具通过很多的状态转换来随机驱动程序，记录测试工具可以运行的命令。第二天，测试人员和开发人员通过寻找bug和触发他们的环境的日志来跟踪。这是简单的模拟例子。如果你正在工作在一个和开发团队合作的环境，那么你用测试工具建立的测试用例将比通过手工建立的脚本更广泛和有效（团队每周可以发现新bug）。
当你和开发人员一起开发hooks，接口和调试输出的话，自动化测试将更加成功。（一致通过）
协作的方法：不依靠基于GUI自动化测试工具，简单的使用工具—方便测试驱动程序，没有简单的GUI衰退测试范例。LAWST会议上提供的表格是迷人的，听到关于自动化成功的故事。大多数案例中，和开发队伍协作大多数都获得了戏剧性的成功，不包括传统的仅仅使用（任何使用）基于GUI的衰退测试。
我们可能在LAWST的会议后期研究测试设计和开发之间的写作关系。
大多数代码是由工具建立不可维护和没有长期值的脚本。不管怎样，用测试工具写测试用例因为它可以记录一系列近期发生的事件时，这时候扑获是有用的。通过录制工具建立的脚本可以在给你写自己代码的时候一些提示。（一致通过）
我们不能用屏幕区域来记录一切，因为那时浪费时间。（事实上，我们不在需要的时候才用屏幕区域和使用他们。我们在对比屏幕小的区域中发现问题。有时我们不得不对比屏幕区域，可能因为我们测试的区域友自画工具，但是范围太大了，我们应该对比本地结过，而不是BMP图片）。（一致同意）
不要失去测试自动化验证点。在脚本中添加扑获比寻找BUG要容易得多。（一致通过）
测试设计
自动化简单脚本不是正确策略。（一致通过）
如果你从建立很多的简单测试用例开始，那么你建立强大测试用例前就用完时间。收集大量的例子中，容易通过的测试用例比手工测试可能看上去更严谨，但是一个有经验的手工测试人员可能运行复杂的测试要比程序运行要稳定的多。
组和测试能发现新的bug（总和比部分更总要）（一致通过）
本文地址：http://com.8s8s.com/it/it36893.htm