老宋的地盘

 找回密码
 我要加入
搜索
查看: 3117|回复: 3

GUI自动化测试的反思

[复制链接]
发表于 2013-12-12 01:43:20 | 显示全部楼层 |阅读模式
加过不同类型的GUI测试项目,其中包括Java SWING, Web Page, Flash, WinForm, Excel Addin等。总结起来,有以下几点值得反思的。
   
1)通常GUI自动化测试的ROI是非常低的。这些GUI项目大多都经常改变界面,甚至每几个月都需要更改界面,这使得自动化测试用例管理和维护变得非常复杂。GUI自动化最大的弊病在于:它发现Bug的可能性很小,在这些的GUI项目中,通过自动化用例发现的Bug屈指可数,99% 失败的用例都是由于环境或则测试用例本身的原因导致的,而不是发现任何产品Bug.当然,不同项目有不同的特性,Brain Marick有一篇全面关于评估是否自动化测试的文章,可以帮助作出决定。
   
Alan Page是微软的第一个测试架构师(Test Architect,2001),现在负责微软测试的EE工作。他最着名一句话就是“95%的GUI自动化测试工作都是浪费时间”,他本来写的99%,但是为了表示他并非反对GUI自动化测试,他把这个数字改成了95%.
   
2)GUI自动化测试可以提高测试人员的士气。有些测试人员不愿意单单做手工测试,他们需要一些挑战,自动化测试是最好的任务。对于自动化测试,测试人员总是可以根据自己的能力,完成自动测试用例的开发和部署。提高测试人员的士气,比这些自动化测试本身更加有意义。所以,在一定程度上引入自动化测试,是对项目组有好处的。
   
3) GUI自动化测试无法代替手动测试,无法模拟用户的行为。对于GUI测试,我相信手工测试仍然是最重要的测试方法,测试人员在测试GUI软件过程中,有不同操作方法和不同的次序,所有这些变化是一个巨大的组合,无法通过自动化测试完成,很多情况下,也没有必要通过自动化完成。测试人员在手工操作软件过程中,每一步骤都通过思考来验证当前状态的正确性,而这些复杂的思考无法简单快速的转成自动化用例的验证部分。
   
4) GUI自动化测试的进度往往是无法按时完成的。很多测试人员在制定GUI自动化测试的初期,往往过于乐观,希望通过自动化覆盖尽可能多的测试用例。但是,在项目执行的后期,他们发现需要忙于手工测试,另外产品也不稳定,无法顺利完成既定的自动化测试用例,总有很多客观的理由无法完成最初的计划。通常这个时候,他们会改变计划,减少自动化测试用例的数量,而将自动化测试用例仅仅用于基本测试(BVT,Build Verificaition Test)。这些计划的改变,某种意义来说,也是测试资源的浪费。
   
进行GUI自动化测试并非难事,但是如何利用自动化测试来进行高效的GUI测试工作是需要丰富的经验。

您需要登录后才可以回帖 登录 | 我要加入

本版积分规则

歌名 - 歌手
0:00

    QQ|手机版|小黑屋|老宋 ( 备案中... )

    GMT+8, 2024-4-20 14:42 , Processed in 0.165743 second(s), 22 queries , Gzip On.

    Powered by Discuz! X3.5

    © 2001-2024 Discuz! Team.

    快速回复 返回顶部 返回列表