再谈UI自动化测试

cleverman

最近还是发现有一些文章，个人对于自动化测试报有很大的怀疑态度，本人也对相关的文章给与了驳斥。我个人和公司对自动化测试都是报有很积极的态度的。这里我想再次的写一篇文章来阐述到底UI自动化测试可以做什么，作为一个优秀的UI自动化测试工程师应该具备有什么方面的技能，以及本人对UI自动化的一些经验和体会。

首先还是要强调一点，API和command line程序都是非常适合用自动化来进行测试的。我想这个观点，即使那些反对自动化测试的人也不应该否认吧？至少我觉得他们应该有这个意识。因此，对于他们反对自动化就集中在了UI自动化方面，我这里也完全站在UI自动化测试的角度来写这篇文章，后边就不再强调了。

再次套用朋友的一句话，＂自动化测试听起来很神秘，学起来很简单，用起来很麻烦＂。我想有过自动化测试经验的人，可能大多都有这个体会吧？前边的过程我就不提了，以后主要探讨为什么用起来会麻烦和怎样简单化自动化测试。总而言之，想搞好自动化测试，还是需要测试人员比较高的技术水平，尤其是编程能力和解决问题，分析问题的能力。

  

首先，我要谈谈自动化测试工具和编程语言的关系。作为一个优秀的自动化测试人员，他的最基本的能力就是编程水平了。所谓编程就是至少要精通一门高级语言，比如Ｊａｖａ，Ｃ＃等等，脚本语言不计算在内。请记住，不是熟悉，是精通。高级编程语言给我们提供很强的能力来实现一些东西。你所精通的语言能力越强，你在自动化测试可以做的事情就越多，越好。简单来讲，论程序的能力来排序是这样的，测试工具－〉脚本语言－〉高级语言（Ｊａｖａ，Ｃ＃）－〉Ｃ／Ｃ＋＋－〉Ｃ＋＋／ＣＬＩ。根据这个语言能力的排序，结合你自己的语言能力，你可以想想你到底具备多少自动化测试能力。我所强调的是，如果你想优秀，你至少要精通一门高级语言，这是必不可少的。如果很多人还只是用测试工具，脚本语言工作而抱怨自动化，我要强烈的建议他们好好去学习一下编程能力先了。他们的问题在于，由于编程能力的不足，使得自动化测试的很多问题没有能力和办法去解决。再谈一下自动化测试工具，无论哪种测试工具，无论他们设计的多么强大，从编程语言来讲，他们最多能够达到脚本语言的能力。也就是说，如果你完全用测试工具来进行自动化的开发，很多问题你还是无法解决的。因此，我推荐的自动化开发方法是高级语言结合测试工具。我的自动化测试逻辑是，用测试工具只是完成ＵＩ操作，其他部分完全用高级语言来实现。我们不能否认高级语言所具有的能力，他们创造出了世界上这么多丰富多彩，这么多优秀的软件，难道开发测试程序会有问题吗？因此，我们的焦点就落在了测试工具的ＵＩ操作部分。

  

第二，关于测试工具。开发语言重要，选择一个合适的测试工具也同样的重要。一个灵活，强大的测试工具可以使你的自动化开发起到事半功倍的作用。结合不同的项目，不同的语言，你可能会有不同的选择。不过，这里我想解释的是，具有了高级语言的开发能力之后，我们期望测试工具来为我们做什么。我前边也说过了，我们所要求自动化测试工具所做的就是ＵＩ的操作。这里边比较重要的是三个方面，一是找到ＵＩ对象，二是操作ＵＩ对象，三是同步。如果一个工具能够让你找到所有的ＵＩ对象，并且能成功操作这些对象，就完全满足我们的自动化开发需要了。如果，工具能够提供同步的功能，就使你能够如虎添翼，不然的话要自己去实现，会麻烦不少。到了这里，你已经具有了所有ＵＩ的操作能力（测试工具提供），并且具有了高级语言的实现能力（高级语言提供），你才有了基本的能力去做一个优秀的自动化开发。没有这些能力的人，我严重怀疑能否做出好的自动化测试。

  

第三，怎样自动化。我的自动化的原则是，尽量少的进行ＵＩ的操作，除非是你本身要测试的ＵＩ。道理很简单，ＵＩ操作由于可能受各种问题的干扰，很容易失败。通过非ＵＩ的方法去实现是更加可靠和快速的。这也是我为什么要强调对于高级语言的精通，具有高级语言的开发能力，你就能过把大量的任务从ＵＩ操作转向了程序操作，使得你的自动化程序的可靠性大大的增强。这里还需要强调的一点能力就是系统应用的能力，比如Ｗｉｎｄｏｗｓ使用的能力。Ｗｉｎｄｏｗｓ的很多的操作是有相关的命令来实现的，不一定非得通过大家熟悉的ＵＩ。记住这个原则：除非是你要测试的ＵＩ，否则尽可能的通过高级语言来实现。我想大家对于高级语言来实现的工作应该还是有信心吧？因此，下边我要谈的内容就完全的与你要测试的界面相关了。

  

