1、为什么我们需要UI自动化测试?UI自动化测试的focus应该在哪几个方面?
测试自动化并不是为了赢得老板的赞赏,或者认为这是一个很潮的技术,不用就会落后,而是为了发现问题,提高产品的质量。做UI自动化测试的主要目的也是基于此的。 除此之外,UI自动化测试还可以从一个最终用户(end user)的角度来发现问题,对大数有UI的系统来说,UI是最理想的集成/系统测试入口,也是最需要测试的地方。
UI自动化测试应该集中在:
1)UI的文本,图片显示正确性
2)UI的交互逻辑正确性测试
3)UI上的用户行为正确性测试
4)如果可能,UI的用户体验性测试(这个通常并不适合)
2、什么是GUI自动化测试的难点?
对比手工UI测试,UI自动化测试有如下的难点:
1)从UI测试的角度来说,一个非“预期”产生的缺陷很难被自动化测试发现,而手工测试则能轻松的发现这个缺陷;
2)UI本身的变化性,要想达到和手工测试相同的覆盖率,单纯的UI自动化测试往往很难证明自己的投资回报;
3)UI控件元素本身识别的复杂性;
4)UI自动化测试出现问题时,恢复到下一条测试case执行的场景是复杂的。因为出现这种问题的意外,是非“预期”的;
5)UI的测试case,有很多是关于用户交互方面的,而这方面也其一定的复杂性;
3、如何做出更好的UI自动化测试?
1.要尽量避免UI自动化测试。这点似乎与我们的初衷有点背道而驰。但细想一下,它还是有一定道理的。其原因是API和功能层级来说更加稳定,所以其自动化和维护的成本都比较低。相比而言,UI自动化测试因为有上述的诸多难点,所以其实施起来比较困难,导致它的开发成本和维护成本都要高出许多。因此,有的公司的自动化测试就有一个721原则,即70%的测试工作集中在底层接口测试和单元测试,20%的测试工作为集成测试,其他10%的测试即为界面测试。
2.对于UI本身的变化性和UI控件识别的复杂性,利用ID/Name定位元素设定UI Map,与开发团队约定元素的命名规则,在尽可能的情况下,确保UI的可自动化测试性。当业务发生变更时,一个好的模式或者框架来让测试自动化更加便捷,包括要对业务进行分层,关注数据存储和数据驱动,做到测试数据与测试代码的隔离,UI自动化操作与业务测试逻辑的分离。
3.对UI自动化出现问题时,不能很好的恢复到下一条case的正确执行场景(我们可以称之为恢复测试场景或batch run),可以通过组织良好的case,我们写Case的时候倾向于Case之间是没有关联的。我们希望一个Case在执行的时候,它自己能够将初始化和结尾的工作先做好,A Case和B Case不应该有关系,B Case的成功与失败不应该依赖于A Case的成功与失败,一个好的Case应该这样设计。但是有时候A Case做完,我们需要先添加一个用户,然后再删除这个用户,这种情况下,如果没添加就去删除,则是失败的,两者之间存在一种依赖关系。在这种设计的情况下,有一个解决的思路是支持Case间的依赖,你可以定义一个标签去说明某个Case依赖于其他的Case,这样就先执行被依赖的Case,然后再执行这个Case,确保了执行的顺序。
总结:
从本质上讲,非UI测试和UI测试,是互为补充的,根据其成本和特性的不同,在实际工程应用中也应该领会运用。其基本原则:非UI自动化测试用例为主,UI自动测试为必要的补充,考虑成本因素,UI自动测试可以被手动测试所取代。那么到底哪些情况下需要基于UI的自动化测试用例的,根据我的经验列出下面几种情况,供大家参考:
1.基本用户场景测试和验收确认(acceptance)测试用例。这 类测试用例要求从真实用户的使用角度去测试产品的实现,只有包括了UI层才完整和验证了产品的真实用户体验。从实现的角度来看,这类用例应该是只覆盖最基 本和核心的端到端的用户场景(End-to-End user scenario),对于敏捷开发,会在用户故事中描述用户使用的基本场景。一般不使用基于UI测试实现那些步骤复杂,或者边边角角(corner case)的测试用例。
2.逻辑与用户界面绑定在的一起,无法绕过UI直接测试核心逻辑模块。这 种情况也是不得已而为之,在实际工程中也最经常出现的,它反映了软件构架设计方面存在的问题,即没有很好的模块化、模块之间过度耦合。如果是一个全新的软 件和功能,在项目初期,测试人员应该与开发人员/构架师仔细探讨一下可测试性(Testability)问题,特别是针对自动化测试的可测是性, 比如:逻辑与UI分离,是否易于进行接口测试等。一旦错过这个阶段,到了产品的中后期,就很难为了测试再修改产品代码。