【转】GUI自动化测试反思
software testing by Cheno
参加过不同类型的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测试工作是需要丰富的经验。