软件测试功能 / 数据库 /linux/ 接口 / 自动化 / 测试开发面试真题解析

软件测试功能/数据库/linux/接口/自动化/测试开发面试真题解析大家好，我是阿沐，我来了啊~功能测试：1、你的测试职业发展是什么？

测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前 2 年积累测试项目经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。

然后学习自动化测试，编程语言，测试开发技术，能够为测试圈带来一些贡献

2、你认为测试人员需要具备哪些素质？

做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。

持有一颗怀疑的心，不能轻易相信开发自测过

耐心加技术是测试人员在企业中生存之道

掌握基本的测试基础理论本着找出软件存在的问题的态度进行测试，不要以挑刺的形象出现可熟练阅读需求规格说明书等文档以用户的观点看问题有强烈的质量意识细心和责任心良好的有效的沟通方式(与开发人员及客户)具有以往的测试经验能够及时准确的判断出高危险区在何处

3、软件测试的目的是什么？

软件测试的目的并不是证明软件没有错误，而是找出软件产品中的错误，使软件尽可能的符合用户的要求。

当然软件测试是不可能找出全部错误的。

4、测试分为哪几个阶段？

一般来说分为 5 个阶段：单元测试、集成测试、确认测试、系统测试、验收测试

5、结合你以前的学习和工作经验，你认为如何做好测试，做好软件测试的一些关键点

具备较强的需求分析能力，测试人员必须非常熟悉系统功能和业务测试要有计划，而且测试方案要和整个项目计划协调好必须实现编写测试用例，测试执行阶段必须根据测试用例进行

易用性，功能，分支，边界，性能等功能性和非功能性需求都要进行测试

对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据

定位 bug 要尽量准确，提高与开发人员协调的效率，尽早的解决 bug 充实自己的技能：不仅熟练掌握软件测试基础知识和理论，还要学习编程语言、数据库、linux 脚本，自动化测试、性能测试技术 6、谈谈你之前测试的项目流程，在每个阶段的输出有哪些？

a 新功能：首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点；(输出：数据库表设计；接口设计，需求文档,提测时间)

b.然后开发就排期进行开发，主管开始编写测试计划，对我们进行任务分配。(输出：：测试计划)

c.我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本；（输出：测试用例）

d.提测（测试去 Jenkins 部署构建）：开发人员版本编译完成后，我们会先进行预测，主要对主功能业务进行测试，接口测试

如果主业务流程不通过，直接返回给开发进行修改。预测通过，依据测试用例进行系统测试。测试过程中，提交 bug，跟踪 bug，进行回归测试直至不存在严重 bug，满足用户需求，（输出：测试报告）

e.产品发布上线后，关注 web 是否正常运行，要进行常规的维护性测试。回归测试

（输出：上线记录，上线的新功能）

7、怎样写测试计划和编写测试用例？

简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础

2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的 bug 情况

3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例

4、找到需求相关的一些特性，补充测试用例

5、根据自己的经验分析遗漏的测试场景

6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例

7、书写格式一定要清晰

广告

8、为什要在一个团队中开展测试工作？

因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量认证，这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

9、你所熟悉的软件测试类型有哪些?

测试类型有：功能测试、性能测试、界面测试

功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象

区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没有问题的，然后再考虑性能的问题。

10、黑盒测试，编写测试用例方法有哪些？

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

11.请说一下白盒测试是什么，编写测试用例方法有哪些？

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。

白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。

常用白盒测试方法：

静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。

动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：

1.语句覆盖每条语句至少执行一次。

2.判定覆盖每个判定的每个分支至少执行一次。

3.条件覆盖每个判定的每个条件应取到各种可能的值。

4.判定/条件覆盖同时满足判定覆盖条件覆盖。

5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

6.路径覆盖使程序中每一条可能的路径至少执行一次。

12、Beta 测试与 alpha 测试的区别？

答：alpha 测试是公司内部在模拟实际操作环境下进行的一种验收，公司内部会组织内部员工进行的测试，alpha 测试不能由程序员或者测试完成。

Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试，beta 测试不能由程序员或测试员完成。

13、写过测试计划或者是测试报告么？测试计划包括哪些主要步骤和信息？测试报告包括哪些内容？

测试报告交付文档有哪些？

答：写过；1、测试计划包括：项目信息、参与文档、测试范围、测试策略、测试时间人员安排、测试环境；2、测试报告包含：项目背景、参考资料、测试范围、测试结果及缺陷分析、测试结论与建议，风险评估；3、交付文档：主要是测试用例、测试计划、测试报告。

14、对于重现率不高的 BUG 怎么处理？

先在出现问题的环境上尽量重现，保持浏览器环境、出现问题的特定账号等的一致，多次尝试仍然不能重现，也要记录到 bug 平台，将出现问题的特征步骤尽量描述清楚，附带问题截图及日志截图、注明偶现；如果项目时间允许，bug 等级高，需要开发协助重现；如果时间不允许，记录到 BUG 平台后续在跟进。

