软件测试面试题集(含答案)

软件测试面试题集
一、Bug基本要素
缺陷ID，状态，类型，所属项目，所属模块，缺陷提交时间，缺陷提交人（检测者），严重程度，优先级别，缺陷描述信息，测试步骤，测试前置条件，测试数据，期望结果，实际结果。
注:Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。
A- Crash 错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
B- Major 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
C-Minor 次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
D-Trivial 错误是表面化或微小的（提示信息不太准确友好、错别字、UI 布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；
E-Nice to Have（建议） 建设性的意见或建议。

二、http协议中get和post的区别/strong>
1、get请求通过URL传递，post通过request body进行传递；
2、get只能进行url编码方式，但是post可以进行多种编码方式；
3、get只接受ASCll数据类型，但是post没有限制；
4、get因为参数包含在url地址上，所以并不安全；
5、get对参数的传递有有限制的，但是post没有；
6、get的请求参数会被完整的保留在浏览器的历史记录里面，但是post不会；
7、GET产生一个TCP数据包；POST产生两个TCP数据包。

三、http和https的区别/strong>
1、安全性不同
http是超文本传输协议，它是明文传输的，如果有人截取服务器与浏览器之间的协议，就可以知道传输的信息了，https有一个ssl加密协议，所以相对来说https是安全的。
2、端口号不同
http的端口号是80；
https的端口号是443。
3、申请方式不同
http申请是免费的；
https因为是ca申请证书所以是收费的，一般很少有免费的。
4、连接方式不同
http的连接很简单，是无状态的；
https是由ssl+https协议构建的的可进行加密传输，身份认证的网络协议。

四、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题/strong>
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

五、列表和元组的区分/strong>
1、元组和列表都属于序列；
2、列表属于可变序列，它的元素可以随时修改或者删除，而元组属于不可变序列，其中的元素是不能修改的，除非整体重新赋值；
3、列表可以使用多种方法实现添加和修改列表元素，而元组没有办法，因为不能在元组中添加或修改元素，同样也不能删除元素；
4、列表可以使用切片方法访问和修改列表中的元素，元组也支持切片，但是它只支持通过切片访问元组中的元素，不支持修改；
5、元组比列表中的访问和处理速度更快，所以如果只需要对其中的元素进行访问，而不进行任何修改，建议使用元组；
6、列表不能作为字典类型中的键，而元组是可以的。

六、数据库常用聚合函数/strong>
1、计算记录的总数
SELECT COUNT(字段名) FROM 表名；
2、计算某列的和
SELECT SUM(字段名) FROM 表名；
3、查询字段的最大最小
SELECT MAX(字段名) FROM 表名；
SELECT MIN(字段名) FROM 表名；
4、排序
SELECT 字段1，字段2，字段3 … FROM 表名 ORDER BY 字段；

七、一个问题你认为是bug，但是开发人员认为不是，你如何处理/strong>
1、将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
3、与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

八、如果你负责的项目线上出了bug，你怎么解决/strong>
先了解bug发生的根源，看是我理解需求要偏差还是设计用例上有疏漏。如果需求理解有偏差看是需求描述是不是描述得不够准确，如果是的话可以和需求商量定一套比较规范的需求描述文档，看怎样才能把歧义降到最少；如果需求准确但我理解出了问题，那我下次梳理需求的时候会多问，多和需求讨论，争取每个需求都理解得很透彻；如果是设计用例上有疏漏，那我会考虑疏漏这个点的原因，并把这次疏漏的点记下来，避免下次再出现这样的问题。

九、缺陷的生命周期

二十八、为什么测接口及必要性
比如测试用户注册功能，规定用户名为6~18个字符，包含字母（区分大小写）、数字、下划线。首先功能测试时肯定会对用户名规则进行测试时，比如输入20个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗果是登录可能会通过SQL注入等手段来随意登录，甚至可以获取管理员权限，那这样不是很恐怖/p>

接口测试的必要性就体现出来了：
①可以发现很多在页面上操作发现不了的bug；
②检查系统的异常处理能力；
③检查系统的安全性、稳定性；
④前端随便变，接口测好了，后端不用变。

