自动化测试

敏捷自动化测试(3)——让断言不再成为自动化测试的负担

流过昼夜 提交于 2019-11-27 07:12:06
作者: 殷坤 来源: InfoQ   在本系列的第一篇文章“我们的测试为什么不够敏捷”中,根据实例总结出敏捷自动化测试的两大阻碍:“脚本维护困难”、“断言条件繁琐”。本文针对在不失自动化测试有效性的前提下如何降低断言成本来分享一些实践经验。   目前业界常见的自动化测试工具在断言方面大多都是采用“指哪儿打哪儿”的细粒度模式,即,在自动化测试过程中只能对设置为断言条件的字段(页面元素)进行断言。而且这些测试工具即使提供录制脚本的功能,但对于断言往往还需要测试人员手工补充插入。   除了补充、维护断言条件的工作量大之外,这种断言模式还存在一些明显的不足,下面结合一个实际的例子(如下图)进行分析: 无法感知未设为断言对象的字段上发生的错误 以上图为例,如果在“增加用户”的测试脚本之后只对列表中的“用户姓名是否存在” 进行断言,那么就可能遗漏“入职日期没有提交成功”的错误。而且由于页面的信息量往往很大,我们是不可能对所有字段都设置为断言条件的。 难以对于UI样式或UI逻辑进行断言 以上图为例,有一个UI样式类的缺陷(左侧菜单树的根节点“console”下面多出来一条虚 线)和一个UI逻辑类的缺陷(右侧用户列表只有一页,但“下一页”和“最后一页”图标依然是可以点击的,即没有灰显)。此类缺陷即使对于经验丰富、心思缜 密的测试人员,在人工测试时也是很可能发现不了的

自动化测试用例编写守则

空扰寡人 提交于 2019-11-27 07:11:57
手工测试用例 PK 自动化测试用例 首先,需要区分手工测试和自动化测试用例的不同。 1.手工测试用例: 关注某个功能点 可考虑多种异常情况并做出相应的处理,通过人为的逻辑判断当前步骤的功能实现正确与否 人工执行具有一定的步骤跳跃性 人工测试步步跟踪,能够细致的定位问题 主要用来发现功能缺陷,适用于测试阶段 2.自动化测试用例: 关注的是流程,多个功能点 用例步骤关联性强 保证产品主题功能能正确完成和让测试人员从繁琐重复的工作中解脱出来 自动化测试的每个用例的起始页面和退出页面一般是同一个页面,从哪里开始,到哪里结束(为了保证每次测试的初试环境是一样的) 目前自动化测试主要用于冒烟测试和回归测试(冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例) 自动化测试用例设计原则: 不需要将所有的手工测试用例转化为自动化测试用例 选择功能较为稳定的功能模块进行测试。当功能变动大时,脚本的维护需要花费更多的精力 选择的用例如为主体流程,可用于冒烟测试 自动化测试也可以用来做配置检查,数据库检查等。也算用例拓展的一部分。 如果平时在手工测试时,需要构造一些复杂数据,或重复一些简单机械式动作,就可以使用自动化脚本创造 准备复杂的测试数据。对于大的应用系统,数据之间的关系和准备过程都会很复杂,甚至有其他外部系统导入、传输或计算出来的数据

软件测试-测试分类

非 Y 不嫁゛ 提交于 2019-11-27 00:45:59
软件测试-测试分类 一、按软件测试阶段: a. 单元测试 b. 集成测试 c. 系统测试 d. 验收测试 1、单元测试 单元测试的原则: 1、尽可能保证部没测测试用例相互独立 2、一般由代码的编写人员来实施 单元测试的优点: 1、能尽早发现缺陷 2、有利于重构 3、可以简化集成 单元测试的缺陷 1、不可能穷尽测试,即测试用例不可能覆盖所有的执行路径,不可能捕捉到所有的错误 2、每一行代码需要3-5行测试代码来完成测试 单元测试框架 xUnit,比如:JUnit 例:eclipse->new->Java project->(finish)->右键项目->properties->Java Build Path->Add library->选择JUnit->next->选择Junit版本->finish 选中需要测试的类,在上右键->new->junit test case(勾选setUp()和tearDown() )->next( 选择需要测试类中待测试的方法 ) -> finish() 2、集成测试 在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块,子系统或者系统的过程中各部分工作是否达到或者实现相应3技术指标及要求的活动。 集成测试实施方案 1、BIg Bang(一次性集成/大爆炸):把大部分开发模块耦合起来,形成一个完整的软件系统