第四，怎样进行ＵＩ测试。首先要尽量的减少ＵＩ操作，除非是你必须要测试的操作。比如简洁快速的启动你要测试的界面，用快捷键代替鼠标操作等等。总而言之，理想状态下我们进行的每一次ＵＩ操作，都是我们需要测试的，其他操作尽量避免，不能避免用最可靠的方式去实现。那么我们现在的焦点就变成了，怎样来处理我们真正要测试的ＵＩ了。ＵＩ测试的开发基本上就三个问题：发现对象，操作对象和同步。简单解释一下同步，同步就是有一个机制告诉你何时可以执行一个ＵＩ操作。很多人是用ｓｌｅｅｐ的方式，等待一定的时间去执行下一个操作，这是我非常反对的。我的原则是，尽量少用ｓｌｅｅｐ，就算要用每次最多不要超过一秒。滥用ｓｌｅｅｐ会严重影响测试程序的性能（具体的ＵＩ自动化过程，大家可以参考我的其他文章）。

  

第五，ＵＩ测试错误／异常的解决和Ｄｅｂｕｇ。通过以上的解释，我们只是在自己需要测试的ＵＩ操作才进行ＵＩ操作，否则通过高级语言或者系统命令来实现。是不是我们的ＵＩ自动化就完美了呢？绝对不是，这只是一个基础，还远远没有达到完美。我们在自动化开发和应用的过程中，大部分的时间其实是花费在了异常／错误处理和Ｄｅｂｕｇ上面。这跟真正的程序开发非常的类似，你如果去看代码的话，大量的是在进行返回值得检验和异常的处理。如果我们的程序在运行过程中出了问题怎么办，或者如果没有出现我们期望的结果怎么办？一般来说有三种问题，第一是产品的问题，我们可以报ｂｕｇ了，第二是你测试程序的ｂｕｇ，你需要ｆｉｘ。第三是其他的问题，比如测试工具，甚至高级语言本身的问题，你需要ｗｏｒｋａｒｏｕｎｄ。总而言之，优秀的测试程序最终的目的是，一旦程序的运行发现了问题，就是产品的问题，就是可以报ｂｕｇ的。能够达到这种境界才能算自动化测试的完美，才能算是一个真正优秀的测试人员。（当然了，正如软件产品不可能没有ｂｕｇ，你的测试程序也不可能完全没有ｂｕｇ。但是，由于软件产品是有大量的用户来使用，而你的测试程序只是很小范围内来使用，使得你消除影响测试过程的ｂｕｇ成为完全可能）

  

综上所述，一个优秀的自动化测试工程师必须要具备高级语言的开发能力，自动化工具的灵活应用能力，系统命令和使用的熟练能力等这些基本功，还更要具备优秀的Ｄｅｂｕｇ，Ｆｉｘｂｕｇ的能力，和保持程序稳定性能力。换句话讲，一个优秀的自动化测试工程师必定也是一个优秀的软件开发工程师。

最后谈一下我为什么要转向Ｃ＋＋／ＣＬＩ？从上边的排序大家可以看到，Ｃ＋＋／ＣＬＩ是目前Ｗｉｎｄｏｗｓ平台最强大的编程语言。在我的自动化开发的过程中，我需要高级语言和系统命令都不能完成的功能。如果没有Ｃ＋＋／ＣＬＩ我就必须要通过ＵＩ来实现，从而降低我程序的可靠性。而有了Ｃ＋＋／ＣＬＩ的功能，我就可以绕过ＵＩ操作了。总之，能够绕过ＵＩ操作的能力也体现出一个自动化测试人员的能力。从这个角度讲，测试人员有很多东西要学的。最后说一下，我自动化工作的要求是１００％可靠，我还不能完全满足，因为使用我程序的人是那些手工测试的人，他们的使用环境的变化有可能引起一些问题的产生，基本上还不是我程序的问题，而是测试工具，或者其他模块的问题，我需要想办法去ｗｏｒｋａｒｏｕｎｄ。不过，随着一定时间问题的积累和解决，如果环境不变，应该可以达到１００％可靠。（可是环境的变化是不会停止的，因此实际上很难达到永久的可靠，不过一段时间的可靠还是应该可以达到的，或者说我们的测试开发必须有这样一个目标，就如同软件开发的目标一样）

