快捷搜索:

软件测试面试中有哪些一定会问到的问题w88官方

作者: w88官方网站手机版  发布:2019-04-18

软件测试面试官会如何刁难你及都会问到什么问题? 我剖析下面试不同的岗位问的问题,不同岗位问的肯定是不一样的,那么我先从初级开始 分为三个等级,就是初级怎么去面试,中级岗位怎么去面试,还有高级的怎么去面试。 还有就是测试经理或者领导一般想是怎么衡量你是什么级别的?他的衡量标准是什么? 初级测试人员通常面试官上来先会问她们什么?首先当然是自我介绍,这个环节是必不可少的,因为每个面试官都需要通过你用最快的时间去了解你这个人,了解你以前干过什么项目,做过几年,有没有项目经验,通过你一个简短的自我介绍,可以对你有一个50%的了解,还有可能你这一个自我介绍,面试官的心里就已经决定了要不要你了。 因为就一个短短的自我介绍,面试官已经心里有数,至少有了50%的数了,那么它还需要继续的去深挖一下,你的能力到底有多少,到底能不能做一个简单的功能测试,他需要问一些简单的问题,比如说有没有编写过测试用例,你编写测试用例的时候用到什么方法?还有就是你上一家公司的测试流程是什么样子的?他需要了解你上一家工作的事流程,为什么? 因为他需要跟他们自己这家公司现在的流程进行一个比较,需要知道你们上一家公司的工作流程跟他们现在的工作流程是不是一样的,如果不一样,那差距到底大不大? 了解下你们公司的流程是不是正规的?是不是一个比较完善的一个流程?他都需要了解。 可能不善于总结的测试人员有可能就说不太好。对吧! 那测试流程应该是什么样子?我现在简单的给大家说一下,一个标准的测试流程应该是什么样的! 首先呢,一家正规的公司,它们的测试流程应该是: 第一件事情拿到需求文档 首先用户把自己想要的东西说出来之后,由产品人员来记录,并且转化成一个需求文档。 那么咱们测试人员跟开发人员需要在产品人员拿出需求文档之后,进行一个需求的评审, 需要了解他们用户到底想要一个什么样的功能,想要一个什么的软件。 在评审的过程当中需要对需求进行一个测试,测试什么?测试他需求文档中有没有二义性的内容,有没有描述不准确,或者是理解不清楚的一些东西,包括你在参加这个需求文档这个会议的期间,产品在讲需求的过程当中,你有没有觉得这个功能有没有必要,或者可以删简,可以留到第二个版本在做。这就是第一件事情,需求评审。 那么需求评审通过之后,咱们测试人员需要由测试的组长或经理来编写一份测试的计划,这个计划里边包含的内容会非常的多,这个具体包含什么这里就不细说了,以后有机会的时候再给大家细讲测试计划,一般情况下都是20多页的A4纸,打印出来之后是非常厚的一摞,里边简单的会有概要设计,详细设计,参考文档还有这个背景,还有咱们人员分工时间安排里程碑,还有风险评估等等,这些都是写在咱们的测试计划里面的。 那测试计划写完之后,咱们会在把所有的测试人员召集到一起开会,对测试计划进行一个评审。 评审测试计划里边什么内容安排的是不是合理,时间的安排是不是真的够用,包括里边的风险是不是规避掉了,还有咱们的测试机的准备,系统的准备,还有测试的一些方式方法,时间的一些这个限制,都是需要写在里边,然后咱们评审通过之后。 咱们再去干什么事情?就是编写测试用例。在测试计划里边会给每一个人进行人员分工,可能张三负责注册模块,李四负责登录模块,王五赵六负责会员中心模块,他们每个人都有自己的负责的那一块功能,他们需要对自己的负责那一块编写测试用例,人员分工安排下去之后,每人编辑好测试用例,那么他们开始怎么样? 开始测试用例的评审 评审他有没有遗漏的点,评审通过之后开始执行测试用例,然后第一轮测试迭代,第二轮测试迭代第三轮测试迭代,直到它验收测试,然后发布上线编写咱们的测试报告,整个这一套流程结束,每一轮测试结束之后,都需要给出一个阶段性的测试报告,第一轮测试结束了,需要给一份测试报告,第二轮结束还是要给测试报告,最后总体的结束了,需要汇总,把所有的bug已解决的未解决的,包括遗留的都需要一个汇总,还有冒烟测试这个事情,我为什么没有说,因为冒烟测试有的公司把它直接进入到了系统测试 什么是冒烟测试?冒烟测试是为了验证这个系统是不是满足系统测试的要求,需要在单元集成系统验收的集成与系统测试之间进行的。冒烟测试通常只需要一天或者半天的时间来完成,它只需要去测一下,简单的去跑一下主要的流程,确保每一个页面能够正确地跳转,每一个正常的功能能够正常的点击就足够了,这就是冒烟测试。这也是面试官比较希望听到你一个完美的回答的一个问题,也是能够衡量出你这个人到底有没有真正工作过的一个问题。 那么还有就是它需要了解到你上一家公司你主要负责的是哪一块业务,那么我建议大家,如果你们去面试的时候,千万不要说你负责注册登录模块这些 为什么? 因为没有什么技术挑战,什么样的人领导才会分配这样的任务呢,那就是实习生去做,领导绝对不会把这个模块分配给一个技术能力强的人去测。 所以说如果你说你在上一家公司,你就做这个注册登录模块测试的话,那我只能说你们领导不太看好你。你应该要说什么?我是负责什么下单流程的,或者负责支付流程的,或者是负责这个退款流程,这些流程都是比较有逻辑性的内容。这些东西会涉及到的前后台,包括审核这个环节都会有。比如你去发布一件商品,需要后台审核通过才能发布,需要涉及到数据库,所以说需要涉及到后台,需要涉及到前台的展示,这些都涉及到很多的逻辑测试。这样的工作是比较有技术含量的。 那还有些面试官会问什么? 你认为你在测试过程中遇到了一个比较逻辑性最强的一个bug是什么? 这个东西就需要你们去想想,曾经你们在测的时候遇到了一个逻辑性特别强的bug呢 这个问题问的目的是什么? 问的目的是了解你到底有没有真正的测试过? 还有就是有的面试官会故意的说错一些东西,然后看你的反应,通过这些都能了解你到底会不会,所以想验证一个人到底会不会使用一个工具,不一定非得要考他。 再往深入一点,他会问你有没有性能测试方面的基础?功能测试这方面,实际上我觉得主要考验人的就是逻辑思维能力,还有你的细心程度能力 初级功能测试这一块,面试官着重要看的是你是不是一个真正细心,而且业务逻辑思维能力强的人,如果强是绝对没有问题的 初级这块还需要分清楚黑盒白盒跟灰盒的区别是什么?包括缺陷的严重级别,提交缺陷的流程,包括缺陷管理工具,一个缺陷的生命周期是什么?还有你会不会简单Linux指令都会问到 还有就是协议这一块,什么是协议?就比如七层协议,还有四层协议都要有一个概念,tcp ip协议,OSI 协议要一定的了解,这都是属于一个软件行业的一些基础的知识点 面试官还会问,测试的方法有哪些,黑盒测试的范围有哪些? 如果能说出来十条以上的,我觉得面试官对你会比较有兴趣,如果连五条都说不出来基本会pass掉的,要是连十个测试范围的方法都不知道的话,绝对是一个不合格的测试工程师。 软件测试初级有专门问初级的题中级有专门问中级的题,高级有专门高级的题,初级主要针对于围绕着它的功能测试这一块的方式方法,并且测试用例的方式方法,还有就是它对测试流程的掌握,编写测试报告,都会着重的去问这些,要是问什么Java,selenium什么的都没有意义,答上来那就不是初级了,所以一般情况也不会去问,除非面试官有毛病。 那么针对于中级的话,一般都会把功能问一遍,面试一个中级测试工程师,着重会问性能自动化跟接口,这是三大重中之重,还有数据库。数据库都是其次的,为什么是其次?因为数据库在大学里有讲,基本上上过大学的都会数据库,都会懂得增删改查,再往深入说,就是表连接子查询的问题了,实际工作当中用的也不多。因为我工作这么多年了,在工作当中用到表连接子查询的机会并不是很多。当然这是衡量一个人的技术水平的一个标杆, 着重要问的是性能自动化,性能的话主要问loadrunner或者jmeter,不要求你全会,最起码达到熟练,因为有很多人会在简历里这样写,明明只是一个了解,他非要写掌握,明明只是一个掌握,他给自己写个精通,这样面试官看到就要考验你,你到底是不是达到一个精通的标准,或者是一个掌握的标准,但是我建议在简历里尽量少出现了解这个字眼,在我看来写了解的就是等于不会,所以尽量不要写了解,如果非要做个比例我可以说我了解东西多了去,什么宇宙的来历啊什么的都了解,是吧!根本没有意义, 所以建议以后简历里头写精通或者掌握、熟悉都可以,千万不要写了解,性能基本会问你们平时要关注哪些指标,怎么做性能测试,这些指标说明什么问题?分别代表着什么意思,怎么叫合格?怎么叫不合格,你得跟我说出个123来,否则的话你就是一个初级。 这些都是面试官会问的问题,jmeter都会问到什么是断言,断言干嘛使的,都有哪些断言,怎么连接APP,假如我要测试一个手机的性能测试的时候,我要怎么设置,包括它这个聚合报告里边每个指标代表什么意思?它的塑型图,塑型结果怎么看,怎么看它的请求,怎么看它的返回值,每个请求代表什么意思?什么是post,什么是get?这些都会。还有接口测试怎么测?首先你要做性能,你必须要先会接口,你不会接口你就没法做性能测试。 像自动化这块问的就比较多了,会问你QTP和selenium的区别是什么? QTP能干嘛selenium呢?QTP能够测试cs跟BS架构,selenium只能针对于BS架构。 那么QTP用什么语言?用VBS语言,那selenium又用什么语言?python或者Java都可以 这些都是中级应该会的,如果我阐述的这些问题你都会了那么你就具备中级的测试能力了 如果我问的这些问题确实把你们难住了,这答案应该是什么?怎么答?如果你自己现在已经开始懵 了,那你需要好好巩固了 还有高级面试的部分,高级部分还需要你会写Java会写Python,需要能解决一些问题,遇到一些疑难杂症的时候,别人解决不了,你能解决,脚本录不了的地方你能录,不用录的方法能写的出来。这就是高级工程师,高级还能干嘛?不仅能看得懂代码,看得懂脚本,还能找到问题的原因,知道这个bug是怎么出现的,是由于什么导致这个bug出现的,怎么去解决它!虽然不用自己去解决,但是告诉开发人员这个问题是由于什么原因导致的,你需要把接口的哪一个代码改掉,把这个参数给换了才能解决这个问题,你需要知道这个问题是怎么出现的,包括解决的方案,并且能够把控整个项目的进度,包括它的时间节点,包括他的所有的人员分工跟安排, 你才能够敢说你自己是一个高级测试工程师 以上就是我总结的现在公司面试都会问到的问题,包括后续你有什么职业规划,或者为什么从上家公司离职,又或者面试官问你你有什么需要问我的吗?这时候一定要问点有水平的问题!不要让面试官觉得你很low,至于该问什么不该问什么在这我就不细说了,如果还是不知道怎么说可以给我留言,看到会给予回答~至于教学资料和学习思路可以在(152 015 953)群文件夹里下载查看即可

