一、为什么很多公司都说要组建一个自动化测试团队，但极少能建立起来？
● 太过于相信自动化测试，且没有经过严格的自动化测试流程和前期分析设计就草率的进行脚本的开发，最终的结果一定是失败！
● 国内的公司很少有专属的自动化测试团队，往往都是信心十足最后确又虎头蛇尾！这其中也分两种情况：其一，缺乏真正可以做自动化测试的技术人员，每个成员都是在学习阶段，那还谈什么组建自动化测试团队？这最多也就叫兴趣小组？其二，的确有牛人在团队中，但是我们都知道，国内很少有公司会专门组建一个专职做自动化测试的团队，国内现在大多数情况是手动测试和自动化测试并用，那么，自动化测试的优先级肯定没有手工测试那么高，而且项目的任务又多，久而久之，自动化测试的愿景又被搁置于一旁了。
● 其实自动化测试已经做的不错了，但是领导看不到短期内有任何的回报，最后还是搁置了！这其中一方面牵扯到成本问题，另一方面则是领导对自动化测试从意识上就存在误区，没有真正认清什么才是自动化测试的真谛！
二、全职QTP自动化测试工程师的工作内容是什么？问几个心中一直以来的疑问和困惑：
（1）QTP是针对功能测试的，主要是自动化地去做测试，那么它强大的地方在哪儿呢？是它能够发现大量潜在的问题？（似乎没感觉到），还是说可以做到无限重复的执行？我们公司用QTP只是重复运行，用来采集性能数据，所以并不能体会到QTP这款产品“赢”在哪方面。
（2）一个全职的QTP测试人员，每天的工作内容是什么呢？每天修改完善脚本、增加逻辑覆盖率？假如一个成熟的产品有成熟的脚本，那么测试人员只要点一下QTP运行按钮，然后直接拿测试结果？总体来说，还是感觉QTP要求很多，用起来很难且收获也不大。
● 首先回答第一个问题：从这位同行的提问中，推断他对QTP的认识一定停留在录制阶段，他把QTP当成了按键精灵。QTP的强大体现在它是解决自动化测试的最好的工具。其实提问的这位同行对自动化测试概念一定很模糊，他以为自动化测试只是简单地重复工作而没有考虑过验证这个问题。做测试，手工测试是怎么做的？其实说白了，也就是用我们的眼睛来验证，那么QTP就是那个能代替人类眼睛验证的测试工具。就像机器人一样，它不是智能的，它的智能是由人赋予的，所以它能做的操作都是人类事先已经知道的。QTP赢在它的一切，卖的真么贵、市场份儿那么高不是没有道理的，如果去使用其他测试工具一段时间后再回来使用QTP，相信一定会感叹，真实一个好工具啊！
● 接着回答第二个问题：一个全职的QTP人员他要做的事情和开发是一样的，都是一脉相承的。他也要需求、也要框架、也要开发、也要维护等等，修改完善脚本不是每天要做的事情，而是每一个版本发布后要做的事情。如果有一个成熟的产品，用QTP写出了成熟的脚本，那自动化测试的目的不是达到了吗？我们的目的就是每天“点”一下，快速拿到测试结果从而解放人力并可以投入到其他项目的测试中去，这也就是自动化测试的目的和意义。另外，QTP基本上只能发现已知的缺陷，目的是为了保证在新增功能加进来以后老功能不受影响；同时也能够回归以前有问题的功能在修复后是否又重现了。QTP几乎不可能发现新缺陷，那是手工测试阶段做的事情。当然，QTP也真的不是万能的，如它肯定不可能比开源的自动化测试工具更Open、扩展性强等，但是世界上不存在万能的事物！
三、如何才能将QTP自动化测试从无到有地应用到项目中。怎么才能成功实施？有什么成功的要素吗？
这个问题其实问得范围非常广，要回答好很不易，现在分享本人之前自动化测试的一些经验。首先需要了解自动化测试的一个总体实施流程，当接到一个项目之后，需要了解影响自动化测试实施的一些需求，如项目的周期长短、需求变更的频繁度、工具的选择以及工具对测试对象的识别能力等。这样做的目的就是为了确定项目是否适合做自动化测试，并不是每个项目都适合做自动化测试，失败的例子实在是太多了，很大一部分原因就是前期根本没有做充足的分析才会导致后期的被动局面，因此绝对不能忽视前期的这块内容。当这些都确定完成之后，还需要完成一个简单的Demo，用于验证工具对项目中对象的识别能力，这些内容可以归纳在前期的可行性分析方案中。接着需要进行自动化测试设计阶段，这个阶段包括需求分析、自动化用例转化为编写，这里需要注意。不是所有手工测试用例都可以转化为自动化测试用例，有些用例完全不适合做自动化测试，或者说不能用自动化测试完成，也或者需要投入很大的经历才能完成。所以需要在设计阶段就定义好这些可自动化的测试用例，并且还需要定义好公共的用例库以及用例的复杂度。当以上内容都定义完毕后，就可以开始下一步核心工作了，也就是自动化测试框架的开发，其大致包含：创建一些公共的组件、公共函数库、公共对象库、测试用例调度机制、外部配置、错误处理、报表生成等功能，当然，如果不是经验丰富的测试人员，在框架这块处理上是不可能一步到位的，需要后期来适应项目并不断进行改进。一段核心功能完成之后，可以说已经离成功又近了一大步了。最后的工作就是把用例全部完完整整地转化为测试脚本，如果框架搭建的比较牛，这一步实现其实是比较轻松的。当然，一些特殊的难题令当别论，如小部分对象怎么识别不了，那只能通过专家组共同讨论解决方案。
1、自动化测试的优势
（1）回归测试更方便、可靠
（2）可运行更多、更繁琐的测试，且快速、高效
（3）可执行一些对于手工测试来说相当困难或根本做不到的测试
（4）更好地利用资源，使资源的使用更有价值
（5）具有一致性和可重复性的特点
（6）自动化测试脚本完全具有复用性
（7）使软件更有信任度
（8）多环境下测试
2、自动化测试无法做到的事及其劣势分析
（1）永远不可能完全取代手工测试
（2）无法完全保证测试的正确性
（3）手工测试能发现的缺陷远比自动化测试多（手工85%左右，自动化15%左右其中只有1%是新缺陷）
（4）对测试质量的依赖性极大
（5）测试自动化可能会制约软件开发
（6）自动化测试工具是死的，它本身没有任何想象能力
（7）成本投入过高，风险大
（8）自动化测试对测试人员的技术要求较高，对测试工具同样有一定要求
3、何时适合引入自动化测试
（1）项目周期长，系统版本不断
（2）需求变更不频繁
（3）系统中的测试对象基本可以正常识别
（4）系统中不存在大批量第三方控件
（5）需要反复测试，如可靠性测试需要进行上千次的系统测试
4、何时避免展开自动化测试
（1）项目周期短，需求变更频繁
（2）在软件版本还没有稳定的情况下
（3）没有明确的项目测试自动化计划、措施和管理
（4）领导不支持
（5）多数对象无法识别以及脚本维护频繁与艰难，二者有其一，自动化测试注定失败。
版权声明：本文出自 跑跑跑跑 的51Testing软件测试博客：http://www.51testing.com/?591690
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。