fengerapple

Thank you very much for sharing!The good man!The good life of peace!

zz45509

1. {:4_85:}

复制代码

282693048

完全同意楼上的观点。。 有点基础的可能就是做开发不是做测试了。。
  茫然勒

xyzwh

现实是,很多测试人员的编程基础差,基础好的就做开发去了.
惭愧哈,还是要好好学习哈

panluhai

支持自动化测试

dabeixiong

不晓得你在讲什么~不知道有没有道理。。。

yangtesting

寒啊 编程能力极弱，看来要加强了

haha_s

赞同楼上几位的观点，开始学习自动化测试，发现自己的编程能力太薄弱了
也希望能借编写自动化脚本的机会多提高自己的编程水平

puchonghui

上次和朋友聊过自动化的问题
偶们的看法是
自动化测试除了对代码严格统一的规范要求以外，对细节的了解程度是个关键。如果对底层细节足够了解，搞自动化便无难度。 ms那套东西，别人想学还真是学不来的。。。。

jaunty

继续C++/CLI 这个
我觉得cleverman 在这里提到C++/CLI来实现程序 去接口被测程序
完全是由于C++/CLI它的强大 因为它跨平台 可以交叉编程 什么东西都可以拿来用
所以说 编程语言你用Java，c#，vb也是照样行的通的

只不过说他们没有c++/CLI那么强大 所以你在测试来自不同领域不同平台的东西的时候会有限制 你会侧不了 你会遇到技术的 绊脚石和卡子


XML知道么？很多东西都可以通过XML互相转换。这样便于沟通

C++/CLI ，就像是利用像XML这样的一种中间物质后使得很多东西都可以无障碍沟通的使用了。当然C++/CLI 肯定是不用XML的

应该是。net平台的中间语言吧。具体的我不知道

只不过我是这么理解的。


所以我觉的语言不是问题
他整篇想强调的是一种测试思想

[ 本帖最后由 jaunty 于 2007-11-23 17:27 编辑 ]

jaunty

原帖由 backtochendu 于 2007-8-13 16:28 发表
软件很多时候是合作工作的，或者说必须要合作工作。你的模块不可能独立任何其他的模块以外
------------------------------------------------------------------------------------------------------------------ ...

我看了cleverman的文章还有你们的讨论。
我看了之后我觉得他说的很有道理。我说说我的理解和看法。 我想你们之间可能是有一些误解。不过的确测试要做到高层面的是需要知道系统的根本然后去操控的而不是依赖外表。

我觉得举个最简单的例子
自动化工具的“识别对象”的原理。
如果你record的脚本只是在UI上去按位置追踪某个对象的操作
如果你的UI一旦变化，你的脚本以后走到那一步就找不到那个对象了。

所以自动化工具就改为去用对象的若干属性作为判断 依次来识别对象。就像QTP是去识别对象的若干属性来识别对象，而RFT是取若干属性之后比较它们的属性权重，然后再判断对象，依此来精准的定位对象。所以你会看到rft的对象识别技术是有认证和商标的。是其他的市面上的商业测试工具鲜有的技术。
因为我们的UI是多变的，但是属性是少变得。所以我们不会再UI层面去抓对象 是从属性层面去抓对象

这是一个简单的例子对于这种思想的理解。
这是我对于cleverman的这种“减少UI操作，尽量用c++/CLI从多环境交叉从事物的本质去抓住它来继续工作” 的这个思想的理解。我从对象识别角度来解释一下。

当然cleverman 不是为了想表达识别对象这么简单的原理

我的理解是
他的意思是说
UI在系统里有很强的逻辑依赖关系。如果你做了很多UI的操作，然后走了某一步后，如果某个UI出了问题之后很多测试工作可能都回受到影响继续不下去了。

如果我们利用这种放弃外表抓本质的思想去做
那么我就可以在当前出问题的ui 停住 然后我们可以继续下面的部分的测试工作。这个时候没有之前的UI生成某些条件来让后面的UI去操作的话，我们就没办法去执行后面的测试阿
怎么办呢
我们就要用高级语言编写程序啊什么的调用API或者系统命令  去创造这些条件 使测试继续进行下去 你就不用停在那里等别人fix那个很简单的UI的某些毛病了

如果我们的测试很多都是基于UI的操作的话 就会出现以上的问题。但是如果你一开始你的测试程序就是抓事物本质来编写或者构建的话
就算UI再怎么变 我们都可以绕过那些侧过的啊 或者有问题出错的啊  的UI部分 去进行其他的模块或者部分的测试

我觉得从这个思想的执行流程上来看，和白盒集成测试的打桩，做驱动 是一样的道理。

这些都是按照我目前的理解层面能给你举出来的例子。

