一直等不到Pe同学的“自动化测试”恩仇录的后续，我也来插两句嘴吧；一是刚好在这方面也有一点点东西想和大家分享，另外是给Pe同学一点压力，让他早点放出后续~~呵呵，开玩笑的啦:)

关于自动化测试，我的经验没有Pe同学丰富，不过也基本完整的参与做过一个小项目的自动化测试的开发。在这里就和大家分享一些其中的感触和经验吧。当然我不会完整地讨论如何为一个项目设计和开发自动化测试--要谈这个话题本人的道行还浅了点，呵呵。这里想分享的是在给项目做测试自动化的时候在准备阶段要注意的两个问题。

一. 测试框架和编程语言的选择
首先，在明确了当前产品的状况是可以自动化以后，第一个问题就是要选择什么样的自动化测试框架和编程语言。关于自动化测试框架的选择：
    1）优先考虑公司内部已有的并且仍然在使用的测试框架；因为
            a）它们是经过时间和实践检验的，而且
            b）你随时可以找到对这个框架很熟悉的人去问，所以学习成本会低不少。

    2）其次考虑当前业界正在被广泛使用并且等得到广泛认可的测试框架，因为它们的质量（quality）是经过了很多精英的软件开发者和公司的检验的。（这里推荐一个STAF，有兴趣的可以去这里看看）
        但是这个选择的不足之处是这样的测试框架往往比较复杂，需要相对较大的学习成本才能掌握。

    3）最后才是考虑自己开发测试框架。理由是显而易见的，因为自己开发测试框架需要投入大量的人力和时间。
        但是当对测试框架的功能需求相对简单，或者资源和时间充裕的情况下也可以优先这个选择。

关于编程语言的选择就相对简单一点了，只要：
    1）易于和产品集成；
    2）学习难度小，开发速度快；
    3）当规模增大时，可维护性较好--在下面我们将看到，自动化的收益往往会是一个长期的过程，所以测试程序的可维护性也是比较重要的考虑。

二. 哪些是需要自动化的测试用例？
当测试框架和编程语言确定以后，接下来要面对的问题就是面对已有的大量的测试用例，我们应该有什么样的策略来进行筛选呢？
也许有人会问：“全部自动化就好了啊，为什么要筛选呢？”事实是100%的自动化大多数时候都是不现实和不合理的目标。因为：
    1）受到测试框架和编程语言的限制，不是所有的测试用例都的可以自动化的；
    2）即使所有测试用例理论上都可以自动化，100%的自动化所消耗的成本（时间，人力，etc）也不一定能被接受。
那么，我们的策略是什么呢？一句话概括就是“选择投入产出比最高的测试用例来做自动化。” 那“投入产出比”如何计算呢？这就取决于你对于自动化测试的期望是什么样的了。关于期望，首先的首先，“自动化测试”一定不是用来帮你找到更多的产品缺陷的！比较合理的期望是“用来验证在产品的开发过程中的代码修改没有不断的引入已知的可能缺陷，从而从一个比较长期的时间段来看，达到节省测试成本（人力，时间，etc）的目的”。从这个理解出发，我们的具体可操作的策略就是“在实现难度相近的情况下优先选择那些将最可能被执行更多次的测试用例”。因为虽然自动化的执行一个测试用例比手动执行的成本要低，但自动化一个测试用例的成本是要比这个节省的成本要大很多的。所以只有当这个测试用例需要被执行多次的时候，这个节省的成本不断累加才能够最终“赢利”。

ps：做测试自动化，如果只考虑在当前的产品版本的应用，收回成本甚至赢利有可能是mission impossible，但是从长期来看一般来讲，设计好的测试自动化应该能继续在产品的新版本中或者售后维护阶段发挥更大的作用从而做到真正的“赢利”。所以在设计测试自动化的时候应该有一个测试程序将需要被长期的使用的考量在里面。

嗯，目前我想到的就是这些了，Pe同学的后续文章应该能给大家带来更多的关于自动化测试的东西的：）也欢迎大家给我们留言一起讨论有关自动化测试的问题。

A.L.