自动化测试

自动化测试是,把人对软件的测试行为转化为由机器执行测试行为的一种实践。

自动化测试的本质是先写一段代码,然后去测试另一段代码,所以实现自动化测试用例本身属于开发工作,需要投入大量的时间和精力,并且已经开发完成的用例还必须随着被测对象的改变而不断更新,你还需要为此付出维护测试用例的成本。

自动化测试的优势

  1. 自动化测试可以替代大量的手工机械重复性操作,测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上;
  2. 自动化测试可以大幅提升回归测试的效率,非常适合敏捷开发过程;
  3. 自动化测试可以更好地利用无人值守时间,去更频繁地执行测试,特别适合现在非工作时间执行测试,工作时间分析失败用例的工作模式;
  4. 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型,比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等;
  5. 自动化测试还可以保证每次测试执行的操作以及验证的一致性可重复性,避免人为的遗漏或疏忽。

适合做自动化测试的项目

  • 需求稳定,不会频繁变更。
  • 研发和维护周期长,需要频繁执行回归测试。
  • 需要在多种平台上重复运行相同测试的场景。
  • 某些测试项目通过手工测试无法实现,或者手工成本太高。
  • 被测软件的开发较为规范,能够保证系统的可测试性。
  • 测试人员已经具备一定的编程能力。

自动化测试的范畴

自动化测试包括但不限于

  • 测试环境的搭建和管理
  • 测试环境的检查,监控和报警
  • 测试代码的编译和测试构建
  • 测试代码的静态检查和报警
  • 测试用例的分发和执行
  • 测试结果的保存与管理
  • 测试报告的生成
  • 测试优先级的建议

自动化测试的目标

错误的预期 1.不清楚自动化测试的目标,以及为达到目标所计划的投入 2.对自动化测试抱有不切实际的幻想型期望,认为自动化测试能够干很多活同时省很多钱

自动化测试的第一目标从来都不是节省测试的人力成本。

成功的自动化测试,作为软件测试的一种工具,从业务「最终效果」来看,应该是能够「节省成本」「提高产品质量」的。

大部分的测试,所要做的是不是保证系统没有bug,而是保证在单位时间内测出大部分「不影响客户使用」,并「不被普通客户发现的bug」

自动化测试不直接找bug,而是通过解放有经验的测试工程师的生产力,让其从重复的回归测试中解放出来,从事新的测试方法和测试手段的研究。

通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新bug,将产品质量再提高一个档次。

错误的观念 1.自动化应该是一种Service(Automation As A Service),所有的测试人员和开发人员都应该可以自己很方便的去跑自动化 2.自动化测试的运行结果应该是可以自动分析的,占用很少的时间 3.自动化测试的成功率应该是要很高的(比如95%以上) 4.自动化应该是写一次,运行很多次,为什么花那么多时间还要去改自动化代码

自动化的成本与收益

自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

为什么要做自动化测试

需要先分析一下「手工测试」和「自动化测试」各自的特点:

  • 手工测试,测试点广深度,需要准备时间少,效果卓越,后续工业化弱

运用场景项目初期测试冒烟,系统测试,验收测试

  • 自动化测试,测试点深度,需要准备时间长,效果相对一般,工业化高 兼容性测试,接口测试,单元测试,线上监控测试,性能测试,稳定性测试,回归测试

当前的自动化实践

从自动化测试的范畴来看一下我们当前的自动化测试状态

  • 测试环境的搭建和管理 问题:执行环境(JDK,python,git,allure)需要手工搭建。
  • 替换代码中win独有的相关库,使其可以在全平台上运行,方便使用Docker技术
  • 测试环境的检查,监控和报警 问题:IPC设备信息 存放在代码data中,但是没有统一的管理与状态监控。
  • 搭建「设备运维管理平台」统一管理设备状态,信息
  • 测试代码的编译和测试构建 python代码不需要编译,使用CI/CD的方案(Jenkins)来进行测试的构建
  • 测试代码的静态检查和报警 搭建Gitlab代码管理平台,使用Gitlab-runner的CI进行代码静态检查
  • 测试用例的分发和执行 使用Jenkins参数化构建选择执行设备,集成JSON Editor进行执行用例选择。
  • 测试结果的保存与管理 使用Jenkins流水线中的文件打包进行结果保存,直接在Jenkins上查看对应执行的报告
  • 测试报告的生成 使用Allure进行报告的展示
  • 测试优先级的建议 问题:暂无
  • 根据某策略自动选择某设备需要执行的用例

本文分享自微信公众号 - 测试游记(zx94_11)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-04-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏老九学堂

当程序猿接手一个新项目的时候,惨!绝!人!寰!

16520
来自专栏软测小生

一款前端性能分析工具—WebPageTest

网站是开源的,支持开发者下载源文件搭建私人的内部测试站点。开源地址:https://github.com/WPO-Foundation/webpaget...

14150
来自专栏软测小生

黑盒测试以及测试用例设计

等价类划分法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例;该方法是一种重要的,常用的黑盒测试用例...

21230
来自专栏软测小生

软件测试用例设计(史上最全软件测试干货)

今天来发一篇软件测试用例设计时需要关注的点,前辈总结的非常详细,基本上素有的测试点都包含在其中了,纯纯的图片。 快下载保存本图吧,遇到写测试用例的时候可以参考一...

21140
来自专栏软测小生

谈一谈软件质量模型

事情起源于一个风和日丽春暖花开阳光明媚的上午,小编的老板突然提问,YY, 马上要上线的XX功能你测试的怎么样?这个功能实现的质量怎么样?

52240
来自专栏软测小生

测试框架TestNG使用介绍

在本期中,给大家分享一下TestNG测试框架的基础知识,使用TestNG的优点,TestNG的基本注解如何使用,套件、忽略、异常、依赖、参数化、超时等测试该如何...

24640
来自专栏云计算D1net

掌握多云取决于兼容文化

如今,云计算使用率正在上升。很多组织正在增加云计算支出、云计算的应用程序范围,甚至与他们合作的云计算供应商的数量。

11030
来自专栏软测小生

软件测试的7个基本原则

软件测试的原则是指帮助测试团队有效地利用他们的时间和精力来发现测试项目的隐藏bug的指导方针。从实际的实践和研究中,研究了以下 7 条软件测试的基本原则,以便测...

26740
来自专栏软测小生

[测试十年]思维模式(二):鱼骨图分析法

大熊:最近我们的测试中出现了几个问题发现晚的问题,比如在输入法的打字速度相比以前有明显卡顿,这个问题在临上线前才发现。这个问题大家怎么看?

12050
来自专栏软测小生

API测试工具Top 10 你都用过吗?

API测试(应用程序编程接口测试)是一种软件测试类型,它着重于确定所开发的API是否满足关于应用程序的功能、可靠性、性能和安全性的预期。

26250

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励