你可能会从铺天盖地的产品说明书，广告，还有很多只顾吹嘘工具的文章了解到很多很多的关于自动化测试工具的优点，但当你辛辛苦苦的把工具下载下来，苦心研究了很久以后，信心百倍地开始在项目中使用工具时，你发现，越来越多的问题出现了。是你太笨了吗？是产品做的不完善吗？其实都不是，只是因为他们没有告诉你其实工具只是个工具，更多的时候它只是商品，商品没有十全十美的，你需要在开始就同时了解它们的优缺点及相应的绕行策略，这样你在以后的实施过程就可以做要胸有成竹。
广告中提及的优点 | 但是。。。 | 因此。。。（弥补策略） |
快速 “脚本执行比人工执行快！！！” | 实际上，测试人员还需要做编写脚本，设置脚本如何运行，解释测试结果，讨论是否需要修复等工作。所有这些工作使得测试执行实际上只是整个测试工作量中的一个小部分。 | 第一次的自动化测试项目将花比纯粹手工测试更多的时间。我们应该将自动化看成是改进测试人员效率的一个工具，而不是一个测试人员的完全替代物。利用测试脚本程序可以很快地将测试人员带到测试应用程序的同一水平线上。 |
全面 “你可以构建一个覆盖应用程序每一个功能的测试包！！！” | 自动化测试覆盖的功能点越多，测试程序就会变得越复杂。自动化测试战胜了消耗时间和测试深度之间的平衡。 | 在做自动化测试之前，详细地说明所有的功能点及其运行条件。利用手工测试的检查表可以发现许多人为的错误。测试人员要集中在测试深度上。警惕将要使用新技术的地方及其预算。 |
可靠 “每次测试脚本在运行时执行相同的操作，因此减少了人为的错误！！！” | 现在的技术只能识别那些已经被编程的部分并进行检查。需要人为地检查并且留意异常的事情 | 利用自动化做些沉闷的工作，如扫描应用程序中期望的菜单标题等。 并且为测试人员给出可能发生的问题的指示。 |
可编程 “你可以编写复杂的测试脚本来找出应用程序中隐藏的信息！！！” | 花在编写复杂测试脚本的时间会象手工测试中“真实工作”的时间一样被检查吗？测试人员乐意成为象遵守纪律的编程人员一样维护复杂的程序代码吗？ | 预算明确的用于自动化研究及开发（及传播）的时间。培训编程人员并核查他们构思逻辑及从API中提取信息的熟练程度。 |
可以重复使用 “你可以测试软件将如何回应重复执行相同操作！！！” | 当软件发生更改时，脚本和图像可能都需要重现编写，甚至要重新设计 | 采用数据驱动的方法：利用spreadsheets或测试说明书数据库来有计划地驱动测试 |
可重用 “你可以重复使用测试脚本来测试应用程序的不同版本，即使用户界面发生了变更！！！” | 为了彼此可以更好的工作，需要在一个公共的架构上创建程序代码 | 强制使用命名规范及函数的公用库。设计模块中的测试脚本从一个共同的起点开始，例如主页。并且追踪使用的测试数据。 |
