【测开冲冲冲】测开面试题八股文以及答案

博客主页：卷测开的快乐人 欢迎点赞 收藏 ⭐留言 欢迎讨论！
本文由 【卷测开的快乐人】 原创，
首发于 CSDN
由于博主是在学小白一枚，难免会有错误，有任何问题欢迎评论区留言指出，感激不 尽！✨ 精品专栏（不定时更新）

整理了经常考的八股文，大家可以看看，接下来会写一些应用题，记得双击加关注。

请你分别介绍一下单元测试、集成测试、系统测试、验收测试、回归测试，以及这里面那一步最重要。

单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的。
集成测试： 通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所述的程序结构。
系统测试： 是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
回归测试： 回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。
验收测试： 验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

集成测试和系统测试的区别，以及它们的应用场景主要是什么？

区别：
1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。

2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。

3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
场景： 集成测试：多用于接口测试。
系统测试：按照开发模型的说明书，对整个系统进行黑盒测试。

黑盒与白盒的测试方法

白盒测试： 白盒测试也称为结构测试，主要应用于单元测试阶段，检测软件编码过程中的错误。程序员的编程经验、对编程软件的掌握程度、工作状态等因素都会影响到编程质量，导致代码错误。
方法：
1）语句覆盖:所有的“语句”都要覆盖一遍。就是设计若干个测试用例，运行被测程序，使得每一个执行语句至少执行一次。

2）判定覆盖:包含语句覆盖，每个判断T、F各一次。使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。

3）条件覆盖:包含语句覆盖，每个条件T、F各一次是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次,但未必能覆盖全部分支。
黑盒测试：
黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。
方法：
1）等价类划分法

等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据划分为若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例。测试用例由有效等价类和无效等价类的代表数据组成，从而保证测试用例具有完整性和代表性。使用该方法设计测试用例主要有两个步骤:a确定等价类;b生成测试用例。

2）边界值分析法

边界值分析法是对程序输入或输出的边界值进行测试的一种黑盒测试方法。实际的测试工作证明，考虑了边界条件的测试用例比那些没有考虑边界条件的测试用例具有更高的测试回报率。这里所说的边界条件，是指输入和输入等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

3）因果图法

因果图法也是较常用的一种黑盒测试方法，是一种简化了的逻辑图。因果图能直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的输入组合上。因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况

手动测试和自动化测试的优缺点

手动测试的优点：
可以对各种应用程序进行手动测试
更适合生命周期较短的产品
适用于需求频繁变化的项目和GUI不断变化的产品
与自动化测试相比，手工测试的初始投资更便宜
手工测试可以执行临时测试
测试人员无需了解自动化工具
缺点；
手工测试在进行回归测试时，非常耗时。
与自动化测试相比，手动测试的可靠性较低，因为它是由人工进行的。所以总会容易出现错误和失误。
从长远来看，相比自动化测试，手工测试代价过于昂贵。
自动化测试的优点：
自动化测试执行速度更快
从长远来看，它比手动测试更利于企业长久发展
自动化测试得到结果更可靠
自动化测试更强大、更通用
它主要用于回归测试
可重复使用，可以记录自动化过程
它不需要人工干预。测试脚本可以在无人值守的情况下运行
它有助于增加测试覆盖率

缺点：
仅适合长期迭代更新的产品
自动化测试在最初搭建时成本会比较高
大多数收费的自动化工具费用都比较高
它有一些限制，例如处理验证码，获取 UI 的视觉方面，例如字体、颜色、大小等，不适合使用自动化测试

如何进行BUG的评测

通常bug管理中，severity分为四个等级blocker、critical、major、minor/trivial。
1、Blocker（崩溃）:阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

2、Critical（严重）:系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等。（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

3、Major（一般、界面、性能缺陷、兼容性）:功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。(该问题实际测试中存在最多，合理安排解决Bug，解决率关系版本的优化程度)

4、Minor/Trivial（次要、易用性及建议性问题）:界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

