转载声明:文章来源https://blog.csdn.net/2301_78042008/article/details/130590314
一、软件测试概述
说起软件测试,很多人的印象,大概是有手就能做,「点点点」就行了。确实,大多数基础测试工程师做的都是「点点点」的工作,但是这个点呢,讲究逻辑,通过什么方式来「点点点」,能尽早暴露问题,用更少的操作覆盖更多的测试场景,从而保证产品质量,这就涉及到技巧性了。
除了「点点点」,测试同学还有很多其他的工作可以做,那么实际的测试工作是怎样的呢?
测试同学的职责无非就是两个,保证软件测试质量和提高测试效率。
为了达到这两个目标,测试同学的日常就包括:常规需求的功能测试,自动化测试,性能测试,跟踪线上反馈问题,搭建测试环境,把控项目进度和质量,开发测试平台或脚本,进行部门的管理工作等等。
1、常规需求的功能测试
包括参与需求评审会议,制定测试计划,编写测试用例,评审测试用例,执行测试用例,提交Bug,回归验证Bug,发送测试报告,进行线上验证等一系列活动。
2、进行性能测试
根据项目需求,对重要接口制定压测方案,利用Jmeter等测试工具进行压力测试,配合开发同学找到系统瓶颈,并产出压测报告。
3、进行自动化测试
利用自动化测试工具例如Robot Framework,Python+unitest/pytest,Selenium等完成页面UI自动化或接口自动化,提升测试效率,尽早暴露问题。
4、跟踪线上反馈问题
在日常测试中,线上问题不可避免,反馈过来的线上问题,需要测试同学过滤和重现,再同步给开发同学,并协助开发同学定位问题,待开发同学解决后,测试同学验证完成后上线。
5、搭建测试环境
有的测试环境由运维同学来搭建,而有些则需要测试同学来搭建,视不同的公司而定,搭建测试环境会有文档,根据文档,即可完成,一般的测试环境有Linux,Windows,而Linux偏多,因此会用到较多的Linux命令,平时学会一些基础的Linux命令是很有必要的。
6、把控项目进度和质量
对于项目中出现的Bug和不确认点,需要测试同学积极推进,及时与产品和开发同学沟通,尽快解决问题,推动项目的进展。
对于产品的质量,测试同学会对定期进行Bug统计,分析Bug原因,如果质量一直很差,就会采取一些措施来积极改进和提升。
7、培养测试新人
新人在试用期间,会分配一位导师,对其工作内容和转正考核负责,一般由测试组长承担该角色。
8、开发测试平台或脚本
有些公司有专门的测试平台,来完成Bug统计与质量分析,接口自动化统计等等功能,这部分开发工作会由测试开发工程师来承担。
9、进行部门的管理工作
管理工作由领导承担,包括各项目的人员安排,项目测试时间的评估,项目测试进度跟进,部门成员绩效考核,人员招聘,团队建设等等。
二、所需能力模型
想要做好软件测试,需要具备两方面的能力,即硬实力和软实力
一)硬实力
硬实力,也就是测试同学需要的专业知识,具体的知识体系如下:
1、软件测试基础知识
有幸上了软件测试这门专业课,算是入了门,为后续的职业发展也打下了基础。
入门测试基础知识,主要从软件缺陷,软件开发周期模式,软件测试分类,软件测试用例设计方法等方面入手。
2、软件测试流程
业界比较规范的软件测试流程是:需求评审,制定软件测试计划,编写测试用例,进行用例评审,执行测试用例,提交Bug,验证Bug,发送测试报告,进行线上验证。
但是在实际工作中,往往不会有这么规范的流程,我只在一家公司经历过这么规范的流程,当时刚好公司进行流程规范,请了何勉大佬,来公司专门做指导。
该大佬, 是一名资深精益产品开发顾问,专注于精益产品交付、精益创业、创新及精益产品设计等领域,曾为华为、平安科技、招行以及多家成功的创业公司建立或引入精益产品开发和创新方法,推荐大家看看他的书籍 《精益产品开发:原则、方法与实施》。
大多数不规范的流程主要分为以下几种:
1)没有需求评审,开发完直接提测
需求由开发同学口述或者在邮件中进行简单的说明,测试同学就开始介入测试。
在需求不明确的情况下进行测试,测试同学往往在沟通需求的过程中花费很多时间,而且最后可能会背锅。
这种情况下,测试同学则需要记录好已经测试的点,并与开发和产品同学确认清楚范围,只能保证当前已经测试功能的正确性,其他未测功能风险未知,并在测试报告上做明确说明,万一以后线上有Bug,可以拿测试报告说话。
2)没有用例评审环节
用例评审,即测试,开发,产品三方一起,确认测试点,旨在避免遗漏测试点,在比较复杂的系统中会有该环节,对于逻辑很简单的系统,就没有必要了。
做好用例评审,要把握好评审的粒度,如果粒度太细了,与会的同学会比较疲,参与感会越来越弱,所以把握好粒度很重要,列出测试点即可,不用特别详细。
3)没有Bug管理工具
在Bug管理系统上记录,有利于质量分析,同时Bug库也是一个很好的测试用例库,很多Bug具有普适性,在不同的项目中可以相互借鉴。
有的公司没有Bug管理系统,直接用文档记录,或者发在群里,Bug比较少还好管理,但是Bug一旦多起来,就容易混乱,前后端的Bug需要不同的人员认领,修复了没有地方去更新状态,最后也不利于质量分析。
有的公司则是有Bug管理系统,但是由于开发人员的KPI与Bug数量有关,内部默认不记录Bug,直接用IM沟通,手动记录。
理论上来说,Bug管理系统是很有必要的,不仅能节省沟通成本,还有助于质量分析,大家如果合理利用,能带来很大的价值。
3、常用的测试工具
1)测试用例工具
编写测试用例的工具有很多,常见的有Xmind,Excel,TAPD,Testlink,Zentao等,在实际工作中,因为Xmind的简单和便捷性,用到的是最多的。
2)项目管理工具
常用的项目管理工具,有Zentao,TAPD,Teambition,Coding,Jira,企业自研工具。
在实际工作中,接触的到主要有Jira和企业自研工具,在何勉老师精益指导的过程中,用到的就是Jira,对于每一个需求,开发和测试同学,都会认领一个task,task的周期从开始到结束,每天站会沟通后,及时更新task的状态,在每个季度末,统计每个需求所花费的时间,做项目管理分析。
3)Bug管理工具
常见的Bug管理工具,有Jira,TAPD,Zentao等。
Bug是一个很有价值的系统,定期进行整理和分析,不仅能发掘很多测试点,还能评估项目的提测质量。
4)自动化测试工具
常见的自动化测试工具,有Jmeter,Appium,Postman,Selenium,Robot Framework,Python+unitest/pytest。
Jmeter,大多数时候用来做压力测试,偶尔也用来做接口自动化测试。
Appium,用来做移动端的自动化。
Postman,用于接口测试。
Selenium,用于Web应用的自动化。
Robot Framework,用于UI或接口自动化。
Python+unitest/pytest,用于接口自动化。
自动化,分为接口自动化和UI自动化,性价比相对较高的是接口自动化,接口的变化比较小,相对好维护一些,而UI自动化,页面变化快,维护成本高,所以很多项目都不考虑做UI自动化。
对于实际的项目经验,我最熟悉的还是Jmeter和Robot Framework,曾经利用Robot Framework完成了项目从0到1的UI自动化和接口自动化,接口自动化覆盖率达到90%,并集成至CI上,每天自动跑,有问题及时发送邮件,大大提升了冒烟测试效率。
5)抓包工具
常见的抓包工具有Fiddler,Charles,Wireshark,这三种都比较常用。
抓包,也是为了更好的协助开发同学排查问题,出现了Bug,通过抓包,可以更清晰地排查是前端问题还是后端问题,比如未发送请求,或者传参错误,字段取值错误等都是前端问题,接口返回报错或者返回字段值错误等则是后端问题。
6)辅助工具
常用的辅助工具有Navicat,Xshell,Wiki,F12等等。
Navicat主要用来连接数据库,可查看数据库的字段,或通过SQL进行数据报表的测试等等。
Xshell主要用来远程连接Linux服务器,对服务器做一些基本的操作,在目录查看文件,启动服务,安装软件等等。
Wiki,主要用于公司内部的文档沉淀,例如编写接口文档,测试文档等等。
F12,抓取接口信息,查看接口请求和返回,区分前后端Bug。
4、基本的SQL语句
在实际测试过程中,例如一些列表或数据报表的展示,需要用到基本SQL语句的增删改查,所以掌握一些基础的SQL语句是很有必要的。
5、基础的Linux命令
在部署Linux环境,做压测等会用到Linux命令,熟悉一些文件管理,压缩与解压,性能监控,系统管理,用户管理,软件安装等命令就满足日常工作的需要了。
6、架构相关知识
架构知识需要结合实际的项目,在日常测试中,可以与开发同学多多沟通,了解下架构相关的知识,主要从语言,框架,部署等方面入手。
一个好的架构具有高可用,高性能,可伸缩,可拓展等特性。
二)软实力
大家不要忽略软实力,软实力有时候甚至比硬实力更重要。
软实力包括沟通协调能力,自主学习能力,文档输出能力,团队管理能力等等。
1、自主学习能力
在测试日常中,与产品,研发同学沟通必不可少,要是沟通能力不行,比如需要确认的需求点说不清楚导致线上问题,与开发同学的测试范围确认不清楚而导致漏测,这无形会给日常的测试工作增加难度。
自主学习能力,这点很重要,我们生在互联网行业,大家知道,技术更新是日新月异的,时常关注行业新框架,新技术和新动态是很有必要的。
2、文档输出能力
文档输出能力,编写测试报告,编写邮件等等都涉及到文档输出能力,这些报告和邮件是平时测试的成果,在业绩考核中也占有一定的比重,如果只会埋头干活,不会表达成果,升职加薪也是有难度的。
3、团队管理能力
团队管理能力,有句话说的好,学而优则仕。的确,大家不可能永远待在基层岗位,大多数人都会慢慢往管理岗靠近,团队管理能力的重要性不言而喻。
三、职业发展方向
软件测试工程师的职业发展,可以分为四个方向:
一)业务测试工程师
业务测试工程师,在测试群体中这个比例是非常大的,这是最接近用户的一个群体,这部分的测试工程师主要负责常规需求的功能测试,接口测试,自动化测试,性能测试等。
涉及的业务主要有电商,金融,在线教育等等,不限于Web,客户端,移动端的测试。
我待过测开比1:10的团队,也待过1:1的团队,具体的比例取决于业务形态和公司的资源,有的项目逻辑简单,开发周期短,出事故的概率低,造成的损失低,测试人员就会配置的少一些,而项目逻辑复杂,盈利多,开发周期长,测试人力就会配置的充足些。
在微软,测开比一般为1:1,在谷歌,测开比则为1:10,还是那句话,现状决定流程。
二)测试开发工程师
测试开发工程师,主要开发公司内部的测试平台/测试工具,也为业务测试工程师解决一些技术问题,例如搭建自动化测试框架,编写一些提升效率的自动化测试脚本。
测试开发的要求比业务测试工程师高一些,需要写得了代码,测得了需求,也就是即会开发,又会测试的同学。
一些小公司是没有测试开发工程师这个岗位的,一是没有自研的测试平台,而是由业务测试的同学偶尔做做补充,业务测试的同学也可以写点小脚本和小工具,所以就没有设置专门的岗位了。
测试开发的人员比例,我历过的公司大概是1:10,2个测试开发工程师,服务于20个业务测试工程师,具体比例取决于目前公司的现状。
三)管理岗
主要是进行部门的管理工作,包括各项目的人员安排,项目测试时间的评估,项目测试进度跟进,部门成员绩效考核,人员招聘,团队建设等。
1、入门级
很多同学是校招或者社招转行进入软件测试,初入软件测试的前两年,职位一般是初级测试工程师,大家都做着最基本的测试工作,主要是进行功能测试,熟悉业务,能保证上线的产品不出大问题即可。
2、3年左右
业务组长,作为项目的主测人员,重点在测试计划的制定和执行,测试任务的安排以及估期,保证项目能按期交付,线上不出现重大的事故,管理人数大约在3~5人。
3、5年左右
测试主管/测试经理,该阶段的工作主要包含测试计划的制定,更多的是关注重难点项目,且需要掌握更多项目管理的知识,深入理解项目的价值,做好项目管理,成本管理,风险管理和人力管理,同时也会参与一些招聘,员工绩效,质量管理,风险管理的工作。
4、8年或以上
测试总监,该阶段需要理解产品的商业目标,直接对产品成功负责。该阶段的主要工作包含管理测试团队,进行人员招聘,带好整个团队的节奏,优胜劣汰,留住核心人员,淘汰达标的人员,提升团队战斗力。
同时需要负责资源的计划和分配,持续改进测试能力,提升测试效率,保证产品质量,从测试的角度对交付的产品和质量负责。
四)转型
如果对测试没有很大的兴趣,觉得自己的沟通能力还不错,更喜欢与人打交道,可以转型到产品岗。
在业界,有很多从测试成功转型为产品的同学,他们后续发展的非常好,因为测试对于产品功能是非常熟悉的,产品需要的能力与测试有较多的重合,所以相对来说,转型的难度不高。
如果热衷于技术,追求技术带来的成就感,可以转到开发岗,在实际职场中,测试转开发的比率是很小的,测试同学要求的知识面是广而浅,开发同学要求的是精而深,个人兴趣和技术难度可能是转型少的一个原因。
其实还有好多选择,可以转型做测试咨询,创业,滴滴司机,或者外卖小哥等等都可以的,遵循自己的内心,选择想要的岗位。
四、六年软件测试心得
一)面试篇
1、多面试
不管有没有换工作的想法,建议每年都出去试一试,一方面可以多看看机会,另一方面可以结合外面的要求,查找自己的不足,让自己始终保持竞争力,不至于在公司突然裁员的时候,束手无策。
介绍几个面试的小技巧:
1)突出展示擅长项
有的同学擅长接口自动化测试,可以在面试前深度梳理,在面试中着重表现,例如熟悉Robot Framework测试框架,完成了项目从0到1的自动化测试,从环境搭建,用例编写,到CI集成,邮件发送测试报告等等,尝试引导面试官不断深入自己会的知识点。
有的同学擅长脚本的编写或测试平台的开发,项目经验可以着重描述开发的测试平台包含的功能,解决的问题,运用的技术,提升的效率等等。
有的同学擅长业务测试,对各种业务烂熟于心,项目经验则可以着重描述接触过的业务,运用的测试方法,上线质量等等。
2)用数据说话
数据,用来展示测试成果,是很有说服力的。
有的同学会自动化测试,展示成果的时候,可以描述自己实现了多少模块的自动化测试,共计多少条用例,测试覆盖率达到多少,效率提升了多少。
有的同学善于项目管理,改善项目流程,提升整个项目团队的交付能力,可以描述自己帮助多少个团队,规范了项目流程,项目交付能力提升了多少。
3)项目经验或技术能力与面试公司尽量匹配
在招聘过程中,大多数公司偏向于招与当前岗位匹配度高的人,因为来了可以快速上手,节省学习成本。
在实际工作过程中,我们接触的项目可能很多,但是在面试过程中,尽量说与当前岗位匹配度高的项目。如果项目业务不匹配,技术能力栈匹配的也可以,能增加面试的通过率。
总之,就是尽量往JD上的要求靠。
2、看面经
如果想进大厂,可以先看看大厂的JD,再去网上找对应的面经,有些面经写的很仔细,值得参考。
常见的渠道有:牛客网,知乎,公众号,简书,CSDN,测试论坛,知识星球等等。
3、投简历
投简历,建议不要海投,能内推最好了,内推拿到面试的机会是很高的,可以找自己身边的朋友,同学,师哥师姐,球友等等内推。
4、慎选择
有的人对于大厂有一种情怀,但是不是大厂的每一个部门都是很好的。进大厂,最好选择大厂的核心业务部门或项目组,不要去边缘化的小组,否则理想和现实的差别很大。
在进厂之前,建议提前找内部的人员了解,或者在面试的时候,主动询问,充分权衡好之后,再做选择。
二)日常篇
1、主动沟通
平时的工作中,尽量主动一点,比如多与开发同学沟通,可以加深对项目的理解,而不仅仅局限于对功能的测试,比如实现语言,框架,技术方案等等都可以学习。
多与产品同学沟通,而不是纯粹做一个需求文档的阅读者,多问几个为什么,比如产品的商业价值,用户的使用习惯,交互设计的逻辑等等,这些,都是我们可以精进的地方。
多与领导或部门小伙伴沟通,与领导沟通,主动表达述求,对自己的工作保持一点想法。如果自己对工作任务,或者发展方向有困惑,一定要及时与领导沟通,向领导表达自己的想法,这样,领导在分配任务的时候,会优先考虑主动申请的人。
比如有同学一直在做纯粹的业务测试,很少涉及到自动化或性能测试,而自己又想往这方面发展,可以向领导表明自己的想法,这样,后续有这方面的任务,领导会优先考虑,亲测有效。
如果有想法但是从来不向上反馈,领导也不知道我们目前的想法,就会默认对于目前的工作安排比较满意,所以有好的机会也不会轮到自己头上,还是那句话,主动就会有故事。
2、勤于分享
在工作中,分享是一项很加分的技能。
有的同学热衷于研究自动化测试框架或脚本,亦或是一些能提升测试效率的小工具,但是很少分享,只有自己在那捣鼓,独乐乐不如众乐乐,分享出来,大家一起用,既提升团队测试效率,又能在领导面前留个好印象,一举两得。
分享,其实也是打造个人影响力的一种表现,你很NB是一种本事,让大家都知道你NB,才是真的NB。
每年的分享,很多公司会作为测试人员年终KPI考核的一项指标,所以,多分享,没错了。
3、及时总结
总结,其实是一个复盘的过程,也是一个自我改进提升的过程。
测试过的项目,用到的测试工具,思想和方法,碰到的难点以及解决方法等等都可以总结记录,并以文档的形式输出沉淀,都是一个很好的积累过程。
在下次碰到同样的问题,可以有自己的一套思路,或者分享至博客,记录在公司WIKI,对他人来说,可以避免踩同样的坑,利他即利己。
帖子还没人回复快来抢沙发