二十九、什么项目适合做接口自动化测试
①任务需求明确，不会频繁变动；
②项目周期较长，回归测试频繁（>=5次），开展自动化确实能提升测试效率及质量；
③产出的效益高于投入；
④测试预留的时间比较充裕。

三十、接口测试中的http状态码
每发出一个http请求之后，都会有一个响应，http本身会有一个状态码，来标示这个请求是否成功，常见的状态码有以下几种：
1、200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
2、300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。
3、400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。
4、500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果。

三十一、没有接口文档如何做接口测试/strong>
没有接口文档，那还能咋办，瞎测呗！一个公司的开发流程里面，如果接口文档都没有，是无法展开接口测试的，你都不知道这个接口干什么的，也不知道具体每个字段代表什么意思，那还测啥呢br> –当然，你肯定不能回答面试官不测(心理mmp，脸上笑嘻嘻)，接下来就是扯犊子时间
1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）
2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通

三十二、接口测试中的数据依赖
在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理br> 用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数。

三十三、当一个接口出现异常时候，你是如何分析异常的/strong>
1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了。
2.查看后端日志，xhell连上服务器，查看日志。

三十四、前后端bug区分
一个Bug出现，最简单易行的判断办法是：通过请求与响应来判断。
1、如果前端已经把数据发送给了后端，后端接到请求，而后端没有返回数据请求，则是后端出了问题；
2、如果前端在用户输入数据后，发送的请求没有带数据，则是前端的问题，或者后台已经传回了数据，但在前端显示不出来，这是前端问题。
3、当然具体问题要具体分析，可以在浏览器中debug调试中看，但大的原则就是通过请求与响应来判断。

三十五、那么需求评审时期测试到底要做什么呢/strong>
1、需求评审前，提前进行需求熟悉阶段，逐一分析需求点，做好准备，相关需求疑问点列好清单，带着问题去参会。
2、产品宣讲时期，就算过程有问题，不要试探打断产品的宣讲，一是节约时间，二是不礼貌，等产品将一个模块宣讲完毕，开始带着你的问题，开始你的表演，分析给项目成员听，并提出改进建议。
3、当需求有问题确认需要修正，或需进一步跟业务确认再做定夺的，做好标记，并提醒产品，做好会议记录。
4、开发是个直男~一旦进入技术凯旋，那非得争的明明白白的，所以宣讲时期如果开发进入技术凯旋，在适当时期提醒产品，进行控场，有效的控制时间，接着宣讲其他模块业务流。
5、需求评审完后，项目群推送需求评审会议记录点，周知各位目前的版本的疑问点以及修改点，并提醒产品进行下次需求确认会议时间,这个会议也可以由测试主持。

三十六、web和移动端测试的区别
1、从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

2、性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。

3、兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。

4、相比较web测试，app更是多了一些专项测试：
①一些异常场景的考虑以及弱网络测试。
这里的异常场景就是中断，来电，短信，关机，断电，重启等。
　　弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。
②安装、卸载、更新：
　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
③界面操作：
　　现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。
④边界测试：
可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等。
⑤权限测试：
设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等。

三十七、逻辑题—取最值(有可能结合代码考查)
一楼到十楼的每层电梯门口都放着一颗钻石，钻石大小不一。你乘坐电梯从一楼到十楼，每层楼电梯门都会打开一次，只能拿一次钻石，问怎样才能取到最大的一颗/p>

只能拿一次钻石，我觉得有歧义，是每个电梯门口都能拿一次还是总共只能拿一次。如果是前者，那就是冒泡排序思想，拿走第一层的钻石，以后在每层楼交换较大的那颗到手里。如果是后者，总共只能出手一次，那么将无法确定拿到的一定是最大的钻石，可先在前5层辨别各个的大小，后5层中如果出现接近最大的那颗的话，就出手吧。