w88官方网站手机版 1

编写目的(此文非原创,只是忘了当初是谁写的了~)

前言:与一些刚入行的测试人员接触时,发现他们对测试的认识不够,总是认为测试只是一个点、点的过程,认为测试也总是在界面上点,点的过程,我只想说“测试看似简单,但实则深不可测”,接下来就讲讲测试过程主要是做什么?

主要明确测试团队在整个项目各阶段中的职责,并对测试团队的组织架构、职能划分进行说明,对日后各部门间配合及组内工作的正常开展起到规范的指导作用。(注:该文档在测试流程及规范部分主要针对测试团队来撰写,其他团队的职责仅略微描述。)

测试主要做什么?这完全都体现在测试流程中,同时测试流程是面试问题中出现频率最高的,这不仅是因为测试流程很重要,而是在面试过程中这短短的半小时到一个小时的时间,通过测试流程就可以判断出应聘者是否合适,故在测试流程中包含了测试工作的核心内容 ,例如需求分析,测试用例的设计,测试执行,缺陷等重要的过程。下面就以迭代测试为例,给大家画下测试流程图:

各角色职责

1.需求分析

一般在上一个迭代测试即将完成之时,下一个迭代的需求文档就已经发出来,放到配置管理平台,便于测试和开发自取,那这个时候一般测试人员就会自动去取需求文档,开始做需求分析,需求分析主要是分析接下来的需求,从功能交互,测试要点等方面入手分析。

