Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
参加过不同类型的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测试工作是需要丰富的经验。