三年测试的风风雨雨

发表于:2019-8-08 10:46

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:木秀    来源:网络

分享:
  碧水涟涟,夏至未至,秋风依依,梅花落时,已是一生
  一初衷:
  为什么写这篇博客?
  个人性别偏于低调,最近换了新工作,坐标成都,就任于一家T系公司。
  1、公司是以项目为单位,有测试团队但没有测试部这个概念,测试团队人数大概60人左右,但都基本跟你没任何关系,只有项目上的其他两个成员跟你有交集,缺少后方养分,差异性,一时间不太适应,
  2、业务划分很精细,能接触到的东西十分有限,还有各模块之间弱化了连接测试,担忧。已经发现过问题,而且也和组员讨论过他们也赞同这种方式容易出现质量弱化
  基于以上有些迷茫吧。今日加班值班,做个小小的往期回顾和总结。
  当时入行软件测试半年后,是一种即有点期待(有些兴趣)更多是迷惑(当时所在测试部门不追求技术功能测试为主)的状态写下来的记录,碎碎叨叨,想不忘初心。
  二回顾:
  薪资
  阶段一:J公司
  ?K(2016年上半年-2018年上半年)
  阶段二:X公司
  ?K+3K(2018年上半年-2019年7月)
  阶段三:K公司
  ?K+4.3K(2019年7月-今)
  备注:有些线索可以猜到博主所在公司,一个是为了职业素养,二来避免不必要的麻烦,博主只展示一下待遇的提升,主要还是聊聊测试之路,三年测试风雨。
  经历:
  J公司:16年毕业于一家极其普通的本科院校,年少轻狂,学术不精,毕业时虽有公司愿意我前往,但我简历写的是测试,入职后是干的开发的活,终日闹累,加班严重,对于测试的一些兴趣和自己的思维方式(HP以前在学校做过测试讲座,出了一道拓展题目,桌子上有一杯水,怎样使水不在杯中,大家穷举例,物理、化学、电解等等方法,最后我举手回答,把杯子的外部注满水,这样就是杯在水中,不在是水在杯中了),我觉得自己适合做测试一些,2个月后辞职找了一家普通的公司做测试,测试团队大概15人左右,妹子较多,业务复杂,只要求功能测试,自己在项目期间看了很多基于测试的书籍,理论的,比如《微软测试之道》、《google软件测试之道》、《探索性测试》、《测试的艺术》等等,自学了PythonSelenium。并应用到项目中,个人应用过来,在团队推广过自动化测试,但是,妹子们表示,那都是花架子,没得意思。没有共鸣,这也是我为何辞职的原因。
  状态:影响力较小,和开发关系很普通,脚本能力一般,但有一定的涉及和基础。
  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,代码覆盖率 以表现出单一
  就写到这儿吧,还有些迷迷糊糊的东西就不写了,理论的东西和实际的结合感悟能体会才是有用的,不管怎样,不要停止学习,停止探索,时间不早了,夜生活开始了(假装有夜生活)。以上是基于自己的一些听闻和见解,欢迎大家共同讨论,共同进步。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号