需求分析完成之后,就会开始需求评审,如果对需求评审不了解的,可以查看上一篇文章。

⦁ 测试经理

2.编写测试用例

需求评审完成之后,对测试而言,应该还需要编写测试计划和测试方案,一般测试计划是由测试主管编写,测试方案是高级测试工程师编写,故有些测试人员并不会要求编写,但是测试用例却是每个测试人员都需求编写的,一般测试用例我们主要用到的都是黑盒用例设计方法,如等价类分析法,边界值分析法,因果图,判定表,场景法,状态迁移,错误推测法等等,根据自己熟悉的方法和需求文档来设计测试用例。

测试用例编写完成后,测试人员就要开始用例评审,用例评审与需求评审的评审流程相同,只是发起人和评审内容,评审重点不同。

1)负责团队内部管理工作,各部门间协调工作;协助团队内部解决测试技术问题;

3.测试执行

一般用例评审完成之后,就要开始等待开发转测。

转测成功后,测试这边就要开始搭建测试环境,然后进行冒烟测试,冒烟测试通过后才开始进入正式测试执行阶段。

冒烟测试的重点:

1.原来版本的主要功能

2.新需求的主要功能主要流程

2)根据每次即将上线的版本内容制定测试范围、分配测试任务;

4.提交缺陷

