软件测试之路再谈(三年测试风雨)

碧水涟涟,夏至未至,秋风依依,梅花落时,已是一生

一初衷:

为什么写这篇博客?

  个人性别偏于低调,最近换了新工作,坐标成都,就任于一家T系公司。

1、公司是以项目为单位,有测试团队但没有测试部这个概念,测试团队人数大概60人左右,但都基本跟你没任何关系,只有项目上的其他两个成员跟你有交集,缺少后方养分,差异性,一时间不太适应,

2、业务划分很精细,能接触到的东西十分有限,还有各模块之间弱化了连接测试,担忧。已经发现过问题,而且也和组员讨论过他们也赞同这种方式容易出现质量弱化

基于以上有些迷茫吧。今日加班值班,做个小小的往期回顾和总结。写日志和大家聊聊是顺便,主要想是借此七夕祝愿大家有人爱的甜蜜长久,没人爱的各自欢喜,要表白的马到功成

距离上一篇17年2月《软件测试之路浅谈》,传送门https://www.cnblogs.com/-lisunman/p/6366045.html

刚刚好两年半了~~~~~~~~~~~~~~~~~~~~~~~~~~

当时入行软件测试半年后,是一种即有点期待(有些兴趣)更多是迷惑(当时所在测试部门不追求技术,功能测试为主)的状态写下来的记录,碎碎叨叨,想不忘初心。

文采拙略,叙事体再做一篇回归。

二回顾:

薪资

阶段一:J公司

?K(2016年上半年-2018年上半年)

阶段二:X公司

?K+3K(2018年上半年-2019年7月)

阶段三:K公司

?K+4.3K(2019年7月-今)

备注:有些线索可以猜到博主所在公司,一个是为了职业素养,二来避免不必要的麻烦,博主只展示一下待遇的提升,主要还是聊聊测试之路,三年测试风雨。

经历:

J公司:16年毕业于一家极其普通的本科院校,年少轻狂,学术不精,毕业时虽有公司愿意我前往,但我简历写的是测试,入职后是干的开发的活,终日闹累,加班严重,对于测试的一些兴趣和自己的思维方式(HP以前在学校做过测试讲座,出了一道拓展题目,桌子上有一杯水,怎样使水不在杯中,大家穷举例,物理、化学、电解等等方法,最后我举手回答,把杯子的外部注满水,这样就是杯在水中,不在是水在杯中了),我觉得自己适合做测试一些,2个月后辞职找了一家普通的公司做测试,测试团队大概15人左右,妹子较多,业务复杂,只要求功能测试,自己在项目期间看了很多基于测试的书籍,理论的,比如《微软测试之道》、《google软件测试之道》、《探索性测试》、《测试的艺术》等等,自学了Python、Selenium。并应用到项目中,个人应用过来,在团队推广过自动化测试,但是,妹子们表示,那都是花架子,没得意思。没有共鸣,这也是我为何辞职的原因。

状态:影响力较小,和开发关系很普通,脚本能力一般,但有一定的涉及和基础。

X公司:18年初,进入了X公司,当时团队正在扩建,是很明显的重QA类型,开发水平参差不起,后来招的的人要求高,前期的较为一般,我当时负责App的测试,版本迭代较多,后做为这个项目的测试负责人,前期,我总结和查询了大量App的测试方法,并应用于测试,发现了不少崩溃,闪退,和ANR问题,作为测试负责人后,第二是公司的要求CI,Jenkins自动打包模块的建立和App自动化主导形成一个闭环的质量链,成长了不少,接触到了接口测试,并运用脚本实现了接口自动化,紧接着,性能测试也做起来了。测试团队大概30人左右,后成立了技术专家委员会,有幸成为其中一员,成员大概7人左右,里面基本都是大佬,我实属菜鸡,但我年限最低3年,他们基本都是5年以上。最大的12年测试经营。技术专家委员会会有双周会,讨论公司的质量把控和提升,流程的优化,新工具的尝试和总结,工具脚本的开发,会有一些难度系数的任务,并为整个测试部服务,这些需要在工作之余完成。

具体聊一下我负责App的测试:

UI自动化(Android)基于appium+robot framework,PO模式业务逻辑数据分离,自动启动环境,关闭环境,执行失败时,自动抓取日志文档并分析,如果日志出现敏感字段,比如空指针什么的,根据提单规则,自动提交bug到JIRA,截取图片保存日志,自己还添加了一些图片断言,手机状态监测等。

接口自动化 前期基于robot framework+requests 写的,后用的pytest+request PO模式,设置了定时任务,每天清晨跑一遍,监测各接口状态数据正确性

后期做了一些IOS自动化试点,基于facebook-wda,也做了android的uiautomator2,这个和appium比起来效率太高了。也简单研究了一点点安全测试的工具

团队里面也做过几次技术分享

状态:有一些影响力,和开发关系较为和谐(学习Android的知识的时候,很多都是共同进退,共同拓展,测试出一些深层次的bug,开发认同感也会上升),有一点脚本能力,对测试的理解进一步加深。

离职是因为:老板不兑现承诺,三次。

见解:

测试之路一直追求的是测试效率和测试覆盖率,如果不基于这两个目的出发,对于项目而言,都是耍流氓,身边也有不少例子,整天搞自动化写脚本,同事,开发都是怨声连连,基本的测试用例都写不好,业务完全没整明白,反馈到项目负责人去了,大会上明确不让他再写脚本了,贼尴尬。不能头重脚轻,断章取义。

测试的方向:不是所有人都得进行自动化脚本的测试,有的人的确不适合,业务方向精通也是吃香的,要清楚的自己的定位和兴趣,国内整个测试行业整体代码能力偏低,大家都是八仙果过海,各显神通,守护质量。

提升测试人效:

第一代:接口自动化+UI自动化

第二代:服务化测试平台

第三代:录制回放

第四代:智能化测试

公司的不同存在几种不同的QA模式:

重QA模式:业务复杂,开发能力较低,各环节把控度不高、

轻QA模式:业务中度,开发能力强,各环节密切,且开发有自测能力

微QA模式:业务简单,开发能力强,基于以完善的测试工具和开发自有测试能力,完全放开

传统的测试评估手段:故障数,用例个数,测试用例review,代码覆盖率 以表现出单一

就写到这儿吧,还有些迷迷糊糊的东西就不写了,理论的东西和实际的结合感悟能体会才是有用的,不管怎样,不要停止学习,停止探索,时间不早了,夜生活开始了(假装有夜生活)。以上是基于自己的一些听闻和见解,欢迎大家共同讨论,共同进步。

经历

原文地址:https://www.cnblogs.com/-lisunman/p/11310612.html

时间: 2024-10-12 17:28:00

软件测试之路再谈(三年测试风雨)的相关文章

小白的软件测试之路

从笔记本代工企业跳出来做软件测试到今天为止整三个月了,一个人从手工测试摸索到现在尝试自动化,做一下总结吧. 第一阶段:依照上一个测试人员的惯例在qc中写用例并执行,发现写的非常的糟糕,无体系且混乱.基本只涉及一些功能测试方面,而且书写非常混乱. 第二阶段:开始查找资料,梳理测试流程,将系统测试各方面重新组织规划,并尽量在有新测试对象时使用这个规范测试,并使用到书中讲到的一些测试用例设计的方法. 第三阶段:寻找自动化测试之路(公司产品分为android端和web端,重点先放在web上),这里的自动

软考复习之路—再谈组成原理

指令系统 指令系统是计算机硬件的语言系统,与硬件的联系息息相关. 指令系统是指CPU所能够处理的全部指令的集合,是一个CPU的根本属性(指令系统决定了一个CPU能运行 什么样的程序).现在cpu仍然使用者X86指令集,不同类型的计算机包含的指令系统的种类和数目是不同的. 所有采用高级语言编出的程序,都需要编译或者解释成为机器语言后才能运行(编译原理),这些机器语 言中所包含的就是一条条的指令.一条指令就是机器语言的一个语句,它是一组有意义的二进制代码. 格式 零地址 在堆栈型计算机中,操作数一般

开启软件测试之路

从大四实习到毕业到如今,从app软件开发到软件测试,所有的一切感觉自己都是在蒙着眼走路,后面有人赶着走路.是时候静下心来想想自己该做什么,静下心来学点什么,如果再一直浮躁下去,终究如咸鱼一般,碌碌无为,不知道自己想要什么,不知道自己为什么而工作而学习. 从开发转到测试已经5个多月了,自己也决定了要一条路走到黑了,记录下自己的学习,自己的工作,相信一切会好的.给自己定个小小的目标,向自动化测试迈进!

