最新15面试提问整理1.docx
- 文档编号:24845198
- 上传时间:2023-06-02
- 格式:DOCX
- 页数:14
- 大小:74.85KB
最新15面试提问整理1.docx
《最新15面试提问整理1.docx》由会员分享,可在线阅读,更多相关《最新15面试提问整理1.docx(14页珍藏版)》请在冰豆网上搜索。
最新15面试提问整理1
15.面试提问整理
(1)
1.请描述一下你们公司的测试流程
需求澄清会议→测试计划、方案及其评审→测试用例及其评审→测试执行、缺陷跟踪→测试结束出报告
2.测试计划是谁编写的
组长/测试经理
3.测试计划主要内容有哪些
项目概述、测试范围、人员分配、测试策略、进度、风险……
4.测试计划评审人需要哪些
项目经理和测试组全体
5.什么叫里程碑
就是项目或版本过程中的各个时间或任务节点,比如版本发布、需求定稿等等
6.什么是版本计划
针对一个升级版本做的计划,内容包括版本范围、进度安排、人员分配、风险等
7.测试计划的编写依据有哪些
需求规格设明书、项目计划……可能参考到的还有需求分析表、概要设计
8.项目进度和测试计划不一致怎么处理
根据实际情况修改计划
9.编写测试计划大概需要多次时间
1-3天(一周内随便说吧)
10.你们公司是什么阶段介入软件测试的
从需求分析开始,测试人员就介入了,开发和测试人员同时进行需求分析。
从SE写出新需求的概要设计开始,开发和测试同时对FRS和概要设计进行需求澄清会议,然后开发人员写详细设计,测试人员写测试方案,开发人员编码,测试人员写用例,开发人员提交版本,测试人员进行测试。
11.你们公司开发和测试人员比例是多少
3:
1
12.你们有独立的测试部门吗?
有/没有,我们都在同一个项目中,项目经理管理我们,我们只有一个测试组长。
13.开发和测试出现了意见冲突怎么解决
沟通,沟通解决不了的可以将问题升级。
14.测试需求分析是谁做的
除新员工外的全体测试人员,新员工也参与,但不会分配任务和对需求分析负责。
15.需求阶段需要出哪些文档
测试需求分析表、概要设计、测试计划等……
16.测试的依据是什么
需求,归根结底就是需求。
17.什么是隐形需求
就是需求中没有明确要求,但是按照约定俗成的规则或日常习惯必须满足的需求。
就好像问:
你有XXX的电话号码吗?
18.项目中碰到需求的问题,能够直接和客户沟通吗?
能,我在项目组中是对外接口人,我可以直接和客户方的代表开会进行沟通。
/不能,我们需要将问题整理到一起,由测试经理和项目经理作为接口人和客户进行沟通。
/不能,我们的需求是产品线提的,关于需求问题,我们直接找产品线。
19.需求过程中不确定的需求怎么解决
项目组内讨论解决,如果还是得不到解决,需要找用户确认
20.需求文档是谁编写的
客户/产品线
21.怎么进行需求测试
会议讨论评审
22.什么是测试点,测试点包含哪些内容
就是针对功能细分的点,我们写的测试点类似于测试用例的标题,是说什么功能的什么情况。
23.什么是测试方案,什么是测试策略
方案是指导我们要怎么测的问题,里边的主要内容是测试点。
策略是指导我们都要测什么方面,比如要进行功能测试,性能测试,兼容性测试等等,并指出需要依赖什么工具等。
24.测试方案是谁编写的
分给谁谁写,自己写自己负责的部分,一般除了新员工都会写。
25.测试方案包含哪些内容
业务功能的描述,对需求、功能的理解,业务流程图、业务表、测试点等等。
26.测试方案编写的输入条件是什么
需求规格说明书、测试需求分析表
27.请描述一下测试用例需要参考的文档
绝大部分都是参考测试方案,很少量是参考需求文档或其他文档。
28.测试用例设计方法有哪些?
等价类、边界值、场景法、因果图、判定表、错误推测法……
29.测试用例内容有哪些
ID、标题、优先级、前置条件、操作步骤、预期结果等
30.什么是好的测试用例
我觉得不冗余不遗漏的测试用例就是好用例,我也看过理论方面的书,书上说能够发现至今没有发现的缺陷的用例就是好用例,不过我们在设计用例的时候根本不知道我们设计的用例执行结果是什么。
31.测试用例的颗粒度划分
颗粒度大小就是用例的粗细程度,每个项目组的尺度应该有所不同吧。
32.测试用例为什么需要有优先级,有哪一些优先级
因为在不同阶段执行的用例数目是不同的,用例对应的功能的重要程度也是不同的,我们用的是高中低三级
33.你们以前一天能够编写多少测试用例
30条左右吧,没怎么统计过,大概是这个数
34.你们项目一共有多少条测试用例
500-2000,具体项目具体分析,和项目大小、颗粒度大小都有关系。
35.高、中、低先级的测试用例的比例占多少
都差不多只是中的会多于其他两个,差不多3/4/3的比例吧。
36.测试用例需要哪些人来评审
①我们测用例评审是测试组内评审的,因为我们的方案是全体项目组成员(PM、SE、开发和测试)来评审的,并且方案里的测试点写到了测试用例标题的程度,所以我们拿已经全员评审过的测试点来写用例只不过是一个体力活,所以我们的用例评审就不用太多人员来参与了。
②我们是项目组全体来评审的,毕竟测试是保证软件质量的最后一个环节,测试用例是测试执行的依据,所以测试用例十分重要,项目组非常重视用例的评审,希望把漏测的可能降到最低,所以我们的用例是项目组全体会议评审的。
37.一个项目需要写多少测试用例怎么估算
这个在需求分析之后根据测试点来评估的,我们的测试点写的很细,所以测试用例的数目几乎等于测试点的数目
38.测试用例是谁写的
测试人员
39.不能发现bug的测试用例不是好的测试用例吗?
我不这样认为,我觉得在执行之前,每个用例都可能发现缺陷,好的测试用例是一套完整的不冗余、不遗漏的测试用例,是能够被其他测试人员执行的测试用例。
不能因为是否找到BUG来说用例是否好。
40.为什么要进行交叉测试执行
因为自己执行自己设计的用例,会按照设计用例的思路来执行用例,可能会忽略一些偶然或异常的情况,交叉执行可能会发现新的BUG。
当然如果用例已经写的很细,颗粒度很小,输入输出写的很全面,交叉执行的效果都会差不多,因为无论谁来执行,结果都是一样的。
41.测试环境是谁搭建的
我们老大/CMO/测试人员
42.你们测试版本是在哪里去获取的
开发搞定之后提交到SVN上,我们去SVN上取
43.什么叫预测试,预测试是怎么进行的,预测试一般为多长时间
预测试就是开放刚刚开发完成,测试环境刚搭建起来,这时我们要对系统的各种功能能不能跑通,业务流程能不能完成进行测试,就是“冒烟测试”,这就是转测试,我们转测试大概需要一天的时间。
44.测试准入条件是什么
预测试功能无阻塞
45.测试环境搭建需要和需求配置一样的硬件条件吗
不一定,功能测试环境是不关注硬件条件的,如果测试性能的话,就要关注这个了。
(其实我不知道什么是需求配置)
46.测试环境会不会在虚拟机上搭建
可能会吧,我们的测试环境都搭建在物理主机上了。
47.测试环境搭建一般会有安装说明书吗
会
48.预测试无法通过怎么处理
开发连夜改,如果改不好推迟测试开始时间
49.每天能够执行多少条测试用例
20来条吧
50.执行用例之后用例会有哪些状态
通过、不通过、阻塞……
51.对于无效的用例怎么处理,哪些情况会导致用例无效
删,需求变更、设计重复、或者对需求理解有偏差都可能造成用例无效。
52.Bug的生命周期以及Bug在每个阶段的的状态
测试人员提交BUG新建
测试经理确认BUG打开
项目经理/开发经理确认,分配给开发打开
开发确认,修改已修改
测试回归通过关闭
开发确认非错非错/rejected
测试确认非错关闭
开发确认不改不改
开发确认遗留delay/延迟/遗留
测试人员回归不通过或确认是BUGreopen/重新打开
53.测试人员在Bug或者需求上存在争议解决过程是怎么样的?
沟通、讨论,找用户确认,不成就升级
54.项目中出现争议,测试经理和开发经理无法抉择怎么处理
没有遇到过,具体问题具体分析,都是一个团队的,没有解决不了的问题
55.你们公司用什么缺陷管理工具,谁维护缺陷管理工具
BUGFREEBUGZILLABUGBASEQC……
56.系统测试缺陷产生的主要原因有哪些
需求理解错误、设计不完善、程序错误、UI错误、兼容性、性能、安全性等
57.Bug级别怎么来定义,一般有几级
我们用的是四级,1-致命,2-严重,3-一般,4-轻微/建议
58.说出你映像最深刻的Bug
略,我在课堂说过一个userid和customerid重复的问题。
59.哪一些Bug需要关闭
回归通过的,确认非错的,无效的
60.测试什么时候可以结束
软件通过验收测试;用例覆盖率、测试执行率、测试通过率、遗留问题等方面达到质量指标;问题都已修复,执行用例无法发现新问题。
61.性能测试在什么时候测试
功能稳定之后,具体的时间就是没有其他干扰性能环境的时间。
比如一共四轮测试的第三轮。
62.自动化测试在什么时候测试
回归
63.兼容性测试在什么时候测试
功能稳定之后
64.资料测试包括哪些,谁来测试,资料测试在什么时候测试
测试方案、测试用例、版本说明书、安装说明书等等文档的评审。
方案、用例的评审就是在其完成之后,版本说明书、安装说明书在版本发布之前。
65.资料是谁写的
CMO,我们写的。
。
。
66.资料测试需要设计测试用例吗?
无
67.测试一般分几轮,大致的时间段是怎么样的
我们新项目一般测4、5轮甚至更多,我们的版本测试一般都是3轮。
新项目中第一、二轮都差不多一个月,3轮可能有半个多月,第4轮大概只有几天。
版本中第一轮可能有一周,第二轮差不多3、4天,第三轮可能只有1、2天。
68.无法执行的测试用例怎么处理
分析原因,如果是冗余的就删除,如果是被阻塞的就保留
69.测试提交的bug怎么处理
确认、修改……
70.Bug修改后由谁来回归
提BUG的测试人员
71.回归不通过的Bug是什么状态
打开
72.你写过测试总结吗?
你说的测试总结是更像测试报告还是业务总结呢?
我写过业务总结,就是在进行了这部分业务的测试之后,总结一下这个业务的细节和测试需要关注的点。
73.测试报告是谁编写的
测试经理/组长
74.测试报告时谁评审的
PM、测试主管、部门主管、部门经理等
75.测试报告里面包含哪些内容
测试过程中的数据如用例覆盖率、执行率、通过率等,遗留BUG的分析,风险,质量评估结果等
76.验收测试是谁做的
用户
77.sit,ut,uat是什么
SIT就是SystemIntegreationTesting系统集成测试
UT就是UnitTesting单元测试
UAT就是UseracceptanceTesting用户接收测试/验收测试
78.什么是用户手册
指导用户使用的说明书
79.验收测试不通过测试需要做什么
改BUG
80.Bug怎么进行回溯
分析漏测的BUG是什么原因产生的,如果是容易发现的,并且测试用例中有涉及,要追究相应测试人员的责任,如果是偶发性,隐藏比较深,也要进行记录,在日后的测试中加以注意。
总之,如果是能力范围内,能够找到却没有找到的BUG就要追究相关测试人员的第一责任,如果非能力范围内的,要引以为戒,吸取教训,积累经验。
81.你们项目的缺陷密度是多少
BUG数/代码量
82.验收的缺陷密度是多少
不知道
83.验收不通过,谁承担责任
一般来说,测试人员承担第一责任
84.有Bug的版本能否发布
可能会发布,看BUG是啥BUG,有多大影响,修改需要多少成本,还是那句话,具体问题具体分析。
85.阿尔法测试盒贝塔测试区别
α是公司内部员工模拟用户进行测试。
β测试是用户进行非正式验收测试。
86.你们项目总共发现了多少Bug
项目的话200-400
版本的话20-60
87.一个项目10个月,你能大致划分一下每个阶段嘛?
确定需求可能需要2、3个月,之后要做近一个月的需求分析,开发设计、编码,测试人员的测试设计可能也需要3个月左右,而测试执行大概需要4个来月。
88.Bug在项目中不能正常收敛,原因有哪些?
需求不断变更是很可能的原因,或者是开发人员水平较低,修复一个BUG引发出若干其他BUG。
89.在测试阶段能够发现大概多少比例的Bug
很多吧,应该有80%以上,如果版本很稳定可能会更高。
90.解释一下为什么越早发现Bug,修复成本越小
因为越早发现BUG,就会在错误的道路上走的越短,及时修正后,避免了在错误的道路上越走越远的情况。
91.什么是28原则
8成BUG在2成的模块。
92.你是怎么安排你的工作时间的
我还是以任务为导向或者说以结果为导向的,每天我都有自己的目标,今天打算完成多少工作,会做到今日事今日毕,如果完成的比较早,可能会帮助其他同事或加强自己学习和提高,如果在下班的时候还差一点完成不了,我宁可加班完成,也不愿意将任务拖到第二天。
当然如果遇到我个人无法解决的问题,造成了我任务完成不了,我会尽快反馈、协调解决问题,尽量保证当天可以完成,或调整我的工作计划。
93.你对出差有什么看法
全球不限时不限地点
94.项目是否发现Bug越多,质量越好
NO!
发现的越多,藏的也越多
95.上线前晚上发现严重Bug,第二天之前来不及修复,该项目能否上线
不能
UT=unittesting单元测试IT=integrationtesting集成测试ST=systemtesting系统测试UAT=Useracceptancetesting用户接受测试(俗称:
验收测试)
经过了近2年的努力,多数研发团队都用上了技术质量部自主研发的Bug管理工具Kelude_Issues,告别了商业工具和其他的开源工具。
这个过程中Bug跟踪流程也发生了比较多的变化,下图是现在Kelude_Issues的Bug跟踪流程图:
这个流程还是有着比较多的“淘宝特色”,我想可能很多用惯了其他Bug管理产品的同仁,看着这个图会感觉不太习惯,觉得状态比较多,箭头也多,有点绕。
在经典的Bug跟踪流程里面,对于“状态”概念的定义,是比较清楚的,一般来说这些状态会比较常见,当然由于工具的不同,所用的英文单词也会有些差别,这个不用纠结,领会精神。
New:
新创建的Bug
Open:
经过了PM的确认,确实是个Bug
Assigned:
已经分配给开发工程师进行解决
Resolved:
开发工程师解决了,等待测试工程师验证(注意是解决,不是fix)
Closed:
通过了验证,关闭
这里最容易引起混淆的概念,就是“Resolved”——被解决过了。
最常见的解决方式,就是Fixed,被修复了;有时因为一些原因,暂时无法修复,只能Later,其实Later也是一种解决方式,常见的解决方式有以下几个:
Fixed:
被修复了
Later:
暂时不修复,后面的版本再修复
WontFix:
不修复了,其实是一种Later的特例,无限期Later
Invalid:
根本不是Bug,往往由于对需求的误解
Duplicate:
重复的,相同的Bug已经被提交过一次了
NotReproducible:
无法重现,在淘宝叫做WorksforMe
严格来说,这一组“解决方式”,是属于同一层面的,它们都需要由测试或者PM来验证,如果验证不通过,那就回到Open状态,验证通过就Close。
而在淘宝Bug流程中,这些“解决方式”都被设置成了“状态”,其实也挺好,更加直观。
但是这里有一个很要命的问题,就是那个“wontfix”状态被刻意放大了,跳了出来成为了一个抽象的概念,这让很多开发工程师非常困惑,到底wontfix代表什么意思?
由于wontfix被错误的使用,引起了比较多的争议,记得当初优昙狠狠的挑战了一把,争论了很久,现在想来还是有道理的。
也有很多开发表示,为什么我要Invalid,还要经过wontfix呢,多不方便,于是我们做了调整,变成了下面这个样子:
这样虽然解决了上面开发提出问题,但是这个流程依然有点不伦不类的,所以我们咬咬牙,继续改,彻底的改,成了这样的流程:
这个流程和经典的流程相比,还是有一些区别,我们依然选择把一些常用的“解决方式”,直接定义为“状态”,这样大家就不用理解那个抽象的“Resolved”了。
当然,我们有一点跟经典Bug流程吻合,就是最后Bug都要回归Closed状态,之前大家都习惯了“只有Fixed才能Close”,这个习惯需要重新适应一下。
这里有人会问,最后都是Closed,怎么区分Later呢,我需要把Later的全翻出来,怎么找?
这个问题还是比较好解决的,只要在CloseBug的时候,把当前的状态也记录下来就可以了,这样大家就能看到类似于Closed(Fixed)、Closed(Later),这样就比较好区分了。
还有一个概念我们也比较常用,就是Reopen,目前Open和Reopen是两个独立的状态,但是它们的含义却是很接近的。
由于我们把Reopen视为修复失败,是一种过错的表现,以后我们只要关注Fixed到Open和Closed到Open的记录即可,不用为了“度量”,单独定一个状态出来。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 最新 15 面试 提问 整理