在正式测试阶段,测试人员是根据已经编写好的测试用例执行程序,当执行程序的实际结果与测试用例的预期结果不符时,就需要在缺陷管理工具上提交bug单,bug单会根据bug处理流程进行处理。

3)制定测试方案并推进实施加以改进,改善产品体验;

5.回归测试

当开发人员修改了大部分bug时,开发人员会再次合版,联调,转测,这时测试人员就会进入到回归测试阶段。

回归测试的重点:

1.检查bug单上的缺陷是否被修复OK

2.检查在修改bug的时候是否引入新的bug

4)制定质量管理体系标准,严格保证并管控产品质量;

6.部署上线/交付

当测试执行阶段根据测试标准中的出口准则,结束测试活动,如果测试结果是OK的,这时运维人员就可以开始部署上线,或者进行版本交付。

上面的测试流程是基于有需求文档的一个完整测试流程,如果公司没有需求文档,则测试流程就会在上面的基础上有所删减。

w88官方网站手机版 2

5)打造高效的测试团队,培养人才梯队,制订团队发展计划与培训机制,不断学习新技术;

6)优秀的执行力,面对挑战,能快速决策分析,调动资源集中突破;

7)负责测试人员招聘、组织架构划分、人员的绩效考核等。

⦁ 测试接口人

1)根据测试经理指派的任务,根据各组别职能协调小组内成员共同完成测试任务;

2)编写测试用例、测试计划、测试方案、测试报告并能指导测试工程师完成工作;

3)与产品、研发、运维团队进行有效的沟通,并负责组织测试用例评审工作;

4)验收各阶段测试工作,保质、保量、按时完成小组内的测试任务;

5)负责小组内的团队建设,探索并提升组内所需新技术,提高组内技术实力等。

测试开发工程师

⦁ 根据项目组需要,能够独立完成测试框架开发工作及所需工具;

⦁ 熟悉mock测试工具,完成mock测试开发;

⦁ 精通web端及客户端APP的自动化测试工具,如selenium、monkeyrunner等,能够熟练使用其做自动化测试;

⦁ 掌握持续交付理念、快速接受持续交付中自动化测试部分;

⦁ 掌握全业务流程,可以分析并提取出业务框架并实施开发;

⦁ 指导其他自动化测试人员,并通过组内培训分享自动化测试理念及方法,提升组内技术水平等。