15、bug 的生命周期？

答：Bug 的生命周期，就是一个 bug 被发现到这个 bug 被关闭的过程，生命周期中一般缺陷状态：新建、指派、已解决、待验、关闭

如果待验证的 bug 在验证是没有解决好，我们需要重新打开（激活）→指派→已解决→待验，循环这个过程，中间其他状态：重新打开、拒绝、延期等

16、说一说 bug 的类型

Bug 类型

• 代码错误 界面优化 设计缺陷 配置相关 安装部署 安全相关 性能问题 标准规范 测试脚本 其他

17、当你提了一个 bug，开发认为这不是 bug，怎么处理？

答：首先确认开发环境是否跟自己测试环境一致，确认在测试环境能重现，如果确认是缺陷跟开发保持有效沟通，如果是级别较低的建议性 bug，可以先记录到 bug 平台，先保留沟通。如果是 bug 级别较高的问题，对应需求文档的预期结果跟开发说明，更有说服力；耐心讲解 BUG 的危害，不行就找产品确认，确实是 BUG 注明情况并再次指派给开发

18、有没有你印象深刻的 bug，bug 的原因？

答：身份证末尾 X 结尾的， 实名认证显示成功，但是在后面提现的时候，会报错，后面发现是保存到库里面的，都是小写 X 的，导致提现这边不识别，印象深刻的原因是因为花了一定的时间去找到这个 bug，并且自己尝试定位到原因，所以印象深刻。

19.作为测试工程师对需求分析的理解？（用户场景）

a.了解需求背景及商业价值

明确了解背景，为什么要做这个需求，明白需求存在什么样的商业价值后，才更明确该站在用户哪个角度去判断考虑该需求

b.站在用户角度去分析需求

产品提出的功能，站在真实的用户角度判断该需求使用对用户来说使用起来是否顺畅，操作路径是否多且复杂存在冗余，有什么风险
  显性需求：产品明确提出的需求
  隐性需求：明确需求背后可能存在的需求（异常场景）
  功能性需求：显性及隐形需求里面相关业务
  非功能性需求：用户体验，性能，可靠性，安全性，可维护性，可继承性

c.站在产品的实现角度去分析该需求

该需求对继承性需求在逻辑上是否存在冲突，原有逻辑是否存在冲突，遗漏

d.站在项目的角度去分析该需求

需求拆解的是否足够细，是否可再拆解，是否可测试，优先级如何，有什么风险

20.你在浏览器打开一个 web 项目网址，中间发生了什么？

网络请求，域名解析、请求后端接口，获取接口响应值，根据数据展示，关闭请求

1、DNS 解析

2、TCP 连接

3、发送 HTTP 请求

4、服务器处理请求并返回 HTTP 报文（apach，tomcat。nginx）

5、浏览器解析渲染页面

6、连接结束

21.如何分析一个 bug 是前端还是后端的问题？

检查接口，前端和后台之间是通过接口文件相互联系的，需要查看接口文件

检查请求的数据是什么，反馈的数据又是什么

页面可以直接 F12，或者抓包查看。如果发送的数据是正确的，但是后台反馈的数据是不符合需求的，那就是后台的问题；如果前端没有请求接口或请求的时候发送数据与需求不符，那这个时候就是前端的问题了。

22、V 模型和 W 模型

测试和开发应该按照 W 模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。

在 V 模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。V 模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。

相对于 V 模型，W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。W 模型由两个 V 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W 模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W 模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

W 模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。

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

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

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

3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。

系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

24、请你说一说 web 测试和 app 测试的不同点系统架构方面：

web 项目，一般都是 b/s 架构，基于浏览器的

app 项目，则是 c/s 的，必须要有客户端，用户需要安装客户端。

web 测试只要更新了服务器端，客户端就会同步会更新。App 项目则需要客户端和服务器都更新。

性能方面:

web 页面主要会关注响应时间

而 app 则还需要关心流量、电量、CPU、GPU、Memory 这些。

它们服务端的性能没区别，都是一台服务器。

兼容方面：

web 是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容

app 测试则要看分辨率，屏幕尺寸，还要看设备系统。

web 测试是基于浏览器的所以不必考虑安装卸载。

而 app 是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 。

此外 APP 还有一些专项测试：如网络、适配性。

25 请你说一说简单用户界面登陆过程都需要做哪些分析参考回答：一、功能测试

1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。

2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。

3.登录成功后能否能否跳转到正确的页面

4.用户名和密码，如果太短或者太长，应该怎么处理

5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况

6.记住用户名的功能

7.登陆失败后，不能记录密码的功能

8.用户名和密码前后有空格的处理

9.密码是否非明文显示显示，使用星号圆点等符号代替。

10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用

11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确

12.输入密码的时候，大写键盘开启的时候要有提示信息。

13.什么都不输入，点击提交按钮，检查提示信息。

