分享一下我做软件测试这些年的心路历程
Posted 我爱学电脑
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分享一下我做软件测试这些年的心路历程相关的知识,希望对你有一定的参考价值。
分享一下我做软件测试这些年的心路历程
15年的时候我从某大学毕业,大学的时候学的是光电子技术专业。
在毕业之前,已经在某上市公司的工厂里面实习。那时候的岗位叫做助理工程师,工作内容其实很简单,就是给厂子里面的电脑设置参数啥的,有时候就是让研究一下如何做出更好的晶圆。工资4000,做6休一,包吃包住。让我很难受的是刨去吃饭时间每天要工作10小时,早上8点上班,晚上20点下班。
看着厂子里的老人,从毕业待到现在待遇都没有多大变化。我在想如果我一直待在这里,以后我的人生可能就和他们一样了。
回到学校领取毕业证后,我决定回去就辞职不干了。那时候工厂里面的领导各种挽留,我们组长还为我分析未来的发展。那时候我的决心很大。领导连续和我谈了两天,后来看到挽留不过就开始让我走流程了。
我记得那时候啥都不用干了走流程走了一个月,找了各种领导签字了一波。(真是怀恋那个时候啊)
离开上市公司工厂后,那时候说实在的想要做什么还不知道。那段时间打开招聘网站,上面都是各种兼职、保险、销售的一大堆。简历放上去,每天一大堆招聘电话打过来。你都不得不在后面备注“销售保险勿扰”
每天各种公司投简历,面试。就这样漫无目的找了3个月工作。租房子和吃饭,把工厂里面存的几千块钱花的干干净净。实在不行的时候,压力真的很大,只能各种岗位都投了,看看有没有回应的。结果很多都是石沉大海。
偶然有个读计算机的高中同学在互联网公司做开发,他说他们公司有在找测试。专业不是计算机的也是可以干的。于是那时候开始研究软件测试的岗位,虽然投了我这个同学的公司,但是那时候他们觉得不太合适,连面试的机会都没有。
于是,我把简历一改,意向的岗位改成软件测试,很快就陆陆续续接到电话面试的。但是那时候真的没有接触过这个,这个岗位做啥,是个啥都不清楚。往往就是电话面试后就没有消息了。
焦虑,压力山大。
不得已我开始隐藏自己的简历,每天窝在出租屋里面开始到处了解软件测试的工作内容,学习测试理论方法、恶补计算机知识。想象着,自己身处某一互联网公司,每天需要干啥?怎么干?
说实话,那时候很多知识都能从网上找到,每天从早到晚的学习,但是都是走马观花,有时候看了n遍,没有把握其中的要点。听着视频教程里面的老师讲解,听得很认真,但是却没有领会要点。有些老师非常啰嗦,讲了老半天扯七扯八的,有用的就一点点。心态快炸裂了。就这样从开始自学软件测试开始,期间也偶尔投投简历去面试,但是都失败了。有个面试官对我说我说的都太理论了。有些东西有点驴头不对马嘴…
就这样又熬了2个多月,快崩溃了,那时候真想找个做软件测试的一起研究学习下,或者带带我。然后去咨询了一些培训机构,每个开价2w多。2w对于当时的我实在是很大一笔钱。。。不得已最后放弃了这种想法。
还好,我的同学在互联网公司,他们公司后面招到了一个5年的测试。我同学和他混了几个月,两个人混的很熟悉,我让他带带我,我给他几千块钱。就这样,我一遇到困难就问他,然后按照他的指点学习重点知识。差不多用了一周时间就把测试理论、测试工具和面试等都搞的熟的不能再熟悉了。同时也在他的帮助下,学习了一些python自动化 测试。第二周就面试成功进入了一家大概100人的公司。那时候的工资有5500,比我做计算机的同学还高500。哈哈。现在我的那些学习资料很多还保存得很好,有些我还做了更新。
经过几年的社会工作,如今的我已经是个测试开发工程师了。回顾过去,如果没有这份工作,我估计后面我可能又跑回厂子里面,每天10小时没日没夜两班倒的干活。感谢那时候刚好碰到的测试导师,是他及时纠正了我的方向,让我能够早点找到工作。现在的我除了处理公司的事物外,也承接一些测试外包的任务。时间充足的情况下,也会带上几个准备入门的学生帮助他们更好快的找到工作。
最后,我想告诫后来的入坑软件测试的朋友,软件测试除了懂得测试理论、测试工具和细心等。学习一款适合的编程语言或者学会自动化测试真的很有必要。时间就是金钱,效率就是生命,抓紧时间加油吧,上天不会辜负努力的人。
点我头像了解更多
优云老王的心路历程:那个做了五年的产品经理
前言:
老王的五年产品经理心路历程,对拍脑袋式产品决策的反思,及如何建立产品用户体验监控体系。
我从2003年”误入“运维软件行业,并在2010年开始做产品经理,5年来,我始终和优秀的团队在一起,从零开始创造了ITSM、CMDB产品,并得到了很多用户的认可。但不怕大家笑话,这5年中,我内心其实无比的纠结。面对产品的历次迭代,一方面要做出对用户有价值的功能,要说服开发团队去落地;另一方面担心产品过于复杂用户不买账,而对功能的裁剪却不敢轻易动刀。例如产品是站为用户领导设计还是为真正的用户操作员设计,大家争论不休;功能设计复杂度的把握也非常困难,真正使用者的技术背景参差不齐;用户的真实使用环境也很复杂,很多终端甚至还使用的是IE6。
从业界来看,多数产品经理也与我们的情况一样,做决定的方式基本凭直觉拍脑袋。结果可想而知,产品“堆”了很多冗余的功能,产品的交付没有工程实施人员基本不可能搞定,而用户反馈也非常不一致,有说好的也有评价差的。
我意识到,尽管我们一直强调用户画像、用户体验,但这些年对我们对用户的理解一直都是粗浅的、模糊的、感性的,比如我竟然没有一份完整的数据来描述我的目标用户,我真的对用户一无所知……我预感到这样下去不是办法,迟早一天会离用户越来越远产品失去竞争力。
幸运的是,随着互联网+时代的风格,借着公司打造新全运维品牌“优云”的契机,我终于有了解决这个问题的机会。我主动提出“Web应用体验监控”的产品目标:无限感知我们的用户,建立完备的体验监控体系,以用户数据驱动产品的设计、开发和运维!
一、Web体验监控的思考
前面扯了这么多貌似没什么用,但这是我作为一个五年的产品经理心路历程的真实写照,不知道是否有人跟我一样的想法。作为奋斗在一线的产品经理们,或是保障在后方的运维团队,我们就如同彼得大帝渴望海域一样渴望数据,希望数据是我们的前进路上的一盏指路明灯。我们不迷信数据,但我们相信数据能触及到我们的直觉没法认知的部分,而这部分是产品成功的重要因素。
为此,我开始了研究和探索Web监控的方方面面,这里不得不提到一本书《Complete Web Monitoring》,从这本书我系统化的了解了Web监控体系的全貌。无知真的是很可怕,不查不知道,一查才知道这个领域已经是百花齐放,而且不断有创新的产品出来帮助企业实现用户和利润增长。
一般来说,我们获取Web应用访问数据最为熟知的方式就是类似GA和百度统计这类工具。但是,统计工具的缺陷也是非常明显的,对于Web应用来说,PV等流量指标趋势越来越被看轻,PV并不能告诉我应用的体验情况,且在各类前端MVC框架流行的今天,前后端实现了完全分离,往往一个应用仅由两三个页面构成,这时PV其实已经失去了意义,此时应该关注的是界面内的各类交互行为,如点击、登录、提交等。
说到这里,很多人又要说了,你说的不就是自定义事件埋点吗?之前提到的很多工具都有这个能力了。对的,问题是埋点这事情说时候大多数产品经理是想不清楚的,哪里该埋哪里不该埋得事先想好,定义唯一标识、属性……好不容易弄个excel表给开发人员,开发会说这事太苦逼又没技术含量,后面你要想改的话就等着求爷爷告奶奶吧,要是埋错了的话责任是你的,谁不会犯错呢?
除了前面说的对界面中的关键元素埋点进行监控外,作为产品经理还想知道的是产品的人机交互是否足够顺畅,界面响应是否足够快,各类浏览器下是否有异常的报错,也就是产品本身的质量是否过关。产品质量不可小视,往往一个小小的挫折便使得用户离你而去或者投诉你没商量。
于是,理想中的方案在我心里逐渐清晰起来,而我们的目标是要以最小的代价为用户获取数据的洞察力,它必须满足以下几个条件:
1、侵入性小,不需要开发
2、上手简单,小白也能用
3、数据容易消费,云端自动计算好
4、保留一定的扩展性,可以满足二次开发
OK,我们的目标产品到此有了个基本的概念,接下来就是去把概念变成产品啦。在此借用一下精益开发的思路:
二、建立Web应用体验监控体系
(一)指标体系
对大多数团队而言,尤其是初创企业,没有那么多资源去做这些东西,需要在钱烧完之前找到产品的核心价值,大多数时候就想知道基本的情况就足够了:
1、究竟用户是如何使用我们产品的,最喜欢哪些功能,最不喜欢哪些功能?
2、新上线功能模块是否足够引起用户的兴趣?
3、通常用户在哪里会卡住,用户是否能完成产品所期待的任务?
4、哪些用户访问活跃,登录次数多,操作次数多?
5、了解哪些操作响应慢,哪些页面响应慢?
6、操作和页面慢的原因是什么,网络、服务端还是客户端?
……
随便就可以列出好多需要数据说话的场景。总体来说我们需要抓取的内容包括用户的操作行为以及操作行为的上下文数据,然后基于这些数据做进一步的度量分析,总体可分为三类数据:
1、行为数据:时间、地点、人物、交互、交互的内容
2、质量数据:浏览器加载情况、错误异常等
3、环境数据:浏览器相关的元数据以及地理、运营商等
接下来我们要做的就是以用户的操作行为为导向,构建全方位的Web应用监控体系,通过指标来度量用户体验,通过各种技术实现这个体系。我们给出一个基本的指标模型:
(二)方案选型
其实对于Web监控技术的整个全貌,在书中提到,了解Web用户体验无非三种方式:
1、模拟监控(Synthetic Monitoring):模拟监控顾名思义,即在网络上部署很多的监测点,定期访问Web应用看是否正常访问,访问速度如何,更深入的模拟监控还可以监控预先定义好的业务流,达到模拟用户访问的结果。优点是无须在应用上部署任何代码,可以利用此数据作为基准数据,缺点是数据并不能代表真正的用户,只能一定程度上解决应用访问的可达性问题。
2、真实用户监控(Real User Monitoring):真实用户监控抓取用户的真实访问行为,当联网的用户访问您的应用时会被自动的记录下来,不仅能获得更加详实的数据,理论上可以深入到每一个用户的行为,并对大量的数据进行聚合分析和挖掘。RUM的优点是真实可靠,可以获得深入的用户洞察力,缺点是对应用或多或少都要有所改造,常见的方式有:
a.流量抓包,这种方式需要在网络上把流量镜像出来,然后对各类协议进行还原,对Web应用而言,通常就是还原http/https协议的内容。这种方式对应用本身没侵入性,缺点是只能看到协议所包含的内容,无法将用户与应用交互过程产生的事务关联起来,而且浏览器本身的加载情况无法获取。
b.JS页面代理,这种方式需要在每个页面里面嵌入JS代码,当用户访问页面时,会在浏览器中执行这段代码完成相关数据的采集,并将数据发送到服务端进行分析。优点是可以非常完整的采集用户的行为和浏览器的相关元数据,缺点是对应用有一定的侵入性,需要把代码加载到所有的页面中,好在大多数应用基本都有一个公共的页头文件,一般来说对同一个应用而言一个地方植入后所有页面基本覆盖到了。
3、日志方式(Server Logging):服务端日志是一个宝库,每次用户与应用进行交互时,都会在Web服务器上留下痕迹,我们可以利用Splunk这类工具把服务端的数据导出来分析。跟抓包的缺点一样,无法将用户与应用交互过程产生的事务关联起来,无法获取浏览器本身的加载情况。
其实几种方案并无优劣之分,主要是看希望解决什么问题,作为完整的体验监控方案来说,几个方案是互补的,模拟监控互联网上已经有不少的服务商可以选择了,有兴趣大家可以寻找合适的即可。日志方式过于麻烦,相对来说现成的方案较少对分析的要求较高。我们的目的是要以最小的代价获取数据的洞察力,再回顾之前我理想中的方案要具备几个特点:
1、侵入性小,不需要开发
2、上手简单,小白PM也能用
3、数据容易消费,云端自动计算好
4、保留一定的扩展性,可以满足二次开发
这样一来,采用了JS页面代理作为实现方案,面临的挑战是在保证数据尽可能被完整的采集同时,还要让产品尽可能的易用,不要去劳烦开发人员,而关键的度量指标要尽可能变得容易获取,让云端的服务器尽可能的帮我们完成自动化计算。
有了天时,还要有地利和人和,好在我背靠优云的技术团队,无论在前端采集、分布式计算、大数据存储都有优秀的程序猿和工程狮的鼎力帮助,采用互联网快速迭代的研发模式,自己踩各种坑,自己先用产品,在执着中迎来产品的诞生,在坚持中促成产品的成熟:)
这次我与大家分享的第一部分,后续还会与各位聊聊我眼中的Web应用体验监控产品的六大内容!
作者简介:
王川林
•产品经理
•四年UI设计师、三年商务智能产品、五年IT运维产品
以上是关于分享一下我做软件测试这些年的心路历程的主要内容,如果未能解决你的问题,请参考以下文章