提示:阅读本章之前,请先阅读目录
最新字节跳动50道真题面试题,快收藏
面试官,你好,我在上家公司的测试流程,整体是这样的。
首先,产品经理会编写需求报告,然后通知测试人员和开发人员,三方进行需求评审,需求评审的目的是对需求进行讲解和答疑,对于一些需求没有形成闭环的,以及产品经理没有考虑到的问题,由我们的测试和开发进行补充。
然后就是,由我们的测试经理,编写测试计划和测试方案,主要内容包括需要哪些测试人员参与,时间计划的安排,每个测试负责哪些功能模块,也包括,在测试过程中会存在哪些风险,对于这些风险,要怎么样去预防,以及出现了这些风险之后怎么样去处理,进行一定的规范,同时,约定了测试的边界,
接下来,就是我们测试人员,对自己负责的功能模块,编写测试用例,编写完之后,由我们测试内部进行测试用例的评审,评审的目的在于尽量丰富测试的内容,同时避免因为个人需求理解的偏差,导致测试用例的错误情况发生,以及会出现漏测的情况的发生。
测试用例评审通过之后,我们先进行冒烟测试,对项目的主要功能,以及主要业务流程进行测试,当符合转入测试的标准之后,我们就会开始整体的功能测试,在功能测试阶段,我们会多伦进行交叉测试,交叉测试目的是能够尽量发现系统中可能隐藏的缺陷,因为测试人员测试过的功能,在进行第二次测试的时候,会不够详细,这个时候,我们进行交叉测试,不同测试人员他的测试步骤是不一样的,所以,能够极大的保障测试的质量,之后就是,输出测试报告。
由我们的测试经理,来判定测试报告的结果,通过还是不通过,如果不通过,就会根据哪些测试用例执行有问题,重新修正之后,再次进行判定,直到通过。通过之后,会先发布的预生产环境,进行验收测试,我们会会同,产品经理,测试,开发,进行验收测试,验收测试的目的是,让业务部门来验证是否满足他们的需求,以及需求理解有无偏差,然后验收测试通过之后,我们就会上线项目,上线之后,会持续关注项目运行的情况,如果有出现功能异常问题,我们会及时介入,排查问题。
最后,我们会进行复盘,对当前版本,有哪些做的好的地方,哪些做的不好的地方,不好的地方,我们会总结原因,然后提出建议,再进行改正,做的好的地方,大家互相学习然后鼓励支持,这样的一个复盘,可以提升我们团队的测试效率,让我们团队的测试能力不断得到提升。
项目立项,产品经理进行需求分析
需求分析,产品经理对需求进行详细分析
总体设计,产品经理对项目产品进行整体的设计
详细设计,产品经理对项目产品进行详细的设计
开发编程,开发人员根据需求进行开发编码
系统测试,测试人员根据测试计划进行测试
上线发布
我在测试之前公司的一个项目中,在一个表格分页器,发现了bug,这个表格分页器有个输入,可以到达指定页数,所以,我就用了边界值法去设计测试用例,并且用等价类法,测试是不是只能输入数字,不能输入字符,结果就是,只能输入数字,其他字符不能输入,边界值法也通过测试,但是,我就根据了错误推断法,因为之前在类似的功能上,对数字进行处理的输入框,有时候,很容易忽略小数点的问题,所以,我就测试1.5,2.5这样的小数点数字,结果直接500,服务器报错,然后,后面,我就把这个bug提交到了前端开发和后端开发,然后开发人员及时进行修复,避免了上线到版本出现的问题,这个原因,主要是前端没有对输入框进行限制,只能输入整数,而后端也恰好没有对分页数字进行整数的判断。
测试结束的标准,我总结了以下几个方面
第一,全部的测试用例执行完毕
第二,未被处理的缺陷,需要全部确认或者设为应有的状态,暂缓处理的缺陷,需要明确标注原因
第三,测试报告的完成
第四,达到测试计划的测试结束标准,比如,严重缺陷全部解决完毕,重要缺陷全部解决,一般缺陷解决率99%以上
第五,测试总结结束,总结此次版本,做的好地方,和做的不好的地方,对此次版本进行复盘
短信功能是否能够正常打开和关闭
短信是否能够正常发送和接收
短信是否能够给特殊号码发送短信:
短信发送失败是否有反馈
短信发送的内容是否支持所有字符
短信发送的内容是否支持图片,视频
短信功能的耗电量
短信发送是否会消耗流量
短信的干扰测试:
短信是否支持同时发给多个手机号
最基础的就是,是否能够写和画
笔的长度是否让人用着舒适
笔写出来的字会不会断触
笔是否支持更换笔芯
笔是否能够拿来当书签
笔是否能够拿来戳气球
桌脚不平,是否能够拿来垫
是否能够拿来切割胶带
是否能够拿来转着玩,消遣
是否能够拿来当收藏品
是否能够拿来拍卖
是否能够当筷子
是否能够拿来掏东西
在手里是否能够正常使用
在太空是否能够正常使用
在南极是否能够正常使用
在温度特别高的地方,是否能够正常使用
使用不当是否会对别人造成伤害
能用多久
三个方面
人力资源
硬件资源
软件资源
冒烟测试也叫验证版本测试,也可以叫转入测试。在开发完成开发阶段之后,提交给测试之前的冒烟测试,在开始整体的系统测试之前,我们都会先进入冒烟测试,测试主功能,主业务,主流程是否能够正常运行,一般我们都是会拿半天,或者3,4个小时进行测试,看看是否值得进行大规模的测试,如果符合转测标准,那么就可以开始系统功能,否则,就会打回给开发,不符合转测标准。
冒烟测试一般不会测试次要功能,以及各种细微的错误。
为什么要进行冒烟测试,主要是避免测试的工作变的毫无意义,并且避免影响到项目进度要求,比如,一个版本,可能要两个星期实现,也就是14天,如果开发进行了10天的开发,然后交给了测试,如果测试这个时候,不进行冒烟测试,而是直接开始系统测试,那么,等到测试工作结束,2,3天,才发现系统主功能都无法运行,叫给开发修复,而剩下的时间,是完全不够开发修复的时候,并且也不够二次测试的时间的,导致项目版本发布时间被迫延期。
测试计划的内容包含
产品概述:描述项目版本内容,以及产品功能有哪些,具体需要测试哪些内容
测试策略:指定测试的方法,是功能测试,还是性能测试,还是自动化测试,需要多少人,做几轮测试
测试方法:系统功能测试,需要用人工测试,少部分用自动化测试
测试资源:包括人力资源,软件资源,硬件资源,根据测试计划去准备资源
测试周期:测试需要测多久,需要固定下来,规定几轮,每一轮的时间安排
风险分析:此次版本会对之前哪些功能造成影响,如果有其他产品在并行开发,就会存在人员资源风险,开发人员转测的时间推迟了(需要测试加班赶进度)
主要目的就是指导测试活动的方法,进度,范围,资源等,明确测试项目要测试的内容,人员责任的划分,以及确保测试工作能够根据测试计划开展。
以实际工作为例,我会先了解测试计划的内容,看看有此次项目版本呢,它可能会影响上个版本什么功能,以及此次版本主要是哪些功能,测试的内容是什么,测试策略中,我们需要用到什么样的测试方法,以及测试周期,进度时间的安排,我需要先提前,整体的了解情况。
然后,我再根据需要测试的功能,提取测试点,很多测试人员,他都是直接去根据这个需求文档,然后直接开始写测试用例,这样是一个非常不好的习惯,因为你没有把测试点都提取出来,如果在中途,离开了,再回来了,就可能会漏掉一些测试点,所以,我都是会先提取测试点,然后用思维导图,列出所有功能,以及功能对应的测试点,然后我再根据,测试用例的设计方法,比如,边界值法,等价类法,错误推断法,场景法,这几种常用的设计方法,进行结合,然后去测试一个比较全面的测试用例。
然后,就会进行测试用例的评审,然后,对于没过评审的测试用例,我会进行优化修改,然后再等待执行测试用例的开始。
验收测试就是对业务流程进行正式测试,以确保系统符合验收标准,给客户或者需求方验证系统是符合业务需求的,在产品开发完成并通过测试之后,我们要交付给客户,那么,我们就需要进行演示,以及验证,让客户满意,并达到客户的需求,并且在演示过程中,客户可以提供意见,然后产品经理统一整理之后,排期安排开发。
验收测试的过程,我们公司是自研的项目,所以,需求方,可能是财务部门,也可能是销售部门等多个部门,所以,产品经理就会要求这些业务需求方,具体的负责人,来参与验收测试,然后,产品经理或者测试经理,就会根据验收测试用例,进行演示,对业务流程进行演示,并给业务需求方进行简单培训,目的是让需求方对系统建立信任,对非功能性的特性赢得客户的认可。
这个确实是工作中,经常会遇到的问题,不过,掌握好方法,也是比较好解决的。
首先,开发不认为是bug,开发肯定是根据了自己的经验以及思维来判断的,那么,我们就需要先分析自己,是不是哪个地方出错了,导致这个误测。
导致误测,有很多原因
第一个,对需求理解有偏差,所以,我们需要重新去翻看需求文档,查看这个功能的具体描述,以及用途,再对照测试点以及测试用例,确保我们的测试用例是符合需求的。
第二个,测试数据有问题,有时候,由于我们的测试环境,会产生非常多的,错误的,无意义的测试数据,而这些错误的测试数据,可能就会导致测试结果是错误的,它是不符合需求的,所以,我们需要排查我们的测试数据是符合需求的
第三个,操作步骤,我们对业务流程的操作步骤,是不正确的,没有按照正确的业务流程来走,就有导致不符合业务流程,也就是不符合实际需求,也会导致误测的情况
所以,我们需要先排除这几种情况,确保不是因为自己的问题,导致这个bug的,而是这个bug是真实存在的。
那么,我们就要看依据需求文档,复现步骤,测试数据,然后找开发进行沟通,把我们的这些数据呈现给开发看,并复现这个bug,以及,我们还要给出修复这个bug的价值,让这个bug是值得修复的。然后,一般情况下,这个开发,会认同我们测试人员的解释,那么,就会确认这个bug,并进行修复。如果开发还是不认同这个bug,那么,我们就可以找产品经理,因为这个需求是产品经理输出的,那么,产品经理就有话语权,来决定这个是不是bug,以及这个bug如何处理。
TCP协议就是,可靠的传输协议,会经过三次握手,四次挥手的连接过程,确保对方能够100%收到数据,并且有丢包重传,如果对方没收到哪个包,那么就会重新发送,直到对方收到。所以,TCP是安全可靠的传输协议,像HTTP,HTTPS用的基本上都是TCP传输协议。
UDP协议,就是不可靠的传输协议,它是直接跳过验证过程,不需要确认对方在不在线,就直接向对方发送数据,这种特点就是效率高,适用于视频等业务,我只需要不断的发送数据给对方,至于对方有没有收到不需要进行确认。
所以总结一下就是,TCP是面向连接,UDP是无连接,TCP是可靠的,UDP是不可靠的,UDP是报文传输,TCP是字节流传输
对于BUG的定位,我会从接口进行分析,因为现在项目都是前后端分离的,如果脱离了后端接口,前端其实只要不用到接口,也是可以运行的,所以,我们就会以接口作为分界线,没有调用到接口的地方,就都是前端的范围。
我会先抓包,抓取这个包之后,分析是哪个接口导致了BUG,然后,再去接口文档查看,该接口的请求头,请求参数,请求方法,以及响应状态码,响应体包含了哪些东西,以及响应返回的数据格式,类型是怎么样的。
然后,如果说,在请求参数,传递错误,请求头,请求方法和接口文档的不一致,那么就是前端请求出现了问题,这个时候bug就归属前端。
如果说,是响应头,响应数据中,数据结构有问题,响应的数据不符合接口文档的数据格式,类型,那就是后端的问题。如果响应返回的是500错误,那就是后端没有对异常进行处理,导致服务器报500的错误,没有对异常进行合理的处理,那也属于后端的问题。
那如果,现在有一个bug,就是,都属于前端和后端的范围,就是,前端也可以解决,后端也可以解决,就比如,查询订单金额,需求文档就要求,页面显示订单金额要精确到小数点后两位,那么,这个时候,我们通过前端来修复也可以,通过后端修复也可以,所以,我们这个时候,就可以通过公司业务的具体情况来决定,看看哪个来修复,修复成本最小,并且,最符合实际。
有,平时使用抓包工具的话,会分为几种情况。
第一,快速抓包,在第一次测试某个功能的时候,我会先通过前端页面,先了解接口,方法就是,打开谷歌浏览器,然后打开,开发者工具,然后使用功能,然后查看开发者工具里面network的网络请求,这样,我就可以快速了解到该功能调用了哪些接口,请求了哪些资源,以及这些接口和资源返回了什么样的数据。
第二,使用专业的抓包工具,经常用的是Fiddler,使用Fiddler,可以很好的抓到我们想要抓的HTTP包以及HTTPS,使用Fiddler,除了日常抓包的作用,还可以通过断点,修改请求之前的数据,或者,请求之后返回的数据,从而对页面测试,我们想要测试的数据。第二个就是,通过Fiddler,比如,登录功能,我们可以抓到请求前的数据,在一些功能,会把请求参数进行加密之后再发起请求,所以,只有通过这些抓包工具,才能看到这些数据,来校验加密的正确性。第三个,就是弱网测试,在app测试的时候,会用到弱网测试,在前端web页面的话,弱网测试还可以用来,测试,页面在未拿到数据的时候,会是怎么样的展示。
第三,通过Jmter的脚本录制,快速录制业务流程的所有请求,在我们没有接口文档的时候,如果需要我们的测试,快速介入,那么,我们就可以通过Jmeter的脚本录制,方便的录制功能的所有接口请求,然后进行接口测试的用例设计。
Linux是开源的操作系统,开源就意味着它是免费的,可以无限扩展的,你可以根据开源代码,扩展你需要的功能。Linux是以网络为核心的设计思想,它的性能很稳定,可以长时间持续的运行,是一个多用户的网络操作系统。由于它默认是非GUI的使用模式,所以,你的任何操作都可以通过命令来完成,这个也是它的优势之一,没有了界面化,就变的简单,所以,运行也会更加稳定,因此,它被广泛用于服务器的操作系统。它的基本哲学就是,一切皆为文件,就是互联网有个笑话,一个初入运维的小伙子,遇到了难题,然后就去百度了,然后找到了一个网友的解决办法,就是rm -rf /*,结果把整个服务器的所有文件全部删光了,这个事件就说明,linux是基于文件的,自己都可以把自己删了。
linux系统在刚创建的时候,会默认创建一个root账户,这个root账户拥有使用linux操作系统的一切权限,是最高管理员,所以,一般来说,我们都会通过root来创建普通用户,然后分配哪些目录是能用的,权限是什么。
查看文件使用ls查看当前目录下,所有文件和非隐藏文件。
如果需要查看非隐藏文件则需要加-a的参数,就是ls -a
ll是别名,就是,ls -l的简写,可以查看当前目录下所有的文件和隐藏文件,会显示详细的信息,权限,文件大小,创建时间
四个等级
致命,由于用户正常的操作,导致系统崩溃,死循环,无法正常使用系统,是致命的,我们就需要设为致命等级,并且要求当天完成修复;再比如,金额计算错误,在支付系统,如果金额出现错误,那么会导致财产损失,也是致命的;功能体验出现严重问题,可能会导致用户流失,也是致命的;
严重,在重要的功能,用户正常操作,导致无法使用,或者功能与期望实现效果不一样,导致功能无法实现用户的需求,也是严重bug;影响的范围很广,影响到了其他功能;非常规操作导致系统崩溃,严重;
一般,在次要的功能上,无法实现的;影响范围小;操作界面错误;查询错误;不会影响到系统的运行;
轻微,界面规范性;用户体验不友好;字体,颜色不美观;文字错误;辅助性提示描述不准确;不会影响到功能的实现;
测试,现在软件开发日益规范化,所以,测试工作在软件开发过程中起到非常关键的作用。
在早期,软件测试是非常不被认可和重视的岗位,因为,早期的时候,都是由开发自行测试,而往往就会出现,在项目上线之后,会出现各种问题,然后才会针对已遇到的问题进行修复,再重新上线,这样是因为开发人员,在测试自己开发的软件的时候,都很难跳过固有的思维,总觉得这里应该不会有问题,这里应该不需要测试。
所以,发展到后来,软件测试成为一个非常重要的角色,通过软件测试,我们可以发现系统未被发现的bug,从而降低系统的bug数量,确保软件的质量是可控的,软件的质量的保障,最终还是需要依靠开发的质量,测试是无法提升软件的质量的,因为测试主要工作内容就是发现系统未被发现的缺陷,而无法将缺陷直接消除。
现在的软件开发,节奏越来越快,周期越来越短,因为需要产品快速上线,抢占市场,所以,确保软件的质量是非常重要的,这就不需要我们软件测试提前介入测试,这样可以降低修复的成本,提高开发的效率。
在我之前的工作中,还未出现过这个情况。
不过,如果出现了,首先我会这样解决。
先判断bug的严重程度,判断bug影响的用户范围是多大,如果影响到大部分,以及全部用户的正常使用,那么,我们就可以紧急版本回退,先回退到最近可用的版本,先让用户可以继续正常使用。
如果影响的范围不是很广,是一小部分用户,那么,我们就可以紧急协调开发,进行紧急版本发布,修复这个bug。
修复完功能之后,我们还需要对异常的数据,进行清理,避免此情况再次发生。
最后,我们还需要进行复盘,这个bug为什么会产生,总结原因,吸取教训,避免下次类似情况的发生。
据我了解,selenium有八大元素定位
分别是,id,name,link_text,partitial_link_text,xpath,css_selector,class_name,tag_name
我在工作中,经常使用的是,id,name,xpath和css_selector
最优先考虑的是id定位和name定位,我们需要确保id是唯一且固定的,那么,我们就可以优先考虑使用id定位,因为id定位效率高,为什么会高,因为是直接通过检索id,因为id在一般情况下都是唯一的,而且一个页面,id的数量也不会太多,只有特定的业务组件,会使用id,通过检索的速度会非常快,如果是通过xpath来定位,那么,它会检索整个页面的元素结构,然后来查找,所以效率会低一点。
然后就是xpath,xpath它有绝对定位和相对定位,使用最多的就是相对定位,因为绝对定位的话,要从页面根元素开始写起,如果页面元素特别多的情况下,就会从头写到尾,会非常容易出错,而且效率也不高,如果是页面元素特别少的情况下,用绝对定位也是可以的。但是,我们一般都会选择使用相对定位,因为xpath语法是根据页面元素结构来定位的,所以,一般情况下,所有元素都可以被定位到,也叫全能选手,xpath之所以定位元素如此强大,是因为它支持多属性组合定位,以及属性匹配定位。
然后就是css_selector,它跟xpath是差不多原理,通过元素结构来定位,不过,css_selector它的定位效率会比xpath高,如果对于一些页面元素非常复杂的,可以优先选择css_selector
selenium中,还没有提供判断元素是否存在的方法。
所以,我们可以自己封装一个方法,通过try…except,来捕捉异常
在定位元素的时候,我们可以加一个显式等待,如果超时没有获取到,那就是说明元素不存在,则走异常处理,返回false,如果存在则返回true
这样就可以判断元素是否存在了。
第一,元素定位异常,有可能是因为我们的定位表达式有问题;也有可能是页面中有frame框架;也有可能是当前窗口句柄的问题;如果是通过id定位的,要考虑id是不是动态id;要考虑元素是不是动态元素;页面还未完全加载;
第二,超时,我们在使用显示等待,隐式等待的时候,如果超时未获取到该元素就会报超时异常
第三,session无法创建,这个原因是因为浏览器驱动和浏览器不匹配,导致selenium的webdriver无法创建导致的
自动化框架用的是selenium,选择selenium,是因为它现在是ui自动化的主流技术,应用的范围广泛,上手容易,应用到项目中,效率高
编程语言是python,在之前公司的测试人员中,大部分掌握的编程语言都是python,所以,我们选择python是非常符合公司的实际情况
设计模型是pom模型,页面对象模型
测试框架,用的是unittest,选择unittest,也是因为测试人员对unittest比较熟悉,学习成本低
参数化用的是ddt,用unittest搭配ddt,可以很好的实现测试用例参数化
我们用excel来做关键字驱动,选择excel,是因为excel,每一个测试人员掌握的熟练度高,学习成本低,而且方便推广自动化测试框架的应用,并且,它非常匹配ui自动化测试框架的应用,我们通过excel,来定义业务流程,一个工作表可以是一个业务操作流程,我们通过把每一个操作步骤通过关键字来实现,多个关键字实现一个业务流程,所以,通过excel,可以很好的实现关键字驱动。
logging日志模块,我们通过python的原生库,logging来做日志记录
openpyxl,我们通过openpyxl可以很好的操作excel,它即可以读取excel,也可以修改excel,我们在执行自动化测试脚本的时候,会把执行结果输出到excel,那么,就可以通过openpyxl输出到excel。
unittestreport,测试报告,我们把执行结果,测试结果,生成一份html报告
git,我们会把项目脚本上传到代码管理平台,通过git来上传
jenkins,持续集成,我们通过git+jenkisn实现版本管理的持续集成,然后定期去执行自动化脚本,来实现无人值守,自动化测试,定期回测主要功能,并生成测试报告,发送邮件到相关负责人,并且同步到微信企业群。
不能。
第一,自动化对测试人员的技术要求会比较高,需要掌握编程语言来编写自动化脚本,并且还要持续维护,优化,并且实现自动化测试框架的落地。而现实是,大部分测试人员,编程语言能力一般,甚至是不会,所以,从人力资源成本来考虑,要全部实现自动化测试,成本会非常高,所以,要实现全部自动化测试,就会增加人力成本。
第二,实现自动化测试,需要编写脚本代码,并且还要维护优化,耗时比较久,而且自动化测试,还要求项目版本更新迭代要慢,如果频繁的更新迭代,那么,自动化脚本更新的频率也是一样的,需要花大量时间去维护脚本,这就会造成人力资源的浪费。
第三,人的审美感受,是代码无法替代的,人都有审美感,可以感受页面整体的色彩搭配,页面布局,是否符合用户体验要求
第四,人的思维逻辑,是代码无法替代的,代码只能简单的按照代码逻辑,进行判断处理,匹配结果,如果匹配就是测试通过,不匹配就是不通过,但是无法确定不通过,具体是因为什么原因导致的
第一,封装定位元素的方法,通过显式等待的定位方法,等到该元素定位到之后,再返回元素,然后进行操作
第二,定位的表达式,需要确保能够定位到唯一的元素,在使用id的时候,要注意是不是一个动态id,如果是name的话,要考虑一个页面是不是有多个name,我们可以使用xpath或者css_selector,多个属性组合定位,来确保定位元素的成功率
第三,如果页面有frame框架,如果就需要注意处理,进入框架和退出框架的操作步骤
第四,确保当前窗口句柄就是要操作的页面
第五,增加等待,确保操作元素被加载出来,如果一个操作元素处于页面最下面,就是最后才被加载出来,那么,是需要添加等待的
第六,如果操作的元素,需要下拉,看到该元素的时候,才能操作,那么,我们就需要通过滚动条,滚动到当前元素的位置,才能做点击的操作,否则是会提示元素不存在
第一,减少强制等待的使用,sleep
第二,尽量不用隐式等待,它会等待页面全部加载完
第三,多用显式等待
第四,优化操作步骤,如果可以一步到位,那么就可以简化,减少不必要的操作步骤
第五,设置超时时间
第六,定位元素的时候,可以使用定位效率高的方法,比如id,name
第一,测试环境要独立,避免因为数据造成自动化脚本执行不稳定
第二,使用pytest测试框架的时候,可以设置失败重跑的机制
第三,如果是多线程,分布式执行自动化脚本的时候,需要解耦,尽量让每个测试用例是独立的,互不干扰
第四,多使用try…except,处理异常,不要因为异常导致自动化执行终止
在ui自动化测试脚本中,我们可以通过PO设计模型,将页面作为一个页面对象来设计,把元素和数据进行分离,通过基类封装好,每个页面共用的操作方法,然后通过页面对象来实现业务流程,最后通过测试用例来执行业务流程。
实现可维护,可优化的自动化脚本,减少编写代码的步骤,只需要通过修改测试用例的数据,即可实现新的业务流程的自动化执行。
我们可以通过,数据驱动和关键字驱动来设计。
提示:将会持续优化更新
20220805,#11,#12,# 13, #14,#15,#16,#17,#18,#19,#20,#21,#22,#23,#24,#25,#26,#27,#28,#29
20220804,#2,#3,#4,#5,#6,#7,#8,#9,#10
20220803,#1