软件测试自动化之路(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)