性能自动化测试工程师

⦁ 有扎实的功能测试基础,能够根据独立编写性能测试方案及性能测试报告;

⦁ 熟练掌握LoadRunner、Jmeter等工具的使用及原理;

⦁ 与客户一起制定并分析性能指标、编写性能测试方案、定位性能瓶颈并找出解决方案;

⦁ 掌握linux命令、Sqlserver、Qracle、Mysql等数据库

⦁ 熟悉Apache、windows及linux平台;

⦁ 编写性能测试脚本并调试。

功能测试工程师

⦁ 服从上级安排,并通过指导能够胜任测试任务;

⦁ 参与需求评审,并对产品需求提出各方面建议及意见;

⦁ 按照需求文档设计测试用例、编写测试用例并严格按照测试计划及用例执行;

⦁ 参与用例内部评审及外部评审;

⦁ 按规定格式提交有效的软件bug,并对软件bug周期进行跟踪处理。

⦁ 测试流程及规范

⦁ 测试流程

1)计划与设计阶段

2)实施阶段

3)测试总结阶段

⦁ 计划与设计阶段

⦁ 项目立项

⦁ 项目立项主要是阐述项目背景、内容及意义,确定项目相关负责人、评估项目预算等;

⦁ 测试参与人员:测试经理;

⦁ 其他部门参与人员:研发总监、产品总监、产品经理等与项目相关的领导、高层。

⦁ 需求评审

⦁ 产品部门组织召开需求评审会议,以产品需求文档、原型设计、UI为输出条件;

⦁ 会议内容:测试团队对需求文档存在异议/需求不完整/不清晰的地方提出问题,相关人员进行解答;

⦁ 会议结束的标准:所有人员达成一致,对需求无异议,需求确定;

⦁ 测试参与人员:测试经理、模块测试负责人;

⦁ 其他部门参与人员:研发总监、模块研发负责人、产品总监、产品经理、UI设计等;

注:

⦁ 需求评审会议召开之前,产品需将产品需求文档、原型及UI设计图提前发给各个团队,以便测试团队预留出熟悉及理解需求的时间;

⦁ 测试团队参与人员由测试经理指定,包含测试模块负责人、测试设计人员、质量保证人员等。

⦁ 测试计划

⦁ 制定依据:需求文档、原型设计、UI设计、研发计划、概要设计及详细设计文档;

⦁ 内容:包含测试范围、测试环境、测试方法及策略、资源分配及进度安排、风险预估等;

⦁ 评审:研发、测试人员需对测试计划初稿进行评审,确认测试的侧重点。

⦁ 评审目的:确保测试计划的正确性、全面性、可行性。评审后完善测试计划,并形成终稿;

⦁ 测试参与人员:测试全体参加。

⦁ 用例设计

⦁ 设计依据:需求文档、原型设计、UI设计、研发概要设计及详细设计文档;

⦁ 测试用例设计

1)需求测试分析、分解需求功能模块、提取测试点后,根据以上文档采用边界值、等价类划分等方法设计测试用例 ;

2)包含测试用例的要素:

首页签:测试用例目录及链接、用例修订日期及修正模块等信息说明;上半部分:项目名称、版本号、编写人、编写时间、功能模块要点、联调测试要点(涉及哪些客户端的交互联调测试);下半部分:用例ID、优先级、功能模块、用例名称、前置条件、输入数据、操作步骤、预期结果、实际结果、备注(关注点、bug号等信息);

⦁ 测试参与人员:模块负责人、用例设计人员及用例执行人员。

⦁ 用例评审

⦁ 用例评审及标准:确保测试用例的全面性、需求覆盖率达到100%;

⦁ 测试参与人员:测试经理、模块负责人、用例设计人员及用例执行人员。

⦁ 测试实施阶段

⦁ 测试准备

⦁ 测试环境的准备:硬件环境、软件环境、网络环境、历史数据环境;可靠且可控的测试环境有利于bug重现、减少环境的变动对测试工作带来的不利影响;

⦁ 测试文档准备:产品需求文档、原型图、UI设计图、测试计划、测试方案、测试用例;

⦁ 测试数据准备:老数据与新数据的准备(数据迁移)、带有历史数据记录的数据(与程序判断有关)、与测试方法及策略有关的数据准备(安全测试、);

