51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2611|回复: 2
打印 上一主题 下一主题

[原创] 自动化测试总结(一)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2019-4-11 16:54:34 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
##自动化测试介绍
自动化测试(Automated Testing),是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架,编写自动化测试用例,来模拟手工测试过程。比如说,在项目迭代过程中,持续的回归测试是一项非常枯燥且重复的任务,并且测试人员在每天重复劳动的工作之下,也丝毫得不到成长。此时开展自动化测试就能够帮助测试人员从重复、枯燥的手工测试中解放出来,提高测试效率,缩短回归测试时间。一般来说,自动化测试通常都会跟持续集成系统(比如Jenkins)配合使用。

但在自动化实践过程中,往往会发现理想和现实之间的差距很大。自动化测试的劣势,主要体现在以下几方面:

相对手工测试,自动化测试对测试人员的要求相对较高;
测试用例需要根据版本迭代进行更新,有一定维护成本;
不能指望自动化测试去发现更多新的BUG,自动化测试能发现的缺陷远远比手工测试少;
自动化测试的产出价值往往在于长期的回归测试,短期内发挥的作用可能不明显;
##希望借助自动化流程解决的问题

测试时间紧张,手工测试可能覆盖不全,容易错过某些边界情况;
模块间强耦合时,单纯从页面进行测试时,比较难深入的发现问题;
回归测试时,需要投入较大的人力/工时;
实现手工测试无法达成的测试任务;
通过编写测试用例,加深对业务/数据的认知,有助于下阶段迭代中发现隐藏的问题;
#引入自动化测试的前提条件
项目周期长,需求变动不频繁
测试用例的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试。如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化测试脚本,但是脚本的重复使用率很低,致使其间所耗费的成本大于所创造的经济价值,自动化测试便毫无意义。

测试任务手工测试难以实现
比如压力测试,大数据或者大量重复数据测试,必须有自动化工具的支持。

##做自动化测试需要具备的能力

拥有编码能力
至少要熟悉自动化工具/框架的代码语言,最好有一定的编码能力,同时代码逻辑要清晰,否则不仅不能保证用例的逻辑性、业务性与健壮性等要素,也不能保证效率;
熟悉被测系统;
熟悉被测系统对任何测试人员来说都是最起码的要求;
掌握一个自动化测试框架/工具;
可以根据所掌握的代码,学习一门自动化测试的框架,如 Selenium/Appium/Robot Framework/UI Recorder/TestNG等;
不断学习,善于学习,知其然知其所以然;
“落后就要挨打。”
##自动化用例一般在哪个阶段完成
一般落后于新功能的手工测试阶段,可以在手工用例执行完成或功能上线后,再去补充自动化的用例。
自动化不是跟着新需求走,而是测变化的东西对不变东西的影响,一定不要做为了自动化而自动化的工作。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-4-24 16:54 , Processed in 0.065290 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表