二、界面测试

1.布局是否合理，testbox 和按钮是否整齐。

2.testbox 和按钮的长度，高度是否复合要求。

3. 界面的设计风格是否与 UI 的设计风格统一。

4. 界面中的文字简洁易懂，没有错别字。

三、性能测试

1.打开登录页面，需要的时间是否在需求要求的时间内。

2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。

3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

四、安全性测试

1.登录成功后生成的 Cookie，是否是 httponly (否则容易被脚本盗取)。

2.用户名和密码是否通过加密的方式，发送给 Web 服务器。

3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用 javascript 验证。

4.用户名和密码的输入框，应该屏蔽 SQL 注入攻击。

5.用户名和密码的的输入框，应该禁止输入脚本 （防止 XSS 攻击）。

6.防止暴力破解，检测是否有错误登陆的次数限制。

7. 是否支持多用户在同一机器上登录。

8. 同一用户能否在多台机器上登录。

五、可用性测试

1. 是否可以全用键盘操作，是否有快捷键。

2. 输入用户名，密码后按回车，是否可以登陆。

3. 输入框能否可以以 Tab 键切换。

六、兼容性测试

1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。

2.同种浏览器不同版本下能否显示正常且功能正常。

2.不同的平台是否能正常工作，比如 Windows, Mac。

3.移动设备上是否正常工作，比如 Iphone, Andriod。

4.不同的分辨率下显示是否正常。

七、本地化测试

1. 不同语言环境下，页面的显示是否正确。

26.如果做一个杯子的检测，你如何测试参考回答：1.功能

（1）水倒水杯容量的一半

（2）水倒规定的安全线

（4）水杯容量刻度与其他水杯一致

（5）盖子拧紧水倒不出来

（6）烫手验证

2.性能

（1）使用最大次数或时间

（2）掉地上不易损坏

（3）盖子拧到什么程度水倒不出来

（4）保温时间长

（5）杯子的耐热性

（6）杯子的耐寒性

（7）长时间放置水不会漏

（8）杯子上放置重物达到什么程度杯子会被损坏

3.界面

（1）外观完整、美观

（2）大小与设计一样（高、宽、容量、直径）

（3）拿着舒服

（4）材质与设计一样

（5）杯子上的图案掉落

（6）图案遇水溶解

4.安全

（1）杯子使用的材质毒或细菌的验证

（2）高温材质释放毒性

（3）低温材质释放毒性

5.易用性

（1）倒水方便

（2）喝水方便

（3）携带方便

（4）使用简单，容易操作

（5）防滑措施

6.兼容性

（1）杯子能够容纳果汁、白水、酒精、汽油等。

7.震动测试

（1）杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。

8.可移植性

（1）杯子在不同地方、温度环境下都可以正常使用。

27.请你来说一下购物车的测试用例参考回答：界面测试

• 界面布局、排版是否合理；文字是否显示清晰；不同卖家的商品是否区分明显。

2.功能测试

未登录时：

• 将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加；

• 点击购物车菜单，页面跳转到登录页面。

登录后：

• 所有链接是否跳转正确；

• 商品是否可以成功加入购物车；

• 购物车商品总数是否有限制；

• 商品总数是否正确；

• 全选功能是否好用；

• 删除功能是否好用；

• 填写委托单功能是否好用；

• 委托单中填写的价格是否正确显示；

• 价格总计是否正确；

• 商品文字太长时是否显示完整；

• 店铺名字太长时是否显示完整；

• 创新券商品是否打标；

• 购物车中下架的商品是否有特殊标识；

• 新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；

• 是否支持 TAB、ENTER 等快捷键；

• 商品删除后商品总数是否减少；

• 购物车结算功能是否好用。

3.兼容性测试

• 不同浏览器测试。

4.易用性测试

• 删除功能是否有提示；是否有回到顶部的功能；商品过多时结算按钮是否可以浮动显示。

5.性能测试

• 压力测试；并发测试。

28.请你进行一下弱网模拟方法一：charles 弱网模拟

使用 chrome 的 webview 调试工具，缺点是只适用于 web 页面的弱网模拟。

方法三：iOS 手机自带 Network Link Conditioner 弱网模拟

iPhone 手机打开开发者选项，具体参考：

设置-开发者选项 > Network Link Conditioner 入口。

系统已经内置常见网络配置，也可以增加自定义配置。

具体配置参数：

in Bandwidth 下行带宽，即下行网络速度

In packet loss 下行丢包率

in delay 下行延迟，单位 ms

out bandwidth 上行带宽

out packet loss 上行丢包率

out delay 上行延迟

DNS delay DNS 解析延迟

protocol 支持 Any，IPV4、IPV6

interface 支持 Any，WI-Fi，cellular（蜂窝网）

文章首发于微信公众号：程序员阿沐，转载请注明出处！————————————————版权声明：本文为 CSDN 博主「软件测试阿沐」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/m0_60126160/article/details/119981903