学习软件测试之客户端(Client)测试

Client测试的特点 Client测试也叫做客户端测试,他是测试安装在用户机器上的应用程序的各个功能是否可以正常运行 需要先在本机安装Client程序包,然后通过运行Client程序,进行各种数据的输入,保存等操作. 测试内容包括:安装测试.卸载测试.用户界面测试.功能测试.字符输入测试.提示信息测试.超链接测试.操作按钮测试.菜单测试.视频音频测试.程序运行权限测试等. Client测试 安装测试: 包括进行首次安装.升级安装.完整的或自定义安装.以及异常的情况,如:磁盘空间不足.缺少目录创

我的软件测试之路正式开始

开发转测试已经有一段时间了,但是我对自己测试这条路并没有一个合理的计划,一直都处于一个迷茫的状态,因为个人测试方面知识面比较窄,总感觉好多东西不会,心里就会着急,然后就东抓一下西抓一下,最后看似好像懂一些,但是真正要用还是不会,就比如前几天我在写自动化测试脚本,搭建了一个很简单的框架,写的脚本也算是顺利的跑起来了,就这样好像自己就有点满足了,有时候就不去学习了,就急着去学习性能测试方面的东西. 我知道这是病叫急于求成,最终一事无成.这两天我也借鉴了一下一些前辈在测试方面的一些学习规划,我也有了自

Google软件测试之道 pdf下载

引领一代风骚的明星企业google, 推出过很多成功优秀的产品,搜索引擎不用说,譬如Gmail ,Chrome, Google Doc, G+等等等等,也推出过很多短命的产品,譬如Google Wave等等. 作为一个时常需要推出新产品,但又要根据用户反馈而做进一步选择继续还是放弃的企业,作为一个需要让产品稳定健壮以保持客户满意度的明星企业,该如何测试是一个很大的问题.Google的经验非常值得借鉴. 该书的作者是Google测试的Senior Director(如果我没记错的话),在测试领域有

全程软件测试之测试需求分析与计划

全程软件测试之测试需求分析与计划 在项目启动之后,就要着手软件项目的计划,包括软件测试计划.软件测试计划是整个开发计划的组成部分,同时,它又依赖于软件组织过程.项目的总体计划.质量文化和方针.在测试计划活动中,首先要确认测试目标.范围和需求,其中"测试需求分析"是关键任务,然后在测试需求基础上制定测试策略,并对测试任务.时间.资源.成本和风险等进行估算或评估. 无论何时进行估算,我们都是在预测未来,并会接受某种程度的不确定性.软件项目计划的目标是提供一个框架,不断收集信息,对不确定性进

《Google软件测试之道》测试开发工程师

拖延了将近半年的草稿,断断续续的写完了.之前草草翻看完这本书,关注点主要在TE上,而关于SET的部分则只是浏览,最近后知后觉,又翻出了这本书,重新看了一遍,又有新收获. 就说说Google的SET是如何做的,以及个人的一些思考和收获吧,寥有慰藉... Google的测试流程可以简练的概括为:让每个工程师都注重质量.而在工作流程引入过程中也伴随着一些致命的缺陷,下面简述下Google是如何解决以及其测试流程的是如何进化的. ①.测试并不能保证产品质量.需要一直谨记的一点:质量是内建的,而不是外加的

我的2015测试之路 ——做一个很有想法的测试

我的2015测试之路 ——做一个很有想法的测试 不记得有多少次了,总是说等什么时候闲了,就回过头看看这一路跋涉.风尘仆仆的自己.可每次都只是想想而已,即使真的闲下来了,却又不太愿意剥开自己的心,怕看了会伤感.又怕看了会觉得失望,可能是我没有成为,当初那个我想要成为的样子吧.是该对自己说一句对不起了.对不起,我深爱的自己! 人们总是在歌谣里哀求时光慢些,不要再让亲人变老了.但它总也是不听话,于是2015年终究是被推进了历史.现在我们只能在回忆和指尖怀念2015了,诚然,2015对我们每个人来说都是