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

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

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

　　* 项目产品复杂度增高，分工很细。老板一般都会倾向于开发工程师尽快地实现代码，然后测试人员扑上去一顿测，鲜有老板愿意投入独立的资源来让测试人员从事自动化测试开发。而且自动化测试在前期的投入比较大，即使这样，也不意味着自动化测试代码易于维护，成为有效资产保留并延用。

　　* 快速迭代导致的自动化测试维护难度增大。需求的经常性变更导致代码结构甚至架构上的变化，具体到自动化测试所以来的，就是用户界面和功能经常性的发生变化，如果测试人员和开发者信息不对等（而这一般是常态），测试人员只能拿着自动化测试资产疲于应付，如果本身再不是专职于此，难度可想而知。需要注意的是，即使可以通过一些技术手段来减轻这种快速变化导致的自动化测试难维护性，比如动态识别，但涉及复杂的产品和功能，这样的努力仍然是杯水车薪。

　　* 测试工程师的代码能力。这是国内一般的通病，测试工程师的技术能力一般是要比开发者低一个档次甚至更多，这种技术能力的不对等，导致测试工程师难以把握自动化测试的开发和维护，因为那也是软件开发，别无二样。而且在“文人相轻”的技术氛围里面，技能的不对等，也很容易造成信息的不对等。测试人员可以说自己是从用户的角度来使用软件和测试，开发者只需要实现代码并修改缺陷。但现在的软件发展根本不再允许有这样清晰割裂开来的团队合作。

　　* 测试案例很多，但覆盖有限，而测试工程师囿于精力无法作探索性测试。这同样同样是资源受限的问题。

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

　　* 开发者自己的代码模块自己实现，自己也最清楚。需要怎么来测试，有哪些前置条件，会有怎样的输出，从API层到用户界面，自己也可以为自己的自动化测试提供方便，反过来又潜在影响了代码的结构，更加可测。

　　* TDD的需要。这是敏捷中很好的实践，也是很难做到的实践。但好处大家都知道。

　　* CI（持续集成）来保证。有持续集成，可以保证测试执行的频率，替代掉手工的无聊并可能导致的错误。

　　* 测试人员来做其他测试，比如探索性测试，不易实现自动化测试的部分。

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

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

　　* 实现。难度在于有没有一个很好的测试框架来帮助实现，脚本的复杂度有多高，是不是易于编写并重构，是否方便技能传递。在自动化的测试案例越来越多时，结构能否依然保持足够的清晰性。开发人员的技术能力是否达到了所需的标准。

　　* 变化。变化的风险有没有实现被考虑进去，在代码层和逻辑层能缓冲掉这样的变化对已有的代码实现甚至整个代码结构的冲击。

　　* 持续投入。自动化测试是需要成本的，尤其在前期，而且也不意味着前期投入够多后来就一定能收获。要投入资源，包括人力、时间、薪水。