测试----自动化测试(二)

1.什么是自动化测试

1. 1自动化测试:
  • 自动化测试是一种使用自动化工具编写和执行测试人员测试脚本和案例的技术。
  • 自动化测试的主要目标是减少手动运行的测试用例数量,而不是完全取消手动测试
  • 帮助测试人员从重复、枯燥的手工测试中解放出来,增加测试的广度和深度,从而提高测试的质量;缩短回归测试时间,提高测试效率,从而缩短项目的交付周期。
1.2 自动化测试和手工测试的区别:
1.2.1 手工测试:

(1)较好的异常处理能力,能通过人为的逻辑判断校验当前步骤是否正确实现;
(2)人工执行用例具有一定步骤跳跃性;
(3)人工测试步步跟踪,能够细致定位问题;
(4)主要用来发现功能缺陷;
手工测试的缺点
(1)手动软件测试需要更多时间和更多资源。
(2) 不准确
(3)反复执行相同的测试用例容易出错并且很无聊。
(4)在非常大的项目和有时限的项目上进行手动测试是不切实际的。

1.2.2 自动化测试:

(1)执行对象是脚本,任何一个盘算都需要编码定义;
(2)用例步骤之间关联性强;
(3)主要用来保证产品主体功能正确和完整,让测试人员从繁琐重复的工作中解脱出来;
(4)目前自动化测试阶段定位在冒烟测试和回归测试。

自动化测试的优点:
降低大型系统的由于变更或者多期开发引起的大量的回归测试的人力投入,这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的,自动化测试前期人力投入较多,但后期进入维护期后,可节省大量人力,而手工测试后期需要增加大量人力用于回归测试
(1)减少重复测试的时间,实现快速回归测试
(2)可靠的测试过程,减少人为错误
(3)可以运行更多更繁琐的测试
(4)可以执行一些手工测试困难或不可能进行的测试
(5)更好的利用资源
(6)测试具有一致性和重复性:测试脚本的重用性
注意:自动化测试不能完全替代手工测试,自动化测试的目的仅仅在于让测试人员从繁琐重复的测试流程中解脱出来,把更多的时间和精力放在更有价值的测试中,例如探索性测试。
自动化测试的缺点:
(1)自动化测试并不能取代手工测试,它只能对针对执行频率高、机械化的重复步骤;
(2)自动化测试远没有手工测试可靠,它的用例很脆弱,维护成本很高;
(3)自动化测试用例开发工作远远高于手工测试,短期内难产生效益,产出的价值往往在于长期的回归测试。
(4)自动化测试它不能发现很多新bug,它发现的缺陷远远比手工测试少;
(5)自动化对测试脚本开发对测试人员要求比较高,测试脚本执行的效率很大的程度上依赖于脚本的质量,而不稳定的自动化测试脚本还不如没有自动化。、

1.3自动化测试对象和测试用例

1.3.1测试对象

测试对象:UI、接口、代码
测试过程:系统测试、集成测试、单元测试
执行人员:测试人员、开发人员
注意

  • 自动化测试可以在整个测试过程中任何一个阶段实施,前提功能相对稳定
  • 测试人员一般在系统测试时进行自动化测试
  • 集成测试阶段多进行自动构建、部署,以及冒烟测试的自动化
  • 单元测试针对代码级别进行测试,可进行静态代码检查,或者执行单元测试用例,典型的框架比如junit,该部分多由开发人员实施
    UI自动化
  • 用例维护量大
  • 页面相关性强,必须后期介入
  • UI测试适合与界面变动较小的项目
    接口自动化
  • 可在产品前期介入
  • 用例维护量小
  • 页面相关性小
  • 适合接口变动较小,界面变动频繁的项目
1.3.2自动化测试用例的设计

1)自动化用例设计要保证测试对象的明确性;
2)每个用例都是一个完整的场景
3)每个功能点一个测试用例;
4)尽量降低用例的复杂度,每个脚本独立,脚本之间不要产生关联性。
5)在写用例过程中需要将共性功能或操作抽象出来模块化,提高测试脚本的可维护性与代码的重用性。

1.4 常见的自动化测试工具:
  • QTP(功能测试):Quick Test Professional主要应用软件环境的功能测试和回归测试的自动化。采用关键字驱动的理念以简化测试用例的创建和维护。它让用户可以直接录制屏幕上的操作流程,自动生成功能测试或者回归测试用例
  • selenium(功能测试工具):用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。
  • Rational Robot(功能测试) :进行自动的功能性回归测试
  • jmeter(压力测试工具):可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
  • appium(app测试工具):一款开源测试自动化框架,可用于原生、混合和移动Web应用程序。它使用WebDriver协议驱动iOS,Android和Windows应用程序。重要的是,Appium是“跨平台”的:它允许您使用相同的API针对多个平台(iOS,Android,Windows)编写测试。
  • soapui(接口测试工具):soapUI是一个开源测试工具,通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试
  • Loadrunner(性能测试):通过模拟虚拟用户来判断系统的性能

