自动化测试，就像是一块大馅饼，每个人都想上来啃一口，但是进嘴了，却发现味道各不同，然后心里就会有了各式各样的迷惑。

    1、自动化测试脚本谁来写？

    这在过去似乎不是问题，在现在一些公司内也许也不是问题：理应由测试工程师来负责实现代码测试并维护，因为他们更理解产品，更需要从客户端角度来测试，更熟悉测试案例。但问题是种种现实决定了让测试工程师对自动化测试起来显得困难重重。

项目产品复杂度增高，分工很细。老板一般都会倾向于开发工程师尽快地实现代码，然后测试人员扑上去一顿测，鲜有老板愿意投入独立的资源来让测试人员从事自动化测试开发。而且自动化测试在前期的投入比较大，即使这样，也不意味着自动化测试代码易于维护，成为有效资产保留并延用。快速迭代导致的自动化测试维护难度增大。需求的经常性变更导致代码结构甚至架构上的变化，具体到自动化测试所以来的，就是用户界面和功能经常性的发生变化，如果测试人员和开发者信息不对等（而这一般是常态），测试人员只能拿着自动化测试资产疲于应付，如果本身再不是专职于此，难度可想而知。需要注意的是，即使可以通过一些技术手段来减轻这种快速变化导致的自动化测试难维护性，比如动态识别，但涉及复杂的产品和功能，这样的努力仍然是杯水车薪。测试工程师的代码能力。这是国内一般的通病，测试工程师的技术能力一般是要比开发者低一个档次甚至更多，这种技术能力的不对等，导致测试工程师难以把握自动化测试的开发和维护，因为那也是软件开发，别无二样。而且在“文人相轻”的技术氛围里面，技能的不对等，也很容易造成信息的不对等。测试人员可以说自己是从用户的角度来使用软件和测试，开发者只需要实现代码并修改缺陷。但现在的软件发展根本不再允许有这样清晰割裂开来的团队合作。测试案例很多，但覆盖有限，而测试工程师囿于精力无法作探索性测试。这同样同样是资源受限的问题。

    需要什么样的人来编写自动化测试呢？所有人都会同意应该由那些真正对产品的理解，对测试案例的理解很精通的的人来负责。结合上述的问题，和现在的状况，开发者在这方面占有足够的优势。

开发者自己的代码模块自己实现，自己也最清楚。需要怎么来测试，有哪些前置条件，会有怎样的输出，从API层到用户界面，自己也可以为自己的自动化测试提供方便，反过来又潜在影响了代码的结构，更加可测。TDD的需要。这是敏捷中很好的实践，也是很难做到的实践。但好处大家都知道。CI（持续集成）来保证。有持续集成，可以保证测试执行的频率，替代掉手工的无聊并可能导致的错误。测试人员来做其他测试，比如探索性测试，不易实现自动化测试的部分。

    2、自动化测试到底难在哪？

    有一些问题，在自动化测试实现中，是要考虑的：

实现。难度在于有没有一个很好的测试框架来帮助实现，脚本的复杂度有多高，是不是易于编写并重构，是否方便技能传递。在自动化的测试案例越来越多时，结构能否依然保持足够的清晰性。开发人员的技术能力是否达到了所需的标准。变化。变化的风险有没有实现被考虑进去，在代码层和逻辑层能缓冲掉这样的变化对已有的代码实现甚至整个代码结构的冲击。持续投入。自动化测试是需要成本的，尤其在前期，而且也不意味着前期投入够多后来就一定能收获。要投入资源，包括人力、时间、薪水。

    3、选择什么测试工具？

    这需要依据你要自动化的测试包括哪些，多大的量，多深的技术难度，再行选择。问题是，很多时候，一开始根本对这些一无所知，操起个家伙就开始干，但好歹这样也有吃一堑长一智的机会。我认为在选择工具时，考量的因素包括：

要自动化测试案例量有多少？基于Web的还是桌面应用的，还是纯终端的。当然之前要对目前市面上的工具有一个笼统的了解。工具的学习曲线是怎样的？可以很快上手吗？可以很快做技能传递吗？工具的社区效应如何？有足够的参考文档吗？有方便的渠道让你有求必应吗？有源码可以一探究竟吗？公司对选择工具有没有倾向性或者策略上的考虑，如果有，那还选择竞争对手的，或者第三方的就是不甚合适的。工具的发展前途如何？会在你的测试自动化完的时候，甚至还没做完就消亡了吗？工具能允许你的测试案例发生应需的变化而帮助你重构调整吗？能在测试案例日益增多时仍然游刃有余吗？最后一点，我觉得也很重要，这样的工具会让你觉得以后只是在做重复的劳动，还是会让你不停地学到些新东西呢？

    4、自动化测试到底可以测什么？

    自动化测试什么都能测吗？什么都能覆盖吗？显然不。

基于API的自动化测试可以容易实现的，也容易运行并相对容易维护的，比如有些高级的IDE重构功能可以某种程度上帮助你达到这一点。基于UI的很难测，也更难完全覆盖测试。没有一种工具可以帮助你，全部实现你要测试的功能的各个方面，而利用不同工具来实现一个完整的测试案例的自动化，则显得洋枪夹土炮，维护也是个问题。基于Web的则难上加难。因为不同的浏览器对UI的控制是不一样的，你需要考虑自动化测试代码能兼容到不同浏览器。当然，如果你只需要面对一款浏览器，那困难要少一些。

    所以，要选择合适的工具，然后要明白能自动化掉的功能是什么，不能的有哪些，不能一味的借助工具，要考虑到工具实现以及运行维护的成本，有的时候手工可以做一下的动作必须要费很大功夫用工具来完成，以追求片面好成本极高的自动化。

    这是一个学习的过程，有些经验不做过是很难得到的。

    5、老板喜欢自动化测试，你喜欢么？

    自动化测试实现一阶段后，拿出一组数字出来，自动化测试覆盖率多少，节省人力多少，老板看着高兴，自己也开心。但是，是真的开心么？真的对实现了的自动化测试有信心吗？真的能覆盖相应的测试案例吗？可以很好的维护吗？不同的人，心里会有不同大小的结吧？有人会有无知的开心，有人也会有心虚吧。

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54293)
2. 安全测试与渗透测试区别    (阅读：23782)
3. 使用Fiddler对手机应用进行抓包测试    (阅读：7029)
4. 服务器性能测试工具推荐    (阅读：6570)
5. 给Apache做压力测试时遇到的问题    (阅读：6015)
6. WEB性能测试工具推荐    (阅读：5728)
7. 可用性测试好助手——Morae软件的应用    (阅读：5629)
8. 12款很棒的浏览器兼容性测试工具推荐    (阅读：4928)
9. 可用性测试的权衡之道（二）    (阅读：4868)
10. 在线测试不同操作系统不同浏览器网页的显示效果    (阅读：4701)