关于自动化测试的一点思考

测试十年,有一大半时间在做手工测试。最近几年开始看一些自动化测试的东西,有多年手工测试的基础,自动化测试进展相当快,尤其是接口自动化和功能自动化。

自动化测试在我看来就是用工具或者脚本一一实现手工测试的步骤。其中最重要的不是工具或脚本,而是测试思想。手工和自动化都可以实现测试思想所转化出的用例,只是在某些情况下自动化可以提高测试的效率。

这么多年的测试工作,测试方法总结起来只有一个:一定的条件下,做一定的操作,验证得到的实际结果与预期结果是否一致。

测试设计得好不好,在于条件和操作考虑的是否完全(也就是覆盖率高不高测试经验、对业务的理解、对系统的了解程度都会影响测试覆盖率)

测试执行得好不好,在于实际结果与预期结果比对是否完全(漏测很多时候不是测试人员没有执行那条用例,而是执行了却某一点预期结果未验证,或不知道还有这个点需要验证。)

举个栗子:比如用户下单虚拟产品支付成功。除了提示支付成功,前端要验证用户账单有支付记录,订单里有订单记录且账单和订单各字段信息都正确,产品权限开通,权限正确。 后端验证支付列表、订单列表、产品权限新增记录且各字段正确。数据库要验证订单、支付信息、用户信息、用户权限的数据正确性。考虑是否涉及其他的功能和系统验证。实际上工作中大部分测试时间都花在验证实际结果与预期结果是否一致上面。

我接触的自动化测试大方向上主要包含三大块:

1 性能测试  必须自动化。

2 接口功能自动化

3 ui功能自动化

后面两块都属于功能验证,如果不用自动化也可以测。用手工还是自动化主要在于测试时间和成本效率的平衡与取舍。

实际工作中有很多测半天甚至1个小时的小迭代版本,手工测试很快就完成。要是写脚本也许脚本还没写完,上线时间点都到了。但换一个有几十个接口的项目,手工验证与自动化验证相比自动化效率更高。

项目中应用自动化有以下三种情况:

1 自动化脚本协助手工测试
2 部分功能的自动化
3 全量验证

再谈自动化的学习:

重要的一点:先知其然,而后知其所以然。

学技术先快速入门使用。实践中再继续深入学习,理解原理。 就像新人学做菜,跟着视频先买好材料配好菜(搭环境),再起油锅下原料还有调料一番煎炸炖煮出锅(实践)。味道好坏不提,总归知道如何做一道菜了。如果先学菜系理论,营养学等等,可能兴趣耗尽都还是不会做菜。

还有注意不要陷入找资料的漩涡。早期我也浪费了大量的时间找资料,搜哪个工具更好。其实没有好不好,对某一个专项测试而言,会一种工具另一种很快就能上手,一通百通。

我的学习记录:

2008-2015  外包公司外派,接触各种项目:手机测试、web测试、报表测试、接口测试、数据库迁移测试各种项目都做过,用的最多的是数据库

2016至今 fiddler  Jmeter postman  python selenium。

会的工具不多,但是每一个都在项目中有实际应用。学了一种工具,就要想办法在项目中应用起来。比如之前一直用jmeter做接口测试,学了postman之后再做接口测试就用postman,其实除了界面功能都差不多。在学习python之后,便用python+requests实现接口测试了。当会使用多种方式实现之后,你会慢慢领悟到什么样的项目适合用什么样的工具。只验证接口正确性的用jmeter和postman,如果接口数据还要做复杂的处理再验证的更适合python。

工具不用学多深,我经常说excel我们用的功能只有它全部功能的很小一部分吧。这些自动化测试工具都是,不用学得多精多全才去用。会一点用一点,下次有项目再用一点,越用越深入。

the end!

原文地址:https://www.cnblogs.com/dinghanhua/p/10013714.html

时间: 2024-10-09 23:38:54

关于自动化测试的一点思考的相关文章

"简单设计"的一点思考

简单设计是Xp技术实践中开发实践的核心实践,“简单也是价值观中智力色彩最强烈的”,然而,提到简单设计,大家更觉得像原则或者价值观,感觉上还是比较泛,我们不妨从下面的几个角度看一下  1. 为什么要简单设计 <1>. 简单的代码更容易读懂. <2>. 好的设计更能应对变化.  这两点是基于成本和收益考虑的,这里的价值是时间及金钱.更快的满足需求,减少复杂带来的故障排查.修复成本,代码大量修改或者重写成本.  2. 什么是简单设计 对一个团队来讲,简单设计就是团队中每个人都能轻松的读懂