⦁ 测试人员准备:根据测试方法及策略分配测试人员,合理安排进度。

⦁ 单元测试

⦁ 研发在编写代码后需进行单元测试且达到一定的覆盖率标准,才可交付给测试人员。

⦁ 冒烟测试

⦁ 单元测试后交付测试,测试人员进行冒烟测试,确保后续正式的测试工作可顺利进展;

⦁ 冒烟测试通过标准:实现所有主要功能,且无一级、二级bug,三级bug可根据产品迭代情况适当制定相应标准;

⦁ 冒烟测试用例:确定主要模块的主要功能,根据需求文档提取测试用例功能点并编写;

⦁ 冒烟测试执行人员:模块测试负责人员。

⦁ 功能细则测试

⦁ 业务功能细则测试:当冒烟测试通过后,进入正式功能测试;

⦁ 功能测试通过标准:需求覆盖度达到100%,且测试用例的粒度达到单个细小模块的校验,所有用例被严格执行且fix掉所有bug(或最终上线前产品、研发及测试评估优先级为三、四级bug是否全部fix);

⦁ 功能测试执行:模块测试负责人员。

⦁ 集成测试

⦁ 集成测试是在单元测试基础上,对多模块组装联合起来的接口进行测试;

⦁ 集成测试细则:考虑各模块连接起来时,穿越接口的数据是否丢失、一个模块的功能是否影响另外一个模块的功能、子模块组装后是否满足父功能等;

⦁ 集成测试通过标准:所有集成测试用例被严格执行,且满足集成测试接口上的需求;

⦁ 集成测试执行人员:模块测试负责人员。

⦁ 系统测试

⦁ 系统测试是在集成测试基础上进行的测试,依赖于产品需求说明书中已经确定好的系统外设、硬件、网络等组成因素;

⦁ 系统测试分类:恢复性测试、安全性测试、压力测试等;

⦁ 系统测试通过标准:所有系统测试用例被严格执行,且满足产品需求及设计说明书;

⦁ 系统测试执行人员:模块测试负责人员。

⦁ 验收测试

⦁ 验收测试是软件正式上线前的最后一步测试;

⦁ 验收测试分类:正式测试、非正式测试(Alpha 测试)、Beta 测试;正式测试由测试人员与用户共同组成小组或完全由用户来组织验收测试;非正式测试多数由最终用户执行;Beta测试

⦁ 验收测试通过标准:产品最终需满足需求设计说明书的内容及对硬件、软件相关的规定;最终的体验以及功能、性能等方面用户可接受;无一级、二级bug(三级bug接受程度由用户或产品方与我们共同评估);

⦁ 验收测试执行人员:测试人员、研发人员、产品、最终用户。

⦁ 回归测试

⦁ 需注意:回归测试贯穿于整个开发周期的各个阶段;

⦁ 修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的;

⦁ 回归策略:用例库维护、自动化脚本回归、手工测试辅助回归;

⦁ 在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归;

⦁ 回归测试执行人员:测试全体

注意:以上事实流程仅限于有足够的测试时间方可全方位实施,根据敏捷迭代的特性,在实施的各阶段需因环境变化而制定临时测试实施策略。具体详见敏捷迭代过程中各阶段的测试策略及计划报告。

⦁ 测试总结阶段

⦁ 测试报告

⦁ 把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础;

⦁ 测试报告内容要素:测试范围、测试方法、测试工具、测试环境、测试结果与缺陷统计与分析、测试结论与建议等;

⦁ 每个测试阶段或上线前用例及各环节执行完毕后都需要提供测试报告;

⦁ 测试报告撰写人:负责各阶段的测试人

⦁ 上线前review

⦁ 上线前产品、研发、测试共同review上线前需求完成度、用例覆盖度是否满足本次上线的要求,以及存在哪些风险点;

⦁ 上线前的标准是所有覆盖需求的用例执行达到100%,且无严重等级的bug挂起;

⦁ 上线前review执行人员:测试经理携测试全体

⦁ 测试归档

⦁ 测试归档是在测试验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种标准文档进行归类,存档;

