共计 2322 个字符,预计需要花费 6 分钟才能阅读完成。
1 定义
把以 人为驱动 的测试行为转化为 机器执行 的一种 过程。
- 简略讲:比方应用自动化测试框架、脚本、工具等主动关上测试对象(援用),主动去执行测试用例(此过程中蕴含自动化查找元素、控件等),主动输出测试数据、主动生成测试报告等一系列的自动化过程;
- 艰深讲:用机器来 模仿用户的理论行为,如键盘、鼠标等操作,来达到预期。
2 做自动化的目标是什么?
- 测试 工作量比拟大,应用自动化来实现一部分工作;
- 测试过程有 大量反复的工作,应用自动化来进行晋升效率;
- 手工测试难以 笼罩的场景,须要自动化造数据等来实现;
- 有些测试后果,可能自动化比手工更为 准确。
3 自动化测试的优缺点
长处 | 毛病 |
---|---|
反复执行、频繁操作 | 不能 100% 代替人工测试 |
模仿手动测试无奈笼罩的场景 | 不能达到 100% 覆盖率 |
利用闲暇工夫执行 | 须要工夫去剖析后果 |
开释一部分测试人员精力 | 对软件品质依赖大(前提是软件稳固、改变小等) |
测试后果主观公正 | 须要业余的工程师投入专门的工夫开发 |
/ | 投入老本可能会大一些 |
4 自动化测试的前提条件(重要)
即做自动化前先对软件进行剖析,是否满足或者要不要做自动化,有几个前提条件须要留神。
4.1 需要变动不频繁
- 脚本的稳定性最直观的决定因素是 需要的变动 ,如果需要变动大,隔三差五的进行需要更改,那脚本势必也要进行同步更新,这样投入的 保护老本就很大,得失相当,还不如不做。
4.2 我的项目周期比拟长
- 自动化测试和一般的测试一样,须要后期的布局、框架设计、脚本开发、人员抉择、脚本执行、前期保护以及后果跟踪剖析等,是一个 比拟全的且投入较多 的一个过程,如果我的项目周期很短,就不适宜做自动化,其实也没必要;
- 另外我的项目周期短,手动测试都 无奈保障 的前提下,更不必谈及做自动化了。
4.3 脚本的反复使用率高
- 咱们投入了较大的人力、物力、财力等最终实现了一套比拟完满的自动化脚本、框架或者平台,然而 复用率很低,只能在单个产品独自应用,那么这样的代价就太大了。此时咱们须要评估是否必须要进行自动化测试,如果非必须,能够不做;
- 相同的,如果自动化的一系列货色都能 迁徙到其余的产品 测试,那这样的投入是值得的,也是必要的。咱们也应该投入更多的精力进行测试开发。
4.4 团队实力
- 做自动化,不是轻易摘抄一些代码拿来用,他是一个 专项测试 ,须要投入专门的 人力去钻研及测试 ,那么咱们要想做好自动化,先要对本人的 团队进行评估 ,团队的 人员、技术能力 等是否满足要求;
- 另外,自动化须要一直的进行 迭代和优化 ,不能拿着脚本运行看看后果,那其实很多时候,并不能给产品带来 主观的价值 。咱们须要进行不定期的 降级保护 ,针对我的项目业务要进行优化,依据测试过程和后果的数据反馈要进行 稳定性的降级 等等。所以这也须要专门投入人力进行钻研。
4.5 部门的布局和下级的反对
这个是我加的,依据集体的教训的总结;
- 部门的布局:如果自动化是在部门布局中,以及有考核指标,那必定是要做的。如果不是布局,也没有纳入计划,那就要依据理论状况定,毕竟这不会间接影响你团队的理论考评。你的重点应该是在其余的中央,优先保障工作重点内容的实现;
- 下级的反对:这个很重要,做自动化无非是为了晋升效率和品质,然而如果没有失去应有的成果,领导看不到问题,也无感知,那么做自动化兴许不会短暂。这个得缓缓领会了,哈哈。
5 利用场合
自动化测试次要利用在以下场合,具体还要依据我的项目以及自动化的理论开发状况开定:
场景 | 阐明 |
---|---|
测试周期 | 我的项目周期长,轮次较多的软件 |
数据量级 | 须要制作大量的测试数据 |
软件稳定性 | 应用稳固和成熟阶段的产品测试 |
回归测试 | 须要进行简略回归的测试 |
冒烟测试 | 主线性能的冒烟 |
巡检测试 | 线上环境的定期巡检 |
公布验证 | 主线性能的公布验证测试 |
6 自动化意识误区(重点)
6.1 自动化可 100% 笼罩
- 概率不大,要使得自动化的测试覆盖率达到 100%,须要投入专门的人力、物力、财力等,老本比拟大;
- 某些业务的特殊性,或者场景的复杂性,用自动化是无奈进行笼罩的;
- 我的项目的周期限度,不容许投入更多的精力去开发;
6.2 自动化可代替人力
- 领导的口头禅:你就通知我,自动化能干掉多少人力?!==== 每次听到这样的话,不晓得你们怎么想的,反正我是很无奈。但从领导的角度来思考,也不为错;
- 这里存在一些误区,自动化测试是 辅助功能测试 的,或者说是为了解决某些人工不能笼罩的场景;
- 另外,不存在 完完全全的自动化,都是须要人工参加的;
- 遇到相似的意识,倡议自动化测试人员 须要进行解释,不能任由这个观点滋生,不然 === 你猜会咋办!!
6.3 自动化很牛逼
- 任何的事件,都是看谁先晓得而已,与其说牛逼的技术,不如说牛逼的人。
- 自动化只是一门技术,咱们不能脱离业务搞自动化;
- 很多人认为自动化很厉害,就脱离了工作的重心,天天喊着自动化、自动化,最初到头来啥也不是,啥也没失去。当然如果是业余、专门搞自动化测试开发 的那就另说了。因为他们的工作就这,就是 转、精。
6.4 万物皆可自动化
- 这个其实和前边的提到的统一,搞自动化,先要合乎一些 前提条件 以及明确他的 利用场景,不是所有软件都要搞自动化。
- 自觉的自动化,只会事与愿违。
6.4 自动化很简略
- 这是一个很简单的然而又简略的话题,对自动化的方向、工具、技能等 钻研的水平不同,对他的意识就不一样;
- 如果只是解决一些简略的问题,你把握他很简略。如果是简单的一些货色,可能须要深入研究;
- 自动化方向也是很多,不论是性能、性能,还是面向接口、UI、GUI、协定,更或是自动化工具开发等,都须要不同的技能和常识,入门或者简略,要做的很专一,还是须要点积攒的。
6.5 自动化尽早做
不肯定。不同的自动化,染指工夫可能有差别,比方
- UI 的,倡议软件略微稳固或者需要变更不频繁的时候再去开发;
- 接口的,能够在开发阶段同步进行;
7 自动化测试工具
太多了,举个例子,不代表所有的。事例而已:
正文完