关于后台系统自动生成的一点思考

大量实践发现后台管理程序,其实90%的代码都是相同的,当然是在抛弃复杂逻辑业务的情况下,那么如何能高效的节约这些时间呢,那就是接下来我要说的,对于后台系统自动生成的一些思考. 适用情景: 1.表编号id为自增(基于现在大部分表编号都是自增的情况): 2.没有太复杂业务关联关系,比如表的某一个字段,存储了一个json对象,为了平衡后台用户使用,需要友好的分段展示给用户的定制ui界面:还比如表中存储了外键的多个id,但为了方便用户使用,只能已标签name的方式,给用户展示,等等这些超强业务黏合逻辑的

关于前端的一点思考

关于前端的一点思考 Author:tkorays 最近写前端代码,写着写着就突然开始惆怅.忧伤.愤怒.发狂,我TMD到底在干什么啊! 很多东西写了n遍了,但是还是在不停地写着.自己写过的代码也不想再修改完善.重新利用,只是觉得,可能重新写一遍可能要好点.面对这很多库以及框架,虽然喜爱,但是也是有所顾忌,我只要使用其中的一个功能,根本不需要引入这么大的整个库. 事实上,我们可能在动手写任何代码之前,先要思考下,我们到底要的是什么! 0x00 界面真的需要这么炫酷么 在使用某个界面库之前,我们可能先

关于Emit中动态类型TypeBuilder创建类标记的一点思考

  利用TypeBuilder是可以动态创建一个类型,现在有个需求,动态生成一个dll,创建类型EmployeeEx,需要继承原dll里面的Employee类,并包含Employee类上的所有类标记.   网上有很多例子, //创建TypeBuilder. TypeBuilder myTypeBuilder = myModBuilder.DefineType(typeName, TypeAttributes.Public); myTypeBuilder.SetParent(type);   大概

关于如何做自动化测试和何时做自动化测试的一点见解和疑问

中华传统文化源于<易>,成于孝,孝为德之本.孝顺:孝则顺,不孝则不顺. 不久前,参加Thoughtworks组织的一场自动化测试的分享,同事由于出差国外不能参加,特意嘱托我提问两个问题: 在互联网这个将"敏捷"与"持续集成"进行积极实践的环境里,"敏捷测试"与"自动化测试"成了一个大家经常探讨的话题, 那么自动化测试最佳的实行时间是在什么时候?如何推行最有效的自动化测试? 以下谨代表个人观点: 个人整理了一些测试最

关于失败的一点思考

睡觉之前突然想到马云说过的一句话:我们要习惯于拒绝,习惯失败,如果我们还没成功,那是因为我们的失败还不够 --------2016.4,11  以此自勉 关于失败的一点思考

有关盒模型的一点思考

有关盒模型的一点思考 盒子模型是css中一个重要的概念,理解了盒子模型才能更好的排版. 其实盒子模型有两种,分别是标准 w3c 盒子模型和 IE 盒子模型. 他们对盒子模型的解释各不相同,先来看看我们熟知的标准盒子模型: 一.w3c盒子模型 看下面的图,根据色块,右外倒内,分别代表margin.border.padding.content(即网页内容部分) 二.IE盒子模型 与w3c盒子模型的组成部分类似,IE盒子模型也包括上图几个部分 但是不同的是,IE盒子模型把border和padding归

关于模板方法和策略模式的一点思考

该随笔的思想原点,应该算是在两三年前了.当时和一前同事聊天.不知怎得就聊到了Http访问. 一.我记得他和我说过的第一句话,大概是:有没有已经封装好的.比较强大的HttpUtil.也可能是受业务的影响(接口对内).我当时接触到的Http访问,大多比较“规范”,至少有一个接口约束在约定着某些东西,不至于一会传递json,返回json, 一会又要传递xml,返回xml,甚至更奇葩的是,上传个文件.返回0或者1.如果真出现这样的状态,HttpUtil依然能够方便.灵活的适应着各种情况.我想这个Util

关于android SDK安装Failed to fetch URL 一点思考

最近SDK出问题了,然后在google下载了一个android-sdk-windows.rar,然后点击SDK Manager,结果一直不能刷新API Level,然后就开始在网上找了好多资料,解决这个问题,修改 HOSTS,    HTTP  和  HTTPS  都不能解决,这给我带来了很大的困惑!   加载不出来的界面错误为: Fetching http://dl-ssl.google.com/android/repository/addons_list-1.xml Failed to fe