自动化测试真正的难点在哪里?

DontTest

做自动化测试也有不短的时间了,收获不小,但遇到的困难也不小. 下面我想就我对测试自动化的想法,既主要的问题跟大家分享,主要是功能测试方面,也希望能得到各位的指导.
   
    1.自动化测试(以下简称TA)最重要的是流程,不是细节. 某个Object怎样识别,用什么样的VP验证, 这些确实必要. 但是知道了这些就能做好TA吗? 不可以, 测试的脚本不象应用软件,你做好了就可以不管了, 你必须随着被测软件的升级变化而随时更新.  TA该做什么? TA能做什么? TA什么时候介入测试? TA脚本的存活周期? TA如何与相关部门协作, 应该是什么样的关系? 这些是大问题,但是是最重要的问题.

    2.我们写脚本的目的不是为了写脚本而写脚本,而是为了测试软件. 是否你发现在软件release后, 你的脚本就要退休了? 可事实上你的脚本甚至刚写完, 所以你的脚本可能根本没有达到测试的目的! 你可能会说可以再release后再继续测试,但是既然Release了,你还能找到Bug吗?(记住:你TA的脚本是不变的,如果能发现早就在Release前发现了). 你可能还会说,我的TA脚本用在做回归测试(比如做SP时), 这个想法绝对是优秀的, 也确实能起到一定的作用; 但是,你脚本的Cover rate会是多大,我想你最多也就考虑到主要功能的TA掉了,但是你认为主要功能是Bug最可能出现的地方吗? 所以同样TA脚本其的作用要再次质疑, 这也是难点之二.

   3.TA究竟该如何做? 我确实不想听什么大师级人物吹嘘了, 说的我们都心花怒放, 可静静想来, 可操作性有多少? 全是谈些务虚不可操作的东西.  TA现在缺乏理论支持, 没有理论来指导实践, 这也是举步维艰的真正原因. 大家都凭自己的摸索得做, 可能是有些经验教训,但是这还不成其为理论, 回到第一个难点,不重流程重细节其实就是避实务虚的表现(没在真正需要下功夫的地方下刀, 因为刀不知道该怎么下).

   4.对现有工具过度依赖. Robot,WR,TD and so on,什么都可以搞定? 不可以. 并且工具本身是为大众化设计的,并且应用软件更新比测试工具更新快,所以会不断有工具不能解决的问题..我们是否可以针对我们自己的产品开发出适合自己的测试工具? 是否可以借助现有工具加入自己想法进行扩展? 以期更加适合自己产品的测试. 当然这有赖于测试人员自身的技能.

   5.TA搞得DEV(开发), QA两不象. TA比DEV开发技能上弱, 又比QA对测试的理解上弱.你说TA象什么? 说这的目的,我主要是想说TA要考虑自身的发展, 不是会录脚本就好了. 如何发展,各有看法,我可能也没资格在这说什么.

    先就这么多吧,希望能跟各位多多交流.

[ Last edited by ilovejolly on 2005-9-8 at 11:11 ]

sincky

真正的难点是设计自动化测试脚本，才能避免你说的情况。眼下众多企业还没有到达这个阶段，很多公司用自动化工具的目的也不是为了测试出bug，而是代替手工操作，完成大量的重复性操作。但是不代表测试的目的不能实现，是要个过程的，将来会好的，因为我们做自动化测试的，都在进步！
这篇文章是另外的关于自动化测试实施的参考资料：
http://blog.51testing.com/index. ... =1637&blogId=19

魔海

楼主有这样的想法的确是经验之谈。在我看来楼主似乎对自动化测试工具的期望太高所以才会有这样的落差。我也和大家分享一下我的想法：
1. 自动化测试不能完全代替手工测试，就好像机器人永远也不能代替人一样。不然的话我们中的很多人可能会失业或者是转行。
2. 我们想要自动化测试工具帮我们来做什么？
    在我看来一些简单的而又重复的工作可以交给自动化测试工具，比如：系统每个页面的Session超时的一些问题。
Thanks All

guirongb

我觉得,流程设计阿什么的都是可以解决的,难点恰恰在细节方面,那些无法识别的控件,是完成每一个细节的操作的障碍,包括VP,这些点
至于,界面改动,这类的维护,并不是很难,第一,可以想办法把界面的动作,分解,归类,放在头文件中,这样每一次界面改动,无需到每个脚本去改动,只要改动头文件就行了
第二,自动化测试框架的应用,恰能解决这类的维护问题,但是,正是楼主所说的这些无关紧要的细节问题,大大的阻碍了自动化测试框架的实施...

