软件测试自动化之路(2)----测试自动化脚本本身就是软件

纲要：1）TA代码的特点；
                   A ，与其它编程的相通之处
                   B， 与其它编程的不同
                   C， TA适用的场合
                   D， TA的做法
            2）TA开发现在所面临的问题；
                    A，易用
                    B，重用
                    C，有效
                    D，易维护
                    E，快速开发（RAD）
            3）TA的解决方案：
                   A，有的放失
                   B，拿来主义
                   C，数据驱动
                   D，一些具体面微的好的做法（细节上的解决方案）
       TA是用编程的方法去做软件质量保证，发现一些regression issues甚至是新的bug。TA最终会以软件的形式，去实现手工QA 可以做的或做不了的事情。既然是软件编码，那它本身就要遵守一定的编码规则，即也要采取通用的软件开发所要遵守的开发流程，编码规则等等软件工业界公认的标准和方法。我认为这是和其它编程共同的地方。然而在实际工作中，现阶段我们组是这些方面应该加强，如TA开发的流程有一定的随意性，没有严格按需求分析，技术设计，编码，测试，更没有形成相应的文档。
       TA脚本要能去测试被测软件（AUT，APPLICATION UNDER TESTING），相对于通用软件的开发过程它们又要有自己独特的地方。简而言之可以概括如下 几个方面：
         （1）需求分析来源于TESTING CASE，产品设计要依赖于一个相应的已成型的软件（这是目前采取的一种比较通用的模式，它最大的缺点是TA的产品要只滞后于我们实际的测试阶段 ）
         （2）良好的健壮性               
         （3）能容错，但不要放过错误
                     正如第二点所述TA的软件要足够的健壮，我们就要更多的采用ON  ERROR 的形式，但不要忘了记下每一个ERROR的点在任何时候，因为BUG很有可能就在那儿。
         （4）极好的可维护性与升级性
          很多公司TA失败的故事告诉我们：高昂的维护成本是导致TA失败的最终原因。TA成本的故事也会告诉我们，通常一个TA脚本的成本至少要在它运行过15次之后才能收回。
            如果你非要讨论TA能不能完全代替手工测试，就象讨论机器人能否完全代替工人一样没有意义。答案是部分代替，我们现在能做的是选好TA 的实现方向，让TA出现在最能体现出它价值的地方，有如重复的操作，大量的数据输入，实时性能的监测等等任何适合机器（PC）去做的工作。
          

(to be continued)