编写UI自动化测试用例原则

1、一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器。
2、一个脚本脚本只验证一个功能点,不要试图用户登陆系统后把所有的功能都进行验证再退出系统
3、尽量只做功能中正向逻辑的验证,不要考虑太多逆向逻辑的验证,逆向逻辑的情况很多(例如手
号输错有很多种情况) ,验证一方面比较复杂,需要编写大量的脚本,另一方面自动化脚本本身比较脆弱,
很多非正常的逻辑的验证能力不强。 (我们尽量遵循用户正常使用原则编写脚本即可)
4、脚本之间不要产生关联性,也就是说编写的每一个脚本都是独立的,不能依赖或影响其他脚本。
5、如果对数据进行了修改,需要对数据进行还原。
6、在整个脚本中只对验证点进行验证,不要对整个脚本每一步都做验证。

时间: 2024-08-03 07:35:51

编写UI自动化测试用例原则的相关文章

用java和junit编写app自动化测试用例

package myTest; import static org.junit.Assert.*; import io.appium.java_client.android.AndroidDriver; import org.junit.After; import org.junit.Before; import org.junit.Test; import org.openqa.selenium.By; import org.openqa.selenium.WebElement; import

用python和unittest编写app自动化测试用例

import unittest import webdriver import time class Test(unittest.TestCase): @classmethod def setUpClass(self): cap = {} cap['platformName'] = 'Android' cap['platformVersion'] = '4.4.2' cap['deviceName'] = '7N2SSE158P001892' cap['noReset'] = 'noReset'

如何用Airtest编写UI自动化脚本

前言 游戏并不像app一样直接把渲染树节点暴露出来,这就造成游戏UI自动化在元素定位上的不方便性,不过依赖airtest的图片识别,我们可以直接跳过元素检查,以图片对比的形式进行自动化,虽然效率可能会低一些,但是至少也是自动化了. 脚本文件的创建 首先需要创建脚本文件,airtest提供了两种格式的文件——.air后缀和.py后缀: 虽说分开了两种,但两者之前其实差别不是很大(源码中.air文件最终也是较换成.py文件执行),具体选择哪个看个人喜好,个人比较喜欢纯python文件,因此创建的为.

UI自动化和selenium相关以及八大定位

一.UI自动化相关 1. UI自动化的本质(重点) 定位元素→操作元素→模拟页面操作→断言→测试报告 2. 适合UI自动化的场景 UI自动化的前提条件 (1)需求不能频繁变动 (2)UI稳定(UI自动化就是基于UI层面的,UI界面总变化无法开展) (3)项目周期长(UI自动化脚本编写和调试耗时,项目周期短纯手工更高效) (4)回归测试频繁(回归测试多就会有不断的主流程功能需要回归,自动化更高效) 适用场景 (1)冒烟测试 (2)主功能回归测试 3. UI自动化的原则 (1)一个case完成一个功

【Android测试】UI自动化代码优化之路(临时发布)

关于UI自动化的抱怨 听过不少人这样讲 "UI自动化非常不稳定,需求一改,界面一遍,全部都费了".我相信做过的人可能也会有同感.既然这个问题一直都是存在的,那么为什么没有人仔细分析原因呢? 我的老板georgeliao举了这样一个例子:每当需求变化的时候,开发没有跳起来,反而是测试跳了起来.然后不断的抱怨,界面元素全都改了,我的自动化的用例全部都要废弃掉了.那么我们是否想过,为什么开发可以从容不破的应对产品不断变化的需求?而我们却不能呢? 业内不少人也都放弃了UI自动化,觉得接口测试才

三. 自动化测试用例设计

1.  主要内容:   2.  手工测试用例与自动化测试用例区别 目前自动化测试更多的时候是定位在冒烟测试和回归测试: 冒烟测试执行的是主体功能点的用例. 回归测试执行全部或部分的测试用例. 3.  测试类型 4.  异常 5.  WebDriver错误截图 get_screenshot_as_file()函数将截取当前页面的截图保存到指定的位置. 1 # coding = utf-8 2 from selenium import webdriver 3 4 driver = webdriver

实时显示iOS编写UI代码效果

编写iOS应用UI的方式大概有两种,一种是Storyboard/Xib,另一种是手写代码.采用Storyboard/Xib方式组织UI,由于提供可视化的特性,只要从UI库中拖动UI控件,便可以显示结果,极大地提高开发速度.但面临一个问题就是多人协作开发,由于所有的UI都放在同一个Storyboard文件中,使用Git/SVN合并代码就会出现冲突.多人协作开发还不是主要问题,有人提出可以创建多个Storyboard来分开UI编写,而Storyboard/Xib最主要问题是代码复用性比较差.所以有些

UI自动化,你值得拥有

去年春节联欢晚会,为了那张“敬业福”,全家都卯足了劲儿“咻一咻”,连节目都顾不上看了.当时我就想,要是能自动化该多好,不停点击屏幕,屏幕不疼手还疼呢,何况还不好分心,生怕错过了“敬业福”.玩“咻一咻”,是靠不停点击按钮来检查是否得到“敬业福”,而工作中的UI自动化,大抵也和“咻一咻”差不多,都是通过不断地输入,验证系统的输出是否正确.然而做UI自动化,效果并不好,收益低就算了,执行速度还慢.比如打开一个浏览器,可能就要等3-5秒,如果等浏览器访问网址,返回网页内容,就需要更长的时间.要是遇到问题

Android中实时预览UI和编写UI的各种技巧

一.啰嗦 之前有读者反馈说,你搞这个所谓的最佳实践,每篇文章最后就给了一个库,感觉不是很高大上.其实,我在写这个系列之初就有想过这个问题.我的目的是:给出最实用的库来帮助我们开发,并且尽可能地说明这个库是如何编写的,希望让初创公司的程序员少写点给后人留坑的代码(想必大家对此深有体会).我之前给出的库都是很简单基础的,基本是一看就懂(但足够精妙),如果以后的文章涉及到了复杂的库,我会专门附加一篇库的讲解文.如果一个库的原理你知道,此外这个库很容易扩展和维护,而且它还用到了很多最佳实践的经验,你为什