可能cleverman 是愔熟内核的人 他想表达的内容或者操作 测试方法 会更高技术一些  
但是我理解的他想表达的思想就是这个 作本质，这样万变不离其宗。


这是我的理解

有想法继续回帖。

jaunty

楼上的 你是搞It的么？我是不是要给你说你是搞“信息技术”的么？我说API难道我要说你去连应用程序编程接口么？！ 这些字眼是很好翻译的难道我就一定要说中文来表达么？！
你要是说中文跟人家交流这些问题，一定会被人说有病！
你做It的就要做很多technology的东西 大部分都是老外的东西 你想做的高深 先学习外面的东西吧  还有你在外企作一段时间你就知道了 这不是故意卖弄什么 是习惯和必然 因为It技术99%都是外国发明创造开发的 我们都是follow人家的技术和思想，很多东西是无法用中文表达清楚的我想你也理解我看你说到了 难翻译的字。但是我们工作在It环境 整个 控制管理 也是人家老外发明的，我说workaround 才能真正表达到底是什么意思。就像teamwork一样。这个词是老外引进的。真的teamwork只包含我们中文的团队合作这么简单的意思么？！
你做It做久了尤其是你要是再外企做过 包括 台资港资，所有这里的人都是一样的。 大家 不会把 manager去叫个 经理或者 领导之类的。
自己英文差就不要搞IT。你IT想搞得牛先把英文练好吧
这么排斥英文就不要上初中 我们中国人初中就有英语课了。

[ 本帖最后由 jaunty 于 2007-11-23 16:56 编辑 ]

cleverman

被移动了，看看我的话题在哪里。

cleverman

不知道你是真的没明白，还是故意打岔呢？
看来是跟你兜了一个大圈子。
你回头看我的留言吧。我再留言就是又兜圈子了。
不过，还好你不是反对自动化的人。

backtochendu

软件很多时候是合作工作的，或者说必须要合作工作。你的模块不可能独立任何其他的模块以外
------------------------------------------------------------------------------------------------------------------------------
既然你知道这点,那么就更不应该把UI操作用API来实现, 好的模块化完全可以避免你说的问题, 不论如何,用API来代替直接UI操作是不恰当的.

再次说明: 用API能实现的操作, 当时的UI不一定能实现, 你需要明白这点.

cleverman

你不用windows怎么跑你自己的软件？
你建立各式各样的测试环境，只需要你测试的模块就可以了？
软件很多时候是合作工作的，或者说必须要合作工作。你的模块不可能独立任何其他的模块以外。
就算有，也是很少数的情况。我说的是general的情况。

backtochendu

测试工程师必须要善于交流...

如果我有言语过激,,,抱歉...


自动化测试中一个很重要的环节就是异常处理和错误恢复.

你使用API来进行这个工作, 我不认同这种机制.

或许你所在的公司有自己的一套框架,我们看法不同很正常.

你的首要任务是保证自己产品／模块的运行正确
--------------------------------------------------------------
既然如此, 你所谓的"跳过不使用的UI"是别人模块了?
UI自动化牵扯的模块越少越好, 能不牵扯就尽量不要, 可以的话,就不要使用到别人的模块.

cleverman

不知道你测试经验有多少？
UI的操作受很多种因素的影响，都可能fail掉，不是你程序本身的问题。
也就是说不是你产品的问题。是受其他很多因素影响的，出了问题对你来说除了ｂｌｏｃｋ你的自动化测试，没有任何意义。
我说过，ＡＰＩ是跳过不需要的测试的ＵＩ，你管他实际情况怎么样呢？ｆａｉｌ掉也不是你测试的问题。你没有必要花时间去ｃｏｖｅｒ不属于你的工作。
而且影响你整个测试的流程。你的首要任务是保证自己产品／模块的运行正确。工作要有优先级别。如果你真有精力想去ｃｏｖｅｒ其他人，其他公司的产品，那是你个人的问题，不属于普通的测试问题。

backtochendu

我不知道你的文章描述的是哪个测试阶段.

如果已经处于验收测试阶段,一个程序的UI很容易就fail掉,那么根本就不能通过测试.

同样,还是那句话,API能完成的工作,当时的UI界面很可能是不能完成的. 用API来替代直接的鼠标键盘操作,是不恰当的.

cleverman

还有就是C++/CLI不是要跳过你要测试的UI，是跳过不需要测试的UI。
有一些UI的功能，.NET和windows命令不能实现，只能靠调用API来实现。C++/CLI可以方便的进行调用。
如果不调用API，就只能通过UI来实现了，而这些UI是自己不需要测试的UI。你用UI来实现，很不可靠。容易fail掉。