只有问题，没有答案 -- 也说自动化测试

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

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的原因--测试人员看不懂自动化测试的某些结果，一般还是会参与到部分测试中），如何与测试人员，开发人员沟通交流，其工作内容定义，都还是问题。


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

在 很多公司有QC,就是指写完程序后再来挑刺的.(上传到svn上之后)

另至少QC打回来后我还有测试用例可以用.

mock1234提出不少观点，首先确认一下，我这里提到的自动化测试应该是面向系统级别的，而非xp中提到的测试优先里面的那些编写的单元测试用例。
当然，确实我没有去详细的了解TDD，因为精力问题，之前也说了，已经不做这些工作了，同时也不知道自动化测试如何走下去，至少现在我花费精力在其上，是对我自己时间的一种浪费。
其次，我这里提出的都是现实问题。也可能是所处位置的不同，我就是使用GUI工具来编写用例脚本的，我并没有权力来改正别人的观点，同时，我们的测试用例大概是100多个，并针对16种语言，如果1种语言full run的话，大概是一个晚上的时间；你说的很对，自动化测试与手动测试很不同，但是使用我们编写的这些自动化测试脚本的，恰恰是这些原先进行手工测试的同事们，所以在观念上，还是手动的那一套。

关于工具问题，不太清楚大家是如何处理的，我们花费了很多时间在其上，但是工具并不是你来编写的，有很多问题是不知道如何寻找和解决的。可以说算是悬疑问题。

其实关于第1条，mock1234的回复是很理想化的，但是除非你们的自动化测试工具是自己开发的，不然无法回避这个问题。

现在市场上对GUI元素识别最好的应该就是QTP了，我们团队以前开发的时候就是使用的这款工具，使用了8.2版，9.0版，也试用过9.2版，稳定开发阶段使用的是9.0版。面对的应用程序包含了win32（VC编写），JAVA Swing以及.net开发的。

对于win32的程序GUI，如果是用户自定义控件，其识别是有难度的，一般使用virtual object或者绝对坐标来进行解决。而JAVA和.NET，可以使用反射来得到对象的一些属性方法来绕过，这个尽管是无奈之举，但是总归还是可以解决当前的问题。但是从工具本身来说，只能等待其下一版本能够更好的识别对象，无法作更多的工作。

从经验上来讲，视频窗口，菜单，自定义日历，统计型的报表等，这些GUI元素不能识别的可能性比较大。在实际的操作中，带来不少麻烦。