如何选择正确的自动化测试工具

久未见 提交于 2019-11-26 19:25:40
自动化测试正在逐步取代部分手动测试,因为它可以节省时间并提高测试质量。特别是在进行回归测试的情况下,自动化可以通过多种方式提高效率。手动进行重复测试是浪费时间和资源。此外,由于重复测试可能会遗漏,因此存在一定的错误范围,但是自动化中发生错误的可能性很小。但是什么是自动化测试?简单来说,自动化测试就是通过重复执行预定义的动作来执行测试用例的系统来代替人工操作。为了充分利用自动化,必须选择正确的自动化测试工具。 自动化测试工具的类型 记录和重放:此类别中的工具为自动脚本提供了记录选项。屏幕上的每个交互(例如点击,滚动或键入)都将被记录并转换为自动化步骤。可以重播已录制的脚本以执行操作并验证。 基于坐标的识别:此类工具在x/y坐标的帮助下与被测应用程序交互,以自动化和验证应用程序。 本机对象识别:使用本机对象识别的工具可检测给定元素树上的UI或控件元素。该树由XPATH,XML或CSS构建,以标识元素,验证和自动化脚本。 文字识别:文本识别:文本识别或(OCR)光学字符识别工具可根据其文本识别元素。这些工具使用可见文本来推动自动化并验证应用程序。 图像识别:这些工具会获取产品中UI元素的屏幕截图,以将其添加到自动化脚本中。这些屏幕截图将帮助AUT自动执行。 许多测试自动化工具支持多种识别方法,这对于获取更强大的自动化脚本很有用。现在让我们看看选择自动化测试工具时要考虑的因素。 平台支持

【python】如何使用全功能的Python测试框架(小白白必看系列)

拥有回忆 提交于 2019-11-26 17:20:50
如何使用pytest 大纲 安装和简单使用 配置文件 笔记来自: http://stu.ityxb.com/index.html#/ansandqus 断言 一. 第一步 —— 安装和简单使用 pytest是一个非常成熟的全功能的Python测试框架,主要特点有以下几点: • 1、简单灵活,容易上手,文档丰富; • 2、支持参数化,可以细粒度地控制要测试的测试用例; • 3、能够支持简单的单元测试和复杂的功能测试,还可以用来做selenium/appnium等自动化测试、接口自动化测试(pytest+requests); • 4、pytest具有很多第三方插件,并且可以自定义扩展,比较好用的如pytest-selenium(集成selenium)、pytest-html(完美html测试报告生成)、pytest-rerunfailures(失败case重复执行)、pytest-xdist(多CPU分发)等; • 5、测试用例的skip和xfail处理; • 6、可以很好的和CI工具结合,例如jenkins 安装 pip3 install pytest 简单使用 新建一个test_sample.py文件,输入以下代码: def inc(x): return x + 1 def test_answer(): assert inc(3) == 5 在test_sample

自动化测试,性能测试

谁说我不能喝 提交于 2019-11-26 14:47:14
负载测试就是 系统在超负荷的情况下进行一定量的数据测试 是否能够运行 压力测试是系统在资源特别低的情况下 对系统进行长时间的运行 超出系统的瓶颈 手工测试是传统的测试方法,由测试人员手工编写测试用例,缺点在于测试工作量大,重复多,回归测试难以实现;自动化测试利用软件测试工具自动实现全部或者部分测试工作:管理、设计、执行和报告,自动化测试节省大量的测试开销,并能够完成一些手工测试无法实现的测试。 自动化测试是对手工测试的一种补充,自动化测试不可能完全替代手工测试,因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试的话,则会让测试过于低效,尤其是回归测试的重复工作量对测试人员造成了巨大的压力。30%为佳 测一个WEB程序,你可以通过一个数据来控制每次是在哪个页面下工作的(即通过数据来导航到相应的页面)。它是关键字驱动的低级版本,他控制的是函数级的,而关键字是控制动作级的 来源: https://www.cnblogs.com/huaihe/p/11324501.html