软件质量的6个特征

1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。
2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。
3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。
4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外"资源";这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。
5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。
6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。

请你说一说bug的周期，以及描述一下不同类别的bug

1、New:（新的）
当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

2、Assigned（已指派的）

当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

3、Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

4、Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

5、Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为Pending Reset”

6、Reset(再测试)

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

7、Closed（已关闭的）

如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”

8、Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

9、Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

10、Rejected(被拒绝的)

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

11、Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“

不同类别的bug（Bug类型）：

• 代码错误

• 界面优化

• 设计缺陷

• 配置相关

• 安装部署

• 安全相关

• 性能问题

• 标准规范

• 测试脚本

web测试和app测试的不同点

1.功能方面：
在流程和功能测试上是没有区别的，系统测试和一些细节可能会不一样。那么我们就要先来了解，web和app的区别：
web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。在系统测试的时候就会产生区别了。
首先从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
2.性能方面:
web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。
3.兼容性方面:
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。

4.相比较web测试，app更是多了一些专项测试：
　　一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
　　而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。

5.安装、卸载、更新：
　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。这里讲起来的话太多了，如果有疑问的同学可以评论或者给我留言。

6.界面操作：
　　app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。

软件测试实例

给你一个字符串，你怎么判断是不是ip地址？手写这段代码，并写出测试用例。

ip地址最多12加上三点最多15，最少7。用点进行分割进行遍历判断上个位置到改点的数字是否在0~255这个区间类。
测试用例就是根据这些写一些，等价类，边界值即可。

测试用例设计：一串数字，闰年的判别

根据百度百科得闰年的标准是：公历年份是4的倍数，且不是100的倍数的。
根据这个写代码，然后写一些等价类和边界值。

简单的用户登录界面过程都需要做那些分析

一：功能测试
1.输入正确的用户名和密码，点击提交按钮，验证是否可以正确登录。
2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
3.登录成功后能否能否跳转到正确的页面
4.用户名和密码，如果太短或者太长，应该怎么处理
5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
6.记住用户名的功能
7.登陆失败后，不能记录密码的功能
8.用户名和密码前后有空格的处理
9.密码是否非明文显示显示，使用星号圆点等符号代替。
10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
12.输入密码的时候，大写键盘开启的时候要有提示信息。
13.什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
1.布局是否合理，testbox和按钮是否整齐。
2.testbox和按钮的长度，高度是否复合要求。
3. 界面的设计风格是否与UI的设计风格统一。
4. 界面中的文字简洁易懂，没有错别字。
三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。
2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、可用性测试
1.是否可以全用键盘操作，是否有快捷键。
2. 输入用户名，密码后按回车，是否可以登陆。
3. 输入框能否可以以Tab键切换。
五、兼容性测试
1.不同浏览器下能否显示正常且功能正常（IE, Firefox, Chrome等）。
2.同种浏览器不同版本下能否显示正常且功能正常。
3.不同的平台是否能正常工作，比如Windows, Mac。
4.移动设备上是否正常工作，比如Iphone, Andriod。
5.不同的分辨率下显示是否正常。

请对这个系统做出测试用例：一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示

功能要求：
1.每个摄像头都能抓拍车牌；

2.每个摄像头抓拍到的车牌能正常交给系统处理；

3.系统能够正确识别车牌；

4.系统能够将识别出的车牌上传；

5.上传至网络的车牌能够正常展示出来；
一、功能测试
1.使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；

2.使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；

3.使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；

4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；

5.使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；

6.使用非车牌的其他图片，交由系统处理，检查系统能否识别；

7.在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；

8.构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；

9.检查上传至网络的车牌能否正常展示出来；

10.上传非车牌的其他内容的数据，检查能否正常显示出来。
二，性能测试
1.同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；

2.同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；

3.抓拍后，检查系统识别车牌的时间是否在需求要求的时间内；

4.模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；

5.模拟大量车牌同时上传，检查一定压力下能否上传成功。
三、安全性测试
1.检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。