软件测试求职自我评价

温柔似野鬼°
681次浏览
2021年02月13日 08:21
最佳经验
本文由作者推荐

-

2021年2月13日发(作者:具有诗意的网名)








三一文库(



)


/


个人简历





软件测试求职自我评价







我最初 参加测试工作的时候,


不知道什么是软件测试,


集成

< p>
测试和系统测试的概念经常混淆,


cmm


是什么就 更加不知道了。


那时候最简单的开关机也是通过直接拔插电源完成,

安装系统对


我来说简直是有史以来人类的技能,


对于那些拿 着螺丝刀安装机


器的人就认为是宇内超级高手,


身具杀人于无形 之绝世秘技。


拿


破仑说不想当将军的士兵不是好士兵,


我最初的梦想就是想成为


软件测试的高手,傲视天下。所以不断偷师,总 结经验,自认为


掌握了成为高手的几个秘技,这几年混迹


“


江湖


”


还算无往而不


利。不敢独享,望与吾辈测试人员切磋,早日总结成功密技之大


成,助新进人员早日入 门,也算不愧对东北活雷锋的称号。





第一招学会利用网络





刚参加工作面对浩瀚的网络世界, 当时如刘姥姥进大观园,


什么都新奇,什么都想要,从网上下载很多源程序的代码,软件


技术文档之类,


恨不得把所有的好东西收集到手中,

< p>
其实有些在


他人看起来就是垃圾一堆。当时觉得有了这些

< br>“


武林秘籍


”


,成为

< p>
高手指日可待。最初参加工作由于自己工作努力有幸转为开发,


加入项目组 后我的习惯还是没有改,


反而变本加厉,


手中的资源

< p>
更加多,上网的时间更加频繁。





一次项目经理分配任务,觉得依靠手中的秘籍加上自己的


“


聪明才智


”


很快 会完成,不料短短的时间,所有的一切变成了马


奇诺防线。解决问题很慢,思路不清晰, 项目经理在对我施压的


过程中教会了我终身难忘的一招,


学会利 用网络寻找要解决问题


的答案,从此


google


成了我的最爱,关键字成了我变化的招数。


在软件测试工作中,


他帮我解决了很多疑难问题,


解答了很多令


我迷惑的 地方。


也是我帮助测试同行解决问题手段之一,


很多软


件测试新手,甚至老手都没有意识到自己手上就握有


“

< br>无敌秘


籍


”


,所以只要你耐心找 ,答案就在身边。





这里总结一下利用网络搜索引擎的技巧:





组合搜索





每次搜索某个文件,


如果只给出一个单词进行搜索,


经常会


出现成千上百 万计的匹配网页。


然而如果再加上一个单词,


那么


搜索结果会更加切题。





选择表述内容的词组





一般我在网页搜索引擎的时候,


选择 一些可以表达我要查找


内容的关键词组,


用来缩小搜索范围,< /p>


从而找到搜索结果是的办


法。运用词组搜索涉可以先先简单地输入 一个问题作为词组搜


索,


如果仍然找不到合适的,


那就用多个可以表达要查询内容的


关键字进行查询。





定位信息来源





有的时候用词组搜索不到或者无法准确表达所需信息。


可以


用另一种方法直接到信息源,


就是直接到 到提供某种信息的站点


去。


可以用公式


“


公司名


.”


去猜测某一组织的特点。


从而得到所要


搜索的信息的主要词组





其实网络上还有很多关于搜索技巧 的文章,


大家可以自行学


习。千万要记住搜索引擎是帮助你成功 的有力武器。





第二招学会动手





参加软件测试工作后,


随着工作经验 的增长自我感觉越来越


好。


在公司里也逐渐受到同事领导的重视 ,


一次针对公司的新的


软件功能进行测试的时候,


像往常一样


“


随手


”


测试出了几个


bug


,


然后


“


仔细


”


的填写了


bug


单


(


这个


bug


的现象已经出现了很多次

< br>了


)


。这时候测试经理走过来,重新复查了一下填写的< /p>


bug.


他在


重现我的

< br>bug


的过程中,简化了我的输入变化,


bug


神奇的又出


现了,同样的现象,他关闭软件重新变化输入,扩展出


10


几个


变化后,软件不动了,内存不断上升 。终于他找到了产生软件的


bug


的原因,然后对我说


“


寻找


bug


要准确定 位,我们开发团队


是一个整体,时间是等量的,时间不在你身上浪费,就是在他身


上浪费。


如果测试人员每次发现的


bug


描述不清楚,


并且多个问


题潜在的错误原因 是一个,


虽然操作可能稍微有些变化。


这样开

< br>发人员在重现


bug


的时候他要调试跟踪判断,


很花费时间,


而且


效率低。

如果测试人员发现


bug


的时候多动手可以更加准确的定< /p>


位


bug


步骤和原因,

< br>给开发人员最精确的步骤和准确的描述,


这

-


-


-


-


-


-


-


-