⦁ 涉及的文档:测试计划、测试用例、测试阶段性报告、测试总结报告;产品迭代需求说明、设计文档等,最好归类为一次版本上线的文件夹,日后有可追溯性;

⦁ 测试归档执行人员:测试组长/负责人。

⦁ 上线后总结

⦁ 上线后测试组内需对上线成功或经过一段时间线上反馈的问题做出总结;

⦁ 总结内容:对整个研发过程改进的建议、提高测试效率的方法、若出现问题需追溯出根本原因、测试过程出现问题的改进方法、对测试过程中好的一面予以肯定并继续推行等;

⦁ 上线后总结执行人员:测试组长携全体测试人员。

⦁ 缺陷跟踪

⦁ 测试过程中的缺陷跟踪及处理

⦁ Bug处理流程图

⦁ Bug严重等级定义

⦁ 一级: 系统“挂起”或“崩溃”的错误,使得整个测试工作无法继续进行,如:程序死机、死循环、非法退出、数据库死锁、程序无法登录等;

⦁ 二级: 软件功能未按产品需求文档规定的实现,导致功能报错,其他模块测试工作无法进行,如:功能不符、接口错误等;

⦁ 三级: 一般性错误:如界面UI不符/错误、错误未给出弹出框提示等;

⦁ 四级: 轻微bug,如:格式排版、个别文字错误等问题;

⦁ 五级:对软件的改进建议,如:需求说明中未明确但影响用户体验等;

⦁ Bug优先级定义

⦁ Priority 1—严重bug,需立即修复;

⦁ Priority 2—比较严重的bug,根据模块关联性依次修复;

⦁ Priority 3—一般性bug,可在优先级为1和2之后修复;

⦁ Priority 4—轻微性bug,经讨论后可决定是否在下一版修复;

⦁ Priority 5—针对软件改进建议可以修复或不修复,由产品最终决定;

注:Bug严重等级与Bug优先级一一对应,特殊情况可调整映射关系。

⦁ Bug提交规范

Bug提交所含内容如下:

⦁ Bug标题:环境-端名称-模块名称-简要概述Bug;

⦁ 模块路径:首先选择项目端名,其次选择版本号,如图:

⦁ 指派给:输入研发人员名字全拼或名字首字母,下拉框中会显示出研发人员的名字;

⦁ 抄送给:输入抄送人员名字全拼或名字首字母,下拉框中会显示出研发人员的名字,可按需要抄送给相关人;

⦁ 严重程度:Bug严重等级定义;

⦁ 优先级:Bug优先级定义;

⦁ Bug类型:根据Bug定位原因,并选择适当的类型,详见bugfree类型;

⦁ 如何发现:详细阐述bug发现的阶段;

⦁ 操作系统:详细描述操作系统;

⦁ 终端设备:指定某个终端,方便问题重现,准确定位;

⦁ 发现版本号:填写详细版本号;

⦁ 运行环境:阐述bug发现的运行环境;

⦁ 处理状态:bug当前状态;

⦁ 机器配置:描述机器配置;

⦁ 关键词:方便搜索;

⦁ Bug相关:相关联的bug与case;

⦁ 附件:可上传bug截图附件;

⦁ 复现步骤:分为前置条件、复现步骤、预期结果、实际结果、备注(账号密码等相关信息)。

⦁ 市场反馈的Bug跟踪及处理

⦁ Bug处理流程图

详见售后流程图

⦁ 软件发布标准

软件发布需满足以下标准

⦁ 完成发布计划中所有的工作;

⦁ 实现需求定义中所有功能特性;

⦁ 完成所有的测试工作(按测试计划严格执行);

⦁ 严重缺陷都已修复;

⦁ Bug趋势图接近于零,新发现的缺陷;

⦁ 出具完整且权威的测试报告

⦁ 已达到验收标准

软件产品未经测试合格,有严重bug时,不允许发布。

⦁ 争议处理

若针对同一问题研发、测试团队对结论有争议,需项目组成员及产品共同讨论,项目经理给出最终结果,并衡定是否上线。

本文由www.w88985.com发布于w88官方网站手机版,转载请注明出处:软件测试面试中有哪些一定会问到的问题w88官方

关键词: www.w88985.c