2.自动化测试应该怎么去做?

2.1自动化测试的对象
2.1.1适合自动化测试的对象:

实施自动化测试的前提条件:需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用。

(1)重复性任务
(2)冒烟测试
(3)机械并频繁的测试:每次需要输入相同、大量的一些数据,并且在一个项目中运行的周期比较长
(4)敏捷开发,频繁的版本迭代 :新版本是在旧版本的基础上进行改进,功能变不大的项目,但项目的新老功能都必须重复的进行回归测试。回归测试是自动化测试的强项,它能够很好的验证你是否引入了新的缺陷,老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具
(5)手工测试无法完成的测试:接口测试、性能测试、配置测试、大量数据输入测试,这些就是需要投入大量时间与人力也可以引入自动化测试。

2.1.2 不适合自动化测试的对象:

(1)需求变动频繁的项目,自动化脚本不能重复使用,维护成本太大,性价比低
(2)一次测试案例:项目周期短,自动化脚本编制完成后使用次数不多,性价比低
(3)交互型较强的项目,需要人工干预的项目,自动化无法实施
(4)临时 - 随机测试
(5)易用性测试,美观,声音等人的感观方面测试。

2.2自动化测试流程:
  1. 分析:总体把握系统逻辑,分析出系统的核心体系架构。做个测试计划,明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求,并确保测试所需的人力、硬件、数据等资源都准备充分
  2. 设计:根据测试计划和需求说明书,分析测试需求,设计测试需求树,以便用例设计时测试用例要足够明确和清晰,覆盖面广而精能够覆盖所有的需求点。(链接,控件,功能,数据,业务逻辑)
  3. 实现:搭建测试环境,编写脚本,有两个要求一是断言,二是合理的运用参数化。
  • 设计测试框架:要尽可能的将这些模块功能有机的结合起来,要能将脚本有效的组织和连贯应用,提高测试脚本的可维护性和可读性。测试框架还要做到高内聚低耦合。高内聚,每个模块尽可能独立完成自己的功能,不依赖于模块外部的代码;低耦合,模块与模块之间接口的尽量简单。
  • 测试用例:不要在没设计自动化测试用例之前就进行编码,自动化测试用例他是对自动化测试场景的整理与综合。
  1. 执行:定时执行、自动触发、手工触发
  • 定时执行:多用于监控代码版本的质量。如,每天早晚二次固定时间执行精选的中高级用例,实时监控版本质量。
  • 自动触发:多用于冒烟测试。如,精选出冒烟用例(执行时间控制在10分钟内),在开发提交代码合并到主分支时自动触发冒烟测试,有问题邮件通知对应人员。
  • 手工触发:多用回归测试。如,一周或一个sprint为周期触发两次左右的全量执行,要结合实际情况手动触发
  1. 总结:测试结果的分析,和测试过程的总结是自动化测试的关键。自动化测试结果分析主要靠测试报告,测试报告要求通俗易懂,不能过于复杂
  2. 维护系统发生变更时需要及时更新自动化测试用例和修改测试脚本用例与需求挂钩,测试脚本与用例挂钩,必须先更新测试用例,然后才能修改测试脚本,用例和脚本的每次更新需留下维护的记录,以便 review 和 问题查找。
  3. 分析:在自动化测试过程中深刻的分析自动化用例的覆盖风险和脚本维护的成本。
    总结:选择测试工具->定义自动化范围->规划,设计和开发测试环境,测试脚本和测试框架->测试执行->维护
    在这里插入图片描述
    https://zhuanlan.zhihu.com/p/60519940

3.注意事项和细节都有哪些?

1)不是所有手工测试用例都要转为自动化测试用例。
2)考虑到脚本开发成本,不要选择流程太复杂的用例,如果有必要,可以考虑把流程拆分成多个用例来实现脚本。
3)选择的用例最好可以构建场景。例如,一个功能模块,分成多个用例,多个用例使用同一个场景,这样的好处在于方便构建关键字测试模型。
4)选择用例可以带有目的性。例如,这部分用例作冒烟测试等,当然,会存在重叠关系,如果当前用例不满足需求,那么唯有修改用例来适应脚本和需求。
5)选取的用例可以是主体流程,这部分用于冒烟测试。
6)选取的测试用例可以是你认为重复执行,很猥琐的部分。例如字段验证、提示信息验证之类,这部分适用于回归测试。
7)自动化测试也可以用来做配置检查、数据库检查。这些可能超过了手工用例,但也算用例拓展的一部分,项目负责人可以有选择的增加。
8)平时在手工测试时,如果需要构造一些复杂的数据或重复一些简单的机械式动作,则告诉脚本,让它来帮你,或许你的效率会因此提高。

https://zhuanlan.zhihu.com/p/47436296utm_source=qq&utm_medium=social&utm_oi=757986372186312704

烟雾测试和理智测试:https://www.kingwins.com.cn/content-11743.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值