应该知道的自动化测试陷阱[1] 自动化测试工具
在项目启动会议上，项目经理告诉大家说将在项目中采用自动化测试工具，然后指定你在下周的会议之前提交一份工具选型报告。你感到很惊讶，项目经理是从什么地方了解到自动化测试的，为什么突然对自动化测试这么着迷，你突然想起几周前某个工具厂商的销售人员曾经到公司拜访……
你忧心重重，难道项目经理已经掉入了所谓的自动化测试陷阱中?!
陷阱1：自动化测试工具是万能的!
到目前为止，还没有一款商业测试工具能支持从测试计划，到测试设计，再到测试执行的自动化。
你经常会在某些测试工具的产品推介会、演示会上看到演讲者展示测试工具的种种好处、优点，让你为自动化测试激动不已;但是他们往往不会告诉你自动化测试的难点所在，实施自动化测试的复杂度，以及所需的投入有多大。
你的项目经理也许就在这时候开始一步步迈向自动化测试的陷阱。
陷阱2：一个工具能适合所有项目
到目前为止，还么有一款工具可以支持所有操作系统环境。
你也许会被项目经理要求寻找一款可以支持所有实时嵌入式系统测试的测试工具，而你们的应用需要跑在各种操作系统环境上，包括VxWorks、Integrity、mainframe、Linux 和 Windows XP，编程语言包括Java和C++。
陷阱3：引入自动化测试工具后，测试人员的负担立即减轻
引入自动化测试工具后，并不会马上就减轻测试负担，事实上一开始往往会增加负担。
项目经理往往希望通过引入自动化测试工具来减轻测试负担。但是经验表明，在一个新项目中尝试实施并且有效地应用自动化测试，往往需要经过一条学习的曲线。测试的负担并不会马上减轻，但是项目经理却希望马上看到自动化测试发挥其威力，希望马上看到效果。
事实上，在一开始的时候，很大可能会增加测试的负担，因为测试工程师需要一段时间熟悉和掌握测试工具，而与此同时，手工测试一刻也不能停止，因此测试的负担没有减轻，反而加重了。
另外，自动化测试需要仔细的分析被测试应用程序，哪些部分需要和能够被自动化实现;并且需要仔细地设计和开发测试脚本。这些无疑都将加重测试的负担，尤其是在初始阶段。
陷阱4：引入自动化测试工具后，进度可以马上被压缩
上了自动化测试工具之后，整体测试进度不会马上缩短，相反，在初始阶段，往往会对进度造成一定的延误。
另外一个误区是，自动化测试工具能马上缩短测试时间表。但是由于测试的负担在初始阶段加重了，因此很自然地，我们不能期待进度缩短，相反，在引入自动化测试后，我们应该给初始阶段的进度表预留一些时间。一旦整个自动化测试的流程建立起来之后，我们就可以期待自动化测试给我们的进度带来积极的影响。
陷阱5：自动化工具是很容易使用的
自动化测试工具要求测试人员掌握新的技巧，通常需要额外的培训。应该制定培训计划，投入时间和成本，度过学习的曲线。
通常很多工具厂商都会夸大自己产品的易用性，他们会否认所谓的"学习曲线"。工具销售人员通常鼓吹所谓的"录制/回放"可以简单地记录下测试工程师的键盘和鼠标动作，然后再简单地回放出来。
但是，有效的自动化测试远远不仅仅是"录制/回放"那么简单。录制下来的脚本需要手工修改，以便让其可重用性和可维护性更强一点、更灵活一点，而这些都需要语言和脚本知识。因此他们需要针对工具和内建的脚本语言接受培训。
陷阱6：所有测试都可以被自动化
并非所有的测试都可以被自动化。
自动化测试是手工测试的增强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时，最好先验证一下，工具是否能识别出所有对象和第三方的控件。这对于基于GUI的测试工具来说非常重要，因为这类工具往往在识别一些个性化控件方面有困难，例如一些calendar、spin、grid控件，而这些控件被广泛应用在程序界面中，并且这些控件往往由第三方编写，大部分测试工具厂商未能跟上他们的发展速度。
文章来源于领测软件测试网 https://www.ltesting.net/
