软件测试常见面试题
2023-07-19 14:33:22 0 举报软件测试常见面试题
作者其他创作
大纲/内容
综合素质
自我介绍
面试官您好，我叫XXX，一直从事车载软件测试，负责最多的是中控方面
以下是我的一些优势：
车载的测试流程我是熟练掌握的，且能够独立编写测试用例
平时BUG提交会使用到Jira，类似禅道这些缺陷管理工具
测试中抓取log会涉及adb命令的使用 ，也如会用monkey进行APP的稳定性测试，有涉及到代码修改户使用到Androidstudio这些开发工具
我自学过Java语法，看懂简单代码
我接触过有涉及到使用Canoe工具的项目，比如HUD，CANoe主要是用来仿真发送报文、分析报文等这些作用
具有C1驾驶证，也曾经路测过，但开车的人不是我
以上是我的个人简短的介绍，谢谢
离职多久了？为什么要离职
人是需要不断锻炼的，在一个地方呆太久，人的思维会被环境所固化了，换个环境，或许对思维和空间上都有一个很好的发展
宁波版：上周刚办理完离职手续，想去宁波发展
之前很荣幸去过研究院，被实验室里面的更加先进与专业的设备给吸引了，而且吉利研究院里面有很多名企，我想会学到更多技能
深圳版：上周刚办理完离职手续
到目前为止我一直在后装发展
从我自身的职业规划出发，我想把空间再往上升，前装就是一个很好的挑战
假设反问我提升什么空间？
不是同行但类似的岗位：比如蓝牙测试，我有比较泛的蓝牙测试经验，我想贵公司的蓝牙测试会更具专一与专业性
同行同岗位：贵司行业属于前装，相对后装来说会更具备挑战性，我本来也希望接触到跟多挑战的项目
目前我在这个岗位上的发展已经到了一个瓶颈，想换一个环境修炼到更高层
谈一谈你的工作经历
我属于那种比较稳定的员工，在上两家公司呆了平均时间都超过了3年（强调自己的稳定，不会经常跳槽）
然后这两家公司都是属于车载行业的；（突出自己的行业经验和优势）
我在职期间积累不少的车载工作经验，比如怎么了解和分析一个产品的需求，怎么去编写测试用例、怎么去规范使用各种不同的测试工具和怎么跟不同部门协调和沟通等待这些（给出自己能带来的价值）
谈谈你之前公司及工作情况，感悟或收获
这两家都是做车载中控的，我主要是负责中控系统全功能测试，期间也参与了不少项目
积累了不少经验，在有些项目中自己也能够独挡一面，如怎么分析需求，评审需求，测试用例怎么写才能规范，怎么跟同事与客户打交道，相关测试工具的使用和技能的提升，都有所累积
你做了这么多年软件测试，有没有什么感悟？
我的感悟有以下几点：
首先从沟通上讲：沟通是交互信息的前提，在工作中会和不同的同事协调工作，所以要保持良好的沟通;
其次，身为测试，是产品的第一个全面体验者，应当站在用户的角度去理解整个产品，才能更好地进行测试
接着，就是测试用例：用例要覆盖所有的需求，编写要规范，且可执行性强;
最后，就是总结：在工作和生活中不断地去总结和积累经，下次遇到类似问题就可以很好的找到解决方案
谈谈你对未来的规划（职业规划）
近期，入职后，我想快速融入公司团队，熟悉业务；
远期，还是要不断总结与积累，提升个人的技能
为什么要选择做软件测试
一开始是机缘巧合接触到这个岗位，后面发现其实找BUG 是一个很有趣的工作，特别是找到大bug时就特别有成就感；
且我性格也比较适合做测试工作，比如，细心，有责任心，性格开朗等
谈谈你对软件测试工作的理解
软件测试是用来发现软件bug，提高产品质量，降低成本的一个工作
作为软件测试员需要具备哪些特质
参考方面：技术方面，测试思维，工作职责，组织协调等
测试人员需要具备的特质还蛮多的，我认为的有以下几点：
1. 掌握软件测试的相关技术，才能提供测试的质量；
2. 文档的编写能力要好，特别体现在测试用例上；
3. 做事要细心，耐心，负责任；
4. 需要保持良好的沟通能力，毕竟需要跟各个部门都要打交道；
5. 思维要开阔，时刻紧跟市场，从跟多用户的角度思考问题；
如何做好软件测试工作（技术/测试用例/沟通/个人）
1. 要掌握软件测试的相关技术
2.测试用例编写时，要简洁清晰，步骤详细，可执行性强
3. 由于与不通过部门打交道，必须具备良好的沟通协调能力
4. 做事一定要细心，不急不躁，且责任心要强
你觉得软件测试工作什么最重要
我觉得是思维
1. 思维要开阔些，测试用例才能覆盖得更广些；
2. 特别是逆向思维，可以测试一些不容易被发现的BUG；
3. 当然技术也很重要
作为一个测试工程师，你认为怎么样才能保证软件质量
在我看来，软件质量不是靠测试出来的，测试只是为了发现问题，从而使产品尽善尽美，开发才是软件质量的保证者，代码的质量决定了产品的质量
你对上一家公司的贡献是什么
你的优点和缺点是什么
优点：
1. 具备多年的车载测试经验
2. 对待工作比较细心，耐心，遇到不明白的地方也能虚心请教同事
3. 性格开朗，沟通协调能力也不错，与同事也能很好相处
缺点：
平时比较宅，不怎么锻炼，希望自己多锻炼，有了好身体才能更好工作
有碰到让你印象深刻的BUG吗
有的，我就举两个常见的例子
在正常倒车下，出现黑屏
我们自己检查camera的连接都是好的，提到开发，开发分析发现是
1. 遇到过camera 内核驱动异常；
2. camera hal ion内存泄漏
某个平台播放某个视频时出现黑屏，把视频放到其他平台去结果是好的，后面发现只有这个平台不行，给开发分析
1. soc原厂不支持当前视频格式（视频可能带版权）
2. 如原厂soc支持，就通过修改解码库
3. 如果不支持硬件解码此类视频源，可以自己编写软件解码
就举这两个例子吧，如下：
音乐播放界面，carplay来电，无法跳转到carplay
具体现象：第一次能跳转到carplay页面，第二次不能，第三次可以，第四次不能，我走之前都还没未解决
亿连，连接有线安卓时，一直没连接上，好像是华为手机
后面发现这类手机需要到开发者选项里面把USB调试相关子项都要打开
连接蓝牙后，通话，车机端没有声音输出：先从硬件上看，是否有mic，硬件是OK的，那就是软件的问题
如果开发不认可你的BUG，你会怎么做（是否BUG/需求/环境/场景）
我觉得要从以下几个方面分析
首先，自身再确认过，再找开发了解他说不是BUG的原因
其次，假设是需求变更，那就找产品经理确认此事，如果真的改，就关闭，如果没有话就继续激活
接着，假设开发说测试环境问题，那可以按他说明重新部署环境验证BUG，确实如他所说，那就关闭，如果不是，还是就继续激活BUG
最后，假设开发说用户不存在这种使用场景，但没人能保证客户的使用手法，那我们就不认可他说的，让部门老大去判定
开发提测不准时，项目上线出BUG怎么办？
此类问题，在任意一家公司都会存在，也不能彻底解决
我们只能尽可能地去杜绝它，我提个个人见解：
我们只能尽可能地去杜绝它，我提个个人见解：
1. 首先，确定好研发与测试的时间
2. 其次，跟进开发进度，再根据进度来调整开发计划
3. 最后，哪些功能开发好了，就先测试边，不用等开发完再测
项目上线后，出现问题怎么办
评估bug的影响范围
1.分析bug影响的用户数量
2.分析bug影响的严重程度
解决线上问题
1.bug影响范围比较小时，后续版本迭代更新
2.bug影响范围比较大时，立即定位修改问题，将问题影响范围降到最低
回溯线上问题
检查其他的业务是否有同类型的问题
分析bug出现的原因
补充操作出bug的测试用例
能否独立负责一个软件的测试，准备怎么开展测试工作
我们基本都是独立负责项目，只是项目的主导是测试主管而已，当然，没有测试主管我也可以主导一个项目
1.老师给的开展工作：
第一点，我们要梳理整个项目的基本信息（项目这次改动的模块/上线时间，开发时间，测试时间、参与的人员、项目给我们测试部的设备有哪些，还需要我们测试部准备哪些）
1）梳理本次改动模块、上线时间、测试时间、需要几名测试人员参与。如果确定了上线测试，根据倒推法，看看能留给测试多长时间测试；如果不确定测试时长，可以根据开发时长的 1/2 或 1/3 去估算；假如是我自己去负责所有测试，你会需要多久，再根据测试人员数量去均分或能力分配都可，记得预留出应急的时间半天或者一天
梳理本次改动模块、测试时间、上线时间，这个项目需要几名测试人员参与
项目提供给测试的设备都有哪些，还需要我们准备哪些东西
整个项目都有哪些部门参与和对应模块的负责人是谁
第二点，分配人员，把整个项目的基本信息梳理完后，就要确定项目需要多少个人来测试，按测试人员的能力，分配的对应的测试模块，让每人编写自己所负责的测试用例，测试计划是由我编写
第三点，把控测试进度，每天抽一点时间来开个进度会议，让每个模块的测试人员汇报一下测试进度，和测试过程中遇到的问题，做好一个协调与沟通的工作
2. 项目基本信息梳理完后，确定项目需要多个人人参与，开始分配任务，确定每个人负责的模块
可以根据模块的复杂度、业务流程、测试人员的能力，来进行组合分配。每个人一到两个核心流程，分支流程由测试人员自行设计。若任务量过多，自己要主动承担起一部分测试任务。整理好核心check list ，主要业务流程自己得理清楚，多跟产品，开发聊聊，有时间就多跑核心业务
3. 分配完后，开始进入测试阶段，定时汇报项目进度、测试过程中出现的问题和解决方案
1）让各位测试人员定期汇报进度以及质量问题，每天早上 10 分钟左右站会解决这件事。特别是到项目后期，每天开短会汇报进度。
2）测试流程阻塞，分析在哪个环节（产品 or 开发...）出现的问题，快速及时找到解决办法（申请资源 or 放弃一步功能上线...）。
3）做好跨部门协调工作，及时沟通。
在整个项目测试期间，每天早上抽个20分钟，让测试人员要及时汇报进度以及出现的一些问题，做好跨部门的协调与沟通
工作中，经常需要与哪些人沟通，有哪些问题沟通
产品与设计：沟通需求及 UI 界面方面的设计
开发：了解他们的实现方式，有针对性的设计用例，bug与技术上的沟通
硬件组：机器组装，修理零件或线材缺失
业务部：有些客户不知道某个功能的操作方式，需要帮他去解决
在工作中遇到过什么困难，怎么解决
1. 需求不明确，导致改来改去
在项目总结会时，提出让产品尽量先整理好需求再分发下来
2. 项目提测质量差
开发改好后先自测通过，再提测，自测用例可以测试提供，一般是主要流程用例
3. 开发未按时间提测
紧跟进度，进度有延时的及时反馈上去
测试可以提前介入，比如提前问开发，哪些功能做好了，就先测哪些功能。再如开发计划两天完成一个功能，就两天找一次开发，不用等开发全部开发完成再开始测
4. 没有接口文档
让开发完善接口文档，前期可以先用抓包工具辅助做接口测试，完善接口文档，对前后端联调也有很大帮助
5. 测试时间不够
测试时间不够，砍功能或者加人，或者先跑通主要流程。手上有多个项目的话，先做优先级高的项目，其他项目可以先过主要流程
6. 开发不及时改BUG，导致项目延期
跟开发搞好关系，时不时提醒一下开发，及时改级别高的bug
项目原本留给开发与你各一天，但开发多占用了半天时间，你如何去协调开展工作
你们测试的周期一般是多久
客户维护组：
时刻跟进BUG修改，1-2天
项目组：
3-6个月，后装市场竞争很激烈，版本迭代更新很快，但凡出慢一点，就会被别人占领市场
一个项目写测试用例多长时间，测了多久，测出多少个BUG
没留意过具体多少条
没留意过具体每天多少条
一个模块的测试用例大概在100-200条用例，但是还要以具体的功能为准
一天能测多少条用例，能提多少个BUG
每天测试多少条用例，是按测试计划安排，没有固定数量
BUG也是，项目前期bug会多点，一天三十四十都有，后期产品稳定，就相对较少了，开发会开玩笑说测不出问题就不能下班，哈哈哈
你找工作时最重要考虑的因素是什么
公司的发展前景，毕竟公司发展好了对于我们个人自然发展就好
还有就是比较乐意与像面试一样的人共事感觉会更开心一些
你怎么看待加班
加班是因为需要，身为公司的一份子，既然公司需要我们的付出，那肯定义不容辞
你还有什么想问的吗
公司目前在开发的车机是安卓几点几了
请问这个岗位的规划是什么样的
测试跟开发有多少人
开发与测试的问题对接流程
测试内部工作安排流程是怎么样的
面试结果大概多久出来
你平时都关注什么
平时会看一些软件测试方面的内容，比如CSDN、博客园上面等等上学习
期望中的工作环境是怎么样
学习交流的氛围，特别是技术方面的交流与学习
同事之间沟通交流很愉快
你们公司的人员架构是怎么样的
公司部门很多，我就讲技术相关的部门吧
产品/设计/MCU/应用/硬件/系统/测试
婚姻状况
我是恐婚主义，人嘛还是努力工作才有安全感
你对外包怎么看
不论选择什么性质的公司，能实现人生价值即可
之前工资多少，交社保/公积金吗，都交多少
提醒：不要回答具体数字，要说区间，在实事求是的范围
1. 深圳：模糊具体工资，11-13，有项目奖金
2. 宁波：17-22K，加班费1比1
3. 社保与公积金都按深户缴纳
你期望的薪水是多少
深圳：11-15K
宁波：17820K，且有加班费，按1比1
什么时候可以到岗
我已经离职了，随时都可以入职到岗
我们这次做的项目主要是面向车载哪个方面
测试理论
测试策略或测试包括哪些，测试要覆盖哪些方面
UI、功能、性能、可靠性、易用性、兼容性、安全性、安装卸载
设计测试用例的办法：
等价类、边界值、错误推测法、场景法等设计方法来编写测试用例的
1. 等价类分为有效等价类和无效等价类，符合需求的就是有效等价类，不符合需求的就是无效等价类
2. 因为大量错误都是发生在输入和输出的边界上，而不是发生在输入输出范围的内部，所以就有了边界值分析法，边界值是选取正好等于、刚刚大于和刚刚小于边界的值，它一般是跟等价类一起用的
3. 举个例子：设置密码要求是6-12位的数字和字母的组合，那有效等价类就是长度在6-12之间，数字和字母的组合；无效等价类就是长度小于6（取5）的数字字母组合，长度大于12（取13）的数字字母组合，长度在6-12之间的纯数字，长度在6-12之间的纯字母，长度在6-12之间的除了数字和字母以外的字符，等等
4. 错误推测法是指凭借经验推测程序可能出现的错误，比如新建和修改的名称要唯一，不唯一的话没办法提交成功
5. 场景法是根据业务流程来写的，有基本流和备选流，然后考虑异常流情况下是否出现bug。比如一个商品加入购物车、提交订单后超时不支付，会出现什么情况
编写测试用例的思路或怎么写测试用例的
1.首先要熟悉需求，，先理清楚“项目是怎么使用的”、“是给谁用的”、“干什么用的”，再根据业务流程来写，提取功能点，最后根据等价类、边界值、错误推测法、场景法进行测试用例的编写;
2. 功能点的话，每个系统的模块中都有一些共有的功能，比如：倒车，所以在测试中我们要先把这些功能过一遍;
3. 先走正常流，正常流通过之后，再对异常情况进行测;
另外，熟悉业务流程是非常重要的，模块与模块、功能和功能之间是相互联系的，不能只是单独测它的功能正不正常，还要把他们的关系全部走通。比如我测的电商系统中，要先添加商户、品牌和分类，然后才能添加商品
用例要素是什么或包含什么内容
用例编号、模块名称、功能点、用例标题、前置条件、测试步骤、期望结果、优先级、实际结果、备注
测试关注点
如何保证测试用例的质量
1.测试用例的需求覆盖率是100%；
2.测试用例的可执行；
3.测试用例的可读性；
4.测试用例的评审；
5.及时维护测试用例，也许一个功能的变更，或者场景的添加，就需要考虑更多的情况，保证测试用例的完整性
之前都是用什么工具写测试用例的
我们是根据需求文档提取测试点，根据等价类、边界值、错误推测法、场景法来编写测试用例，用excel表格来写测试用例的，发现bug后用公司开发的BUG管理系统提交bug，指派给对应的开发
没有需求文档，直接给你待测试软件，你怎么开展测试工作
1.问：没有需求文档，那肯定有需求提出者，那与他进行沟通。
2.问：但凡懂需求的人，我们都可以问。如问开发，项目经理，测试经理等;
3.分析：结合一些业务资料和百度等进行分析;
4.对比：对比竞争对手产品，分析得到合适的需求;
5.经验：可以借助原来的经验
6.合理：一切的需求都要符合常理
软件开发过程中常见模型
V模型
需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
W模型
测试和开发同步进行，可以尽早发现问题
需求分析、需求测试---概要设计、概要设计测试---详细设计、详细设计测试---编码实现、单元测试---模块集成、集成测试---系统构建、系统测试---系统安装、验收测试
需求分析、需求测试---概要设计、概要设计测试---详细设计、详细设计测试---编码实现、单元测试---模块集成、集成测试---系统构建、系统测试---系统安装、验收测试
软件上线的标准
用例全部执行完毕，bug回归完毕，没有遗留严重的bug，产品经理验收通过后就可以上线了
单元测试、集成测试、系统测试、验收测试
1. 单元测试又称为模块测试，是对代码中的函数和方法进行测试；
2. 集成测试，也可以称作接口测试，开发把功能模块进行整合，测试功能和功能之间是否能够对接成功；
3. 系统测试是对整个系统进行测试，也是黑盒测试；
4. 验收测试分为a验收和贝塔验收，a验收是在开发者环境下进行测试，贝塔验收是在真实环境下由真实用户体验，有问题再反馈给开发人员
软件测试的风险
进度风险、质量风险、人员风险、变更风险、成本风险
你写过测试报告或测试报告都有哪些内容
写过，不过写的都是我们自己负责模块，整个系统的测试报告由测试主管完成
一般的话会对项目背景做一个阐述。
主要就是内容简洁、不罗列详细数据、挑拣一些能说明问题分析数据的：比如缺陷走势图，模块的bug分布等，突出重点遗留问题，然后得出分析测试结论
一般的话会对项目背景做一个阐述。
主要就是内容简洁、不罗列详细数据、挑拣一些能说明问题分析数据的：比如缺陷走势图，模块的bug分布等，突出重点遗留问题，然后得出分析测试结论
测试内容：测试内容的大纲。
测试环境：测试环境的描述，包括客户端和网络环境。
测试工具：测试过程中的测试资源使用。
测试的数据：bug数，解决数，遗留数。
模块bug分布，bug走势图，缺陷遗留，需要说明的问题。
测试数据分析：对于整个过程测试的一个分析，得出结论。
遗留问题：对于软件遗留问题有详细说明。
回归测试策略，历史用例（上一个版本的用例）在现版本怎么回归？
回归测试常用的策略有：全面回归测试、选择性回归测试等。
像我们一般会进行三轮的测试，第一轮把功能都过一遍，提bug；第二轮做一个全面的回归测试；看具体的情况，第三轮会进行选择性的回归测试，把出现bug的相关模块都测一遍。
像我们一般会进行三轮的测试，第一轮把功能都过一遍，提bug；第二轮做一个全面的回归测试；看具体的情况，第三轮会进行选择性的回归测试，把出现bug的相关模块都测一遍。
全面回归测试：所有的测试用例都重新测一遍；
选择性回归测试：对于出现问题的bug进行验证，没有问题的bug就不进行测试；
自动化工具回归测试：使用自动化测试工具进行回归测试。
测试环境怎么维护
等开发把代码更新完后，上传服务器进行覆盖
你提了一个bug，开发不认怎么办？
1.首先从自身找问题，再根据需求文档分析这是不是一个bug，如果确定是bug;
2.再看看测试用例的操作步骤写的够不够详细、可执行性强不强；
3.如果不是以上原因，那就跟开发沟通，可以在开发的电脑上实现给他看，然后跟他好好解释，如果这真是一个bug，开发是不会不认的；
4.如果还是不认，那就要上报给上级，然后开会进行讨论
什么bug是个好bug？
1.确定与需求不符
2. 严重影响到客户的使用
3.bug的复现步骤要详细，可读性可执行性强，能够再次复现出来
0 条评论
下一页
