[说明] 既然是“浅谈”，那当然是浅浅的谈了，再说了，深的我也谈不来^_^
本文为本人个人结合自己在公司中的实践情况谈的一些感想，欢迎讨论，但不想理论。哎，实在是本人理论功底不好，而且懒于辩论。从初中开始，语文就没很好过- -！
自动化测试从广义上来说包括自动化功能测试、自动化性能测试、自动化安全测试、自动化单元测试等等。而我们日常常说的自动化测试一般是指自动化功能测试，本文主要也是从自动化功能测试角度考虑。
[正文]
说起自动化测试的强大，很多人起先的了解来自于测试论坛或者说来自于自动化测试工具厂商对工具的介绍。咱们先来看一段我因为需要而写的一段有关自动化测试的描述（不代表本人真实想法，这是因为有需要才为之的）：
自动化测试就是通过模拟手动测试步骤，执行用某种程序设计语言编制的测试程序，控制被测软件的执行，完成全自动或半自动测试的过程。自动化测试解决了功能测试不仅耗时且高成本的问题。采用自动化测试，企业可以将重点放在改进自动业务过程方面。开发和QA组可以增加测试过程的速度和精确度。整个IT部门可以获得更高的投资回报，而且降低了大量风险。
这段话，个人感觉或许对于像微软这些大公司而言是对的，但就目前中国软件企业现状来说，自动化测试是不是像这段话说的这样真的很难说。单不说我们的定制项目战略与大公司的通用产品战略的差距，就我们公司的质量意识也能使这段话失效。就说以下这点，进行了程序修改后，需要对程序进行比较全面的测试这点，我们的很多公司就不做。原因很简单，上级认为这没有必要、而且是浪费时间，另一点，定制项目的利润可比通用产品少得多得多，哪有那么多钱让我们认真测试呢。而定制项目好像还是我们的主流。
对于自动化测试，有这么一句总结的定义“利用程序测试程序”。这句话很简练吧，自动化测试归根到底也确实是这么个味道。利用工具、利用软件、利用小脚本等等都可以进行自动化测试。本人一直认为自动化测试是一种技术，是一种能力。既然是一种技术，那就不应该用太固定的框框把它限死了。应该是做到随需所用、依需而定。既然是一种能力，就应该用发散的思维去发挥它更多更大的作用。就像阅读这个能力，谁说一定要先划定中心思想，谁说一定要精读，更没人说一定要用三遍阅读法哦。阅读当然得根据读者的目的以及所读文章的特点，甚至是读者的水平来确定读此文章的方法。自动化测试也一样，不一定要用在回归测试上，也不一定要用在集成测试上。有时甚至可以写个小脚本用在解决功能人员测试难的小问题上。这不也是很好的自动化测试嘛。
关于自动化测试工具，厂商说的可以说基本不可信。说什么“录制/回放”就可以实现，“简单得很”。要真相信这个，那你自动化测试的失败也会“快得很”。当然，微软所吹嘘的，要自己编程序来进行自动化测试，而不应该想着使用自动化测试工具来实现自动化测试。这个观点对于微软来说，应该是正确的。但是得看看微软什么现状：就微软的产品，有哪个自动化测试工具能支持得了全自动化测试的？再说了，微软的产品是全世界在卖，那质量要求高，而且利润更高，有的是钱请牛人来编写自动化测试程序。而且微软的人才也是我们这些公司不可企盼的。因此，如果有好的工具，甚至小工具或开源工具，只要能更好的解决公司中的问题，那何乐而不为呢？
可以毫不客气的说，想要进行自动化测试，那还真得会编码。就拿易用性方面名声不错的QTP来说，要是不会编写VBScript脚本，要是不会综合应用QTP内置的对象和函数，要是不了解QTP支持的扩展，那么就是对QTP这个工具没有很深入的了解，那么如何做到能灵活应用呢。要是真碰到特殊问题，那很容易就GameOver了。我曾经拿几个自动化测试工具（如QTP9.2版、RFT7.1版、TestComplete5.0版）试了试一些基本的标准html页面的功能。有的没法完全回放成功，而如果要进行一些特殊的判断或处理，那“录制”基本就不可能了。而且，即使录制的都能成功回放，那能说明这就实现了自动化测试嘛？自动化测试重点还是在测试，要实现的是测试的目的，而不是在于几个工具的使用上。
自动化测试是一种技术、是一种能力，它不是绑定在某种工具上的。在实际的实践中，发现一些自动化测试人员，在熟练掌握一个自动化测试工具后，非常的高兴，而且有点炫耀的味道。于是乎，本人就问他：“你以为会这个工具，你就会自动化测试了吗？你最多就算会这个工具，或精通这个工具，跟自动化测试无关。”（本人说话较直，总喜欢实话实说- -！）。这里要说的是，要注意自动化测试不是工具的必然。如果只是把自动化测试定位在一两个工具上，那这个人到头来可能会的不是自动化测试技术，而是工具。当然如果要直接从自动化测试技术入手，可能学起来会没有感观认识，而且进入那个自动化测试思维大门较难。因此，一般的学习和进阶方法可以如下：找一个或两个比较容易实现自动化测试的工具，进行深入的学习，并在项目中进行实践，等有一定实践经验后，自然会有一定的认识的。而这时就需要自己的思维脱离这些自动化测试工具，进而思考自动化测试技术的方方面面。然后当然就是可以试用其他的测试工具（强调一下，不要以为只有测试工具才能用于自动化测试，其他工具也可以的，只要那个工具提供的功能满足应用的需求，那就可以了），或自己编码实现一个小型工具（自动化测试人员是需要编程技术的），或直接用脚本语言编写执行程序等等。这时就是要根据要测试的内容能随心所欲的应用自动化测试了。
接下来根据几个网友的讨论，谈点有关自动化测试框架的认识吧。在开展自动化测试时，没有必要去深究自动化测试框架到底是什么，要怎么定义。因为这个定义的话，估计还没人敢说他有标准的定义。而且即使有标准的框架要求，那我根据公司的自动化测试需要，加入一些东西也是可以的嘛。在应用自动化测试框架方面，个人感觉还是不要跟风的好。有人总喜欢有什么好的框架或功能齐全的框架，就要拿来用。当然并不是说这些框架不好，也不是说不能用。只是说在用时，请考虑一下，自己目前用这些框架真的好嘛？如果刚开展自动化测试，就拿封装度很高的框架来套上，这不仅会增加学习量（框架是要学习的），而且会使测试人员只对框架有概念，而对于原版的工具生疏，要真是碰到框架不好解决的问题，那到时就不好办了。个人感觉，适用自己公司自动化测试要求的框架是比较好的框架。这个框架，可以是开源的，可以是自己开发的，甚至前期可以就几个文件夹或者规范要求或者再加几个共享文件、几个通用脚本等等。
自动化测试也是需要比较完备的规范的，不仅需要脚本规范，也需要适用公司的自动化测试流程规范。只有有了脚本规范，才能使合作开发的脚本更像一个整体，使后期的脚本维护相对容易些。自动化测试流程规范是相当重要的。流程规范需要确定如何与手工测试人员交互，如何获取需求，如何产生测试用例，如何开发自动化测试程序，如何使用自动化测试，如何分析结果等等。如果这些没有确定好，很容易使自动化测试不流畅，甚至于“破产”。
公司中要实行自动化测试，上级领导和现有开发测试人员对质量的意识很重要。举个碰到过的小例子：系统在发布前，按理应该要进行比较完备的回归测试的。但目前的现状就是只进行简单跑跑看看。这对于手工测试来说，时间不太多。而如果用自动化测试来实现了比较完备的回归测试，时间也不见得比手工测试少，因为手工测试没有进行完备的回归测试呀。在对这点的认识上，手工测试人员和上级认为自动化测试确实没有节省时间，也没有产生效益（因为发现的问题几乎没有）。后来我只问了一句：“难道你们认为在发布前也应该找出一堆BUG吗？难道质量保证是没有效益的吗？”。在后来的自动化测试实现中，我当然是拒绝再为这种之前测试就不完备，而且还不被上级和手工测试人员所承认的功能实现自动化测试了。因为这很容易让上级和手工测试人员感觉自动化测试也就这样，还不如手工测试得了。久而久之，自动化测试基本就会被抛弃了。
瞎扯了这么多，主要还是要说明，自动化测试不像厂商吹的那么强大、易用。具体还得自己去试试，就像小马过河不试怎么能知道呢。而且每个人的认识都会不一样的。最后说明一点，咱们国家现在更需要的是创新，而不是复制。当然创新性的应用也是创新呀。