xiong1000

我个人觉得自动化测试工具并不能代替手工的动作。但是呢，我个人觉得自动测试的好处在于比如我在phase 1的时候录制好并且写好了自动测试代码。在phase2阶段如果我一点修改了某个功能或者某些代码（为了修改一些bug而做的修改）那么我重新测试的时候我就可以完全自动的来全部的轮训一遍，速度和人力就很节约。

不过功能方面我自己做的不多，我主要做一些大规模的集成测试，这个时候如果没有自动工具那么简直就是噩梦，也谈不上测试的运作了。比如我要加20000个用户在几分钟内，那么我唯一选择的就是工具了。不然手控无法处理。

另外对于TA的技术，个人觉得TA可能在做robot录制或者修改脚本上面，技术含量不高。但是你一旦做到经验很高的时候，你在设计测试架构设计的时候你就会明白和发现自动测试的架构不比软件开发架构要简单多少。
我目前在跟进一个robot的测试项目，令我喜欢的不是怎么去修改到手的robot。而是我发现这份代码的可重复使用的实在是设计太好了。
重用在哪里呢？举例说一下
1。对于不同的操作系统，英文中文，系统的对话框都有不一样的。那么有一份专门定义对话框的设置文件。当你测试从英文系统倒中文系统的时候只要修改一下配置文件
2。每个caption的定义又是分在一个设置文件里面的。重用也很高。
3。其他变量也是如何。

不知道搂主对自动化研究有多少，robot的精髓并不是简单的录制，而是测试的组织。初级的自动测试工程师大概就会录制和修改
更高阶的应该就是，测试架构，工程管理，以及考虑测试代码的重用能力。满足不同的需求。那么这样的测试脚本在不同的系统，不同的平台完全或者需要简单的修改就能满足要求。这个是很难的，也是艰苦的工作。

ilovejolly

楼上的说的不错，以后多交流

liwei985

对于不同的操作系统，英文中文，系统的对话框都有不一样的。那么有一份专门定义对话框的设置文件。当你测试从英文系统倒中文系统的时候只要修改一下配置文件


这里说的配置文件是不是指testmanager？还是robot本身可以进行文件读写操作？？
我是新手，刚转测试，学习中，麻烦理解这句话的解释一下下！！

xiong1000

robot其实你用一下就知道类于vc的一些编程方法，也是有头文件可以定义的。
我讲的是一种测试的写脚本的方法思维。
比如你在测试的头文件中定义了一个读文件的功能函数，在头文件实现文件中去实现这个功能。
你准备两分满足不同系统的配置文件，比如对话框设置等等。另外你设定一个具体的判断符号。如果符号为为1那么你采用配置1，如果符号位为2你采用配置2。
那么你在你的具体脚本中，只需要做一个传递一下配置的符号位为多少。就可以具体的根据配置不同进行测试了。
这样避免你写很多的脚本。

具体我会近期整理一下，然后写个帖子。

qingchunjun

期待xiong1000老兄整理的帖子。

cuijy

脚本不是万能的,不可能完全替代手工操作,否则代码维护的工作量比手工测试工作量还大.最好是覆盖主要的用户场景,和重要的流程.
自动脚本的最大优势在回归测试时,当然准确和客观也是其优点.

=====
   4.对现有工具过度依赖. Robot,WR,TD and so on,什么都可以搞定? 不可以. 并且工具本身是为大众化设计的,并且应用软件更新比测试工具更新快,所以会不断有工具不能解决的问题..我们是否可以针对我们自己的产品开发出适合自己的测试工具? 是否可以借助现有工具加入自己想法进行扩展? 以期更加适合自己产品的测试. 当然这有赖于测试人员自身的技能.
=====
建议使用 Rational Functional Tester, 在日食集成环境上开发.对Java测试不错.

dyrain

[quote]Originally posted by cuijy at 2005-10-31 10:21 PM:
脚本不是万能的,不可能完全替代手工操作,否则代码维护的工作量比手工测试工作量还大.最好是覆盖主要的用户场景,和重要的流程.
自动脚本的最大优势在回归测试时,当然准确和客观也是其优点.

对于新手来说最大的难点就是怎样确定主要的用户场景,和重要的流程.我的一个同事对TA崇拜的一塌糊涂，可是在实际应用中并没有起到多少帮助，我想他就是对测试的对象并不理解，TA对他来说只是帮助完成了一些重复的工作，但是怎样覆盖重要的用户场景和流程，我想是新手应该首先学习的，工具永远只是工具！