自己做过比较长一段时间的自动化测试了，尽管现在已经不做，不过也算积累了一些相关的东西。感觉自动化测试现在也是处于一个变化的阶段，有很多东西只有问题，但是没有答案。

1         对页面UI元素的识别

　　在web页面相关自动化测试中，这些问题可能遇到的比较小，但是如果是测试应用程序的话，元素识别就是一个很大的问题，这依赖于你选择的工具，以及开发团队的配合，如果连UI元素都不能识别的话，那自动化测试就是扯淡。

2         业务逻辑

　　在现在的应用中，复杂的业务逻辑会带来大量的代码量，同时如果业务逻辑进行改变，自动化测试的代码修改也会成为项目的泥潭。对应的业务逻辑最好可以尽量分离出来，同时自动化测试的用例，最好是和手工测试的用例有所不同，自动化测试由于加入了编程的成分，那其测试用例最好成为可重用的。

3         如何保证自动化测试的脚本代码是正确的？

　　这算是一个悖论？用来检查的代码，你如何保证其是正确的。当检查出一个fail出来，首先不去怀疑是程序本身的问题，而是去怀疑这是自动化测试脚本的问题。而如果你使用的自动化测试平台是第三方的自动化测试工具的话，甚至还会怀疑到工具本身的问题。这样在本身工作之外，却又多了其他的check任务。这算是自动化引入的最大问题。当然，这还是由于自动化测试需要引入的测试代码的复杂性引起的，一般现在也自动进行的unit test，也会有这样的问题，但是由于其问题规模较小，代码逻辑比较简单，所以将这个问题覆盖过去了。同时unit test由开发人员本身进行编写，也使得这个问题不容易出现。

4         自动化测试的结果分析

　　从测试数据的准备，业务逻辑的整合，测试脚本的编写，到最后生成结果文件。但是如何分析这个结果文件，也是很麻烦的事情，这个也是和测试用例的编写人员有关，测试用例编写得越详细，在脚本实现的时候就可以根据测试用例的描述来生成对应的结果描述，这样对于单个的测试用例，至少这个结果是可以让结果分析人员满意的。

5         如何重现某种错误

　　这个在手工测试中会发生，但是在自动化测试中产生的概率比手工测试要高得多。当你把测试脚本写完，想着，OK，之后就是每天晚上让它自己run，然后check一下结果就可以了。错！你的麻烦才刚刚开始。当你第二天过来，看到半夜的时候，产生了一个错误，我们现在只有这个错误的截图，以及测试结果文件中告诉你我测试工具一共做了哪些工作造成这些错误。然后你又针对这个用例单独跑一遍，结果为pass。那恭喜你中奖了。一个很难复现的bug。从现象判断不出是怎么产生的，偶然但不是必然会发生。这个很头疼。首先你要确定它是个bug，一般都会让你先check是不是脚本或其他问题。

6         保证自动化测试不被滥用

　　有很多场合是不合适使用自动化测试的，在这些场合去使用自动化测试，就是给自己找麻烦。

7         最重要的，流程

　　相信大家应该承认一点，不管自动化测试这玩艺是好还是不好，只有大型的、长期的项目才会去采用自动化测试，既然是这样的项目，那就会参与人员众多，自动化测试的脚本开发人员是否参与自动化测试本身的测试工作（由于3的原因，部分4的原因–测试人员看不懂自动化测试的某些结果，一般还是会参与到部分测试中），如何与测试人员，开发人员沟通交流，其工作内容定义，都还是问题。

　　大概就这么多，一会要去开会了，暂时就先发了，当抛砖引玉