如何做出更好的UI自动化测试

用工匠精神打造精彩文章,分享最新科技资讯,从不同角度剖析资讯内容,剑走偏锋是我的态度,茶余饭后聊百味!各位读者们老爷们好吖,我是文艺与气质于一身实力派小编——小宸,这里可以让您看到最新最有趣的资讯内容,让您感到不同凡响的科技资讯内容,会给大家带来意外惊喜,好了不跟大家逗乐了,给大家呈现今天的精彩内容:

为什么我们需要UI自动化测试?千锋认为是为了发现问题,提高产品的质量。做UI自动化测试的主要目的也是基于此的。 除此之外,UI自动化测试还可以从一个最终用户的角度来发现问题,对大数有UI的系统来说,UI是集成/系统测试入口,也是最需要测试的地方。

UI自动化测试应该集中在:1)UI的文本,图片显示正确性;2)UI的交互逻辑正确性测试;3)UI上的用户行为正确性测试;4)如果可能,UI的用户体验性测试(这个通常并不适合)。

对比手工UI测试,UI自动化测试有如下的难点:

1)从UI测试的角度来说,一个非“预期”产生的缺陷很难被自动化测试发现,而手工测试则能轻松的发现这个缺陷;

2)UI本身的变化性,要想达到和手工测试相同的覆盖率,单纯的UI自动化测试往往很难证明自己的投资回报;

3)UI控件元素本身识别的复杂性;

4)UI自动化测试出现问题时,恢复到下一条测试用例执行的场景是复杂的。因为出现这种问题的意外,是非“预期”的;

5)UI的测试用例,有很多是关于用户交互方面的,而这方面也其一定的复杂性;

做出更好的UI自动化测试:

1)要尽量避免UI自动化测试。这点似乎与我们的初衷有点背道而驰。但细想一下,它还是有一定道理的。其原因是API和功能层级来说更加稳定,所以其自动化和维护的成本都比较低。相比而言,UI自动化测试因为有上述的诸多难点,所以其实施起来比较困难,导致它的开发成本和维护成本都要高出许多。因此,有的公司的自动化测试就有一个721原则,即70%的测试工作集中在底层接口测试和单元测试,20%的测试工作为集成测试,其他10%的测试即为界面测试。

2)对于UI本身的变化性和UI控件识别的复杂性,利用ID定位元素设定UI Map,与开发团队约定元素的命名规则,在尽可能的情况下,确保UI的可自动化测试性。当业务发生变更时,一个好的模式或者框架来让测试自动化更加便捷,包括要对业务进行分层,关注数据存储和数据驱动,做到测试数据与测试代码的隔离,UI自动化操作与业务测试逻辑的分离。

3)对UI自动化出现问题时,不能很好的恢复到下一条用例的正确执行场景,可以通过组织良好的用例,我们写用例的时候倾向于用例之间是没有关联的。我们希望一个Case在执行的时候,它自己能够将初始化和结尾的工作先做好,A用例和B 用例不应该有关系,B用例的成功与失败不应该依赖于A用例的成功与失败,一个好的用例应该这样设计。

但是有时候A用例做完,我们需要先添加一个用户,然后再删除这个用户,这种情况下,如果没添加就去删除,则是失败的,两者之间存在一种依赖关系。在这种设计的情况下,有一个解决的思路是支持用例间的依赖,你可以定义一个标签去说明某个用例依赖于其他的用例,这样就先执行被依赖的用例,然后再执行这个用例,确保了执行的顺序。

今天资讯内容到此为止,大家积极探讨资讯内容,给小编提更多宝贵意见,留下您的关注,小编将持续为大家更新更多的劲爆科技资讯内容,让大家生活充满乐趣。拜拜...

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181026A1QJLN00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券