三十八、内链接、左右链接的区别
　 左（外）连接（LEFT JOIN），以左表为基准，查询出左表所有的数据和右表中连接字段相等的记录，如果右表中没有对应数据，则在左表记录后显示为空（NULL）.如果把两个表分别看成一个集合的话，则显示的结果为JOIN左边的集合。(以左表为准，去右边找匹配数据，找不到匹配，用NULL补齐。)
　 右（外）连接(RIGHT JOIN )是以右表为基准，查询出右表所有的数据和左表中连接字段相等的记录，如果左表没有对应数据则在右表对应数据行显示为空（NULL）.如果把两个表分别看成一个集合的话，则显示的结果为JOIN右边的集合。
　 内连接(INNER JOIN )是查询出两个表对应的数据，如果把两个表分别看成一个集合的话，内连接的结果即为两个表的交集。

三十九、如何做好回归测试
回归测试（Regression testing）是指代码在发生修改之后重新测试之前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的缺陷是否在软件新版本上再次出现。
关于如何做好回归测试，大体上是先验证bug，然后回归和本次修改相关的地方。
1、 和项目中的DEV以及项目负责人沟通确认
这是一个很关键的环节，好的开发人员在提交测试时就会注明可能影响的地方。
2、 关键点的测试
就是很重要的部分，即使看着和本次修改无太直接关联，也最好能走一下基本流程。因为这是客户最关心的地方点，也是盈利的所在。
3、测试的重点
bug修改，关联功能，新增加功能，修改功能，上一轮测试bug多的功能。（测试人员要了解开发在这一轮修改了哪些bug，要注意关注我们的bug管理工具上的变化。）

四十、测试过程中遇到app出现crash或者ANR，你会怎么处理/strong>
可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。

四十一、selenium中显示等待和隐式等待区别/strong>
显式等待

显示等待是单独针对某个元素，设置一个等待时间如5秒，每隔0.5秒检查一次是否出现，如果在5秒之前任何时候出现，则继续向下，超过5秒尚未出现则抛异常。显示等待与隐式等待相对，显示等待必须在每个需要等待的元素前面进行声明。
隐式等待

隐式等待是全局的是针对所有元素，设置等待时间如10秒，如果10秒内出现，则继续向下，否则抛异常。可以理解为在10秒以内，不停刷新看元素是否加载出来。

四十二、简述测试流程/strong>
1、阅读相关技术文档（如产品PRD、UI设计、产品流程图等）。
2、参加需求评审会议。
3、根据最终确定的需求文档编写测试计划。
4、编写测试用例（等价类划分法、边界值分析法等）。
5、用例评审(主要参与人员：开发、测试、产品、测试leader)。
6、开发提交代码至SVN或者GIT ，配管搭建测试环境。
7、执行测试用例，记录发现的问题。
8、验证bug与回归测试。
9、编写测试报告。
10、产品上线。

四十三、Alpha和Beta测试
Alpha测试就是由开发者“指导”用户在开发环境下进行的测试。Alpha测试是在受控的环境中进行的。
Beta测试就是由软件的最终用户们在一个或多个实际生产环境下进行的测试。开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。

四十四、为什么做测试,觉得自己做测试有哪些优势/strong>
我觉得我个人的性格比较适合做测试。
1、 比较细心耐心，考虑事情比较全面，这样对于我在设计测试用例时很有帮助；
2、我能够很好的与人协调沟通，当我们测试和开发发生沟通上的矛盾时我也能很好的解决；
3、平常喜欢刷微博、知乎看热门评论，喜欢考究大众心理，这有助于我站在用户角度设计测试点。

四十五、优秀测试人员应具备的素质
1、沟通能力与表达能力
2、好奇心与怀疑精神
3、责任感与抗压能力
4、自信心，坚持自己的观点
5、耐心与细心
6、逆向思维的能力
7、善于学习与总结
8、团队协作精神
9、文档编写能力

四十六、优秀测试人员应具备的技能
1、精通业务知识
2、具备软件编程能力，比如C,C++,JAVA等。
3、可以用脚本语言编写小测试工具
4、主流操作系统应用与网络知识，可以搭建测试环境
5、熟练掌握各种数据库知识
6、精通软件测试理论与方法
7、掌握常用测试与开发工具的使用
8、优秀的文档编写能力

来源：QT_5779