自动化测试综述

生来就可爱ヽ(ⅴ<●) 提交于 2019-11-26 14:03:30
概念:让程序代替人工去验证程序功能的过程 作用: 回归测试 -------- 开发新版本对所有功能再次测试 压力测试 -------- 模拟多用户并发操作, 兼容性测试 -------- 浏览器兼容性测试 提高测试效率,保证产品质量 优点: 较少时间运行更多测试用例 自动化脚本可以重复运行 减少人为错误 便于测试数据存储 分类: Web自动化测试 接口自动化测试 移动(app)自动化测试 单元测试自动化 什么样的项目需要自动化测试: 需求不怎么变动 项目周期要长 项目有回归测试的需求 自动化测试工具: Web自动化:selenium、robot framework App端自动化: Appium、Monkeyrunner PC端:QTP 接口:Jmeter、Postman 性能:Jmeter、LoadRunner 注意: 自动化测试在功能测试(手工测试)完毕之后进行 web自动化测试属于功能测试,黑盒测试,只是手段的不同 不能取代手功测试,手工测试能发现更多的缺陷 来源: https://blog.csdn.net/qq_42819407/article/details/98882702

12_Python3.6+selenium2.53.6自动化测试_通过xpath定位百度输入框

假如想象 提交于 2019-11-26 02:53:59
一、实现功能 1、通过xpath定位百度输入框 2、输入关键字“Python3.6+selenium2.53.6自动化测试”点击查询 二、实现代码 #coding:utf-8 from selenium import webdriver import time ''' 1、通过xpath定位百度输入框 2、输入关键字“Python3.6+selenium2.53.6自动化测试”点击查询 ''' #启动本机的火狐浏览器 dr = webdriver.Firefox() dr.get("https://www.baidu.com") #等待网页加载4秒钟 time.sleep(4) #通过xpath定位到输入框,并清空输入框 dr.find_element_by_xpath(".//*[@id='kw']").clear() time.sleep(2) #输入内容:Python3.6+selenium2.53.6自动化测试 dr.find_element_by_xpath(".//*[@id='kw']").send_keys("Python3.6+selenium2.53.6自动化测试") #让程序等待2秒钟再执行 time.sleep(2) #点击百度一下按钮 dr.find_element_by_xpath(".//*[@id='su']").click() #退出浏览器 dr

提升自动化效率,一起玩转Selenium框架

别来无恙 提交于 2019-11-25 23:00:52
以往项目组的聊天 测试工程师:已经把新的模块测试完毕了,bug提交到bug库(jira、TFS、禅道)中了。请根据bug描述修改bug,然后我在回归。 开发工程师:好的。 测试工程师:你写的这个模块bug好多哦...,而且前面修复过的bug,有出现了 开发工程师:一会再修改,你先测别的,我开发完这些功能再说。 开发工程师【内心】:测试不就是点点吗,一天天的好烦,有本事你来写程序,看看会不会比我强,代码都不会,还一天天的催。【ps:以上内心独白存在杜撰哦!】 现在项目组的独白 测试工程师:【内部通讯聊天群】测试报告发到邮箱了,请及时查收,修复bug 开发工程师:速度打开邮箱查看自动化测试报告,确认是否有指向自己的bug。一篇内心忐忑,如果测试报告里又有自己的缺陷,那太low了哦,万一老大发现了,轻则批评,重责可能扣奖金哦。 测试工程师【内心】:现在真爽,每天的BVT与回归测试,再也不用手工了。 - - 每天定时跑用例; - - 自动发送测试报告给项目成员; - - 大大减轻了工作压力,在也不用跟开发因为bug的反复频繁沟通了 - - 更加专注于测试新功能及维护自动化测试脚本 现在测试团队都需要什么? 现在测试工程师都在聊什么? python学了吗最近? selenium自动化你们团队搞的怎么样? 你们自动化框架应用的如何? 一直搞手工职业发展回有瓶颈啊。测试真心要往测试开发走啊