2024最新！软件测试高频面试题&amp；基础知识点分享_软件测试面试题2024(1)_白盒子测试模式是在已知产品内部活动方式的情况下,测试产品的内部活动是否都符合-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84563933/article/details/138880293

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

13. 什么是黑盒测试?

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

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

14. 设计用例的方法、依据有那些?

白盒测试用例设计有如下方法:基本路径测试\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试。这时候依据就是详细设计说明书及其代码结构
黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
既可以用于黑盒测试，也可以用于白盒测试的方法的是（边界值分析）

15. 如果能够执行完美的黑盒测试，还需要进行白盒测试吗?(白盒与黑盒的区别)

答:任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能?
2、在接口上，输入是否能正确的接受?能否输出正确的结果?
3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
4、性能上是否能够满足要求?
5、是否有初始化或终止性错误?

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。

以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试，在未发现错误时，不能说明程序中没有错误。

16. 什么是静态测试?

答:通过运行程序测试软件称为动态测试.通过评审文档、阅读代码等方式测试软件称为静态测试,在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.
静态测试方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

17. 什么是回归测试?

答: 回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

18. 软件的缺陷等级应如何划分?

软件缺陷的等级可以用严重性和优先级来描述；

严重性：衡量缺陷对客户满意度影响的满意程度，分为

1,致命错误，可能导致本模块以及其他相关的模块异常，死机等问题；
常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误，如服务器500错误。
2.严重错误，问题局限在本模块，导致模块功能失常或异常退出；
常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
3.一般错误，模块功能部分失效；
常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。
4.建议模块，有问题提出人对测试模块的改进建议；

优先级：缺陷被修复的紧急程度；

1.立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；
2.高优先级（P2级）：缺陷严重，影响测试，需优先考虑；
3.正常排队（P3级）：缺陷需要正常排队等待修复；
4.低优先级（P4级）：缺陷可以在有时间的时候被纠正；

19. 针对缺陷采取怎样的管理措施?

1.要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2.根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
3.所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决;二是方便后面缺陷的分析(保证缺陷相关的信息准确，如龄期等)，这是缺陷状态的管理。
5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。

测试工具

20. 描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程

1.测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2.经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
3.还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
4.项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
5.若是，进行处理，resolved并给出解决方法。(可创建补丁附件及补充说明)
6.开发者收到Email信息后，判断是否为自己的修改范围。
7.若不是，重新reassigned分配给项目组长或应该分配的开发者。
8.测试人员查询开发者已修改的bug，进行重新测试。

21. 请说一下手动测试与自动化测试的优缺点

手工测试缺点：
1、重复的手工回归测试，代价昂贵、容易出错。
2、依赖于软件测试人员的能力。
手工测试优点：
1、测试人员具有经验和对错误的猜测能力。
2、测试人员具有审美能力和心理体验。
3、测试人员具有是非判断和逻辑推理能力。
自动化测试的优点：
1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
2、可以运行更多更繁琐的测试。是可以在较少的时间内运行更多的测试。
3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
自动化测试的缺点：
1、不能取代手工测试
2、手工测试比自动测试发现的缺陷更多
3、对测试质量的依赖性极大
4、测试自动化不能提高有效性
5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
6、工具本身并无想像力

22. 你觉得测试和开发需要怎么结合才能使软件的质量得到更好的保障

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

23. 请问你觉得测试项目具体工作是什么？

1.搭建测试环境
2.撰写测试用例
3.执行测试用例
4.写测试计划，测试报告
5.测试，并提交BUG表单
6.跟踪bug修改情况
7.执行自动化测试，编写脚本，执行，分析，报告
8.进行性能测试，压力测试等其他测试，执行，分析，调优，报告

24. 请你说一下软件质量的六个特征

按照软件质量国家标准GB-T8566–2001G，软件质量可以用下列特征来评价：

功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
可维护特征：与进行指定的修改所需的努力有关的一组属性。
可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

25. 描述测试工具的功能？

LoadRunner-负载压力测试：预测系统性能。
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
Junit：白盒测试工具：针对代码测试
测试管理工具：对测试需求、计划、用例、实施进行管理
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN

测试实例设计

26. 请你说一下app性能测试的指标

1、内存：内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、中等规格、满规格。

空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。
内存测试中存在很多测试子项，清单如下：
●空闲状态下的应用内存消耗；
●中等规格状态下的应用内存消耗；
●满规格状态下的应用内存消耗；
●应用内存峰值；
●应用内存泄露；
●应用是否常驻内存；
●压力测试后的内存使用。
2、CPU：
使用Android提供的view plaincopy在CODE上查看代码片派生到我的代码片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt来获取；
使用top命令view plaincopy在CODE上查看代码片派生到我的代码片
adbshell top |grep packagename>/address/CPU.txt来获取。
3、流量：
网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。
流量测试包括以下测试项：
应用首次启动流量提示；
应用后台连续运行2小时的流量值；
应用高负荷运行的流量峰值。
4、电量：
●测试手机安装目标APK前后待机功耗无明显差异；
●常见使用场景中能够正常进入待机，待机电流在正常范围内；
●长时间连续使用应用无异常耗电现象。
5、启动速度：
第一类：首次启动–应用首次启动所花费的时间；
第二类：非首次启动–应用非首次启动所花费的时间；
第三类：应用界面切换–应用界面内切换所花费的时间。
6、滑动速度、界面切换速度
7、与服务器交互的网络速度

27. 请你说一说app测试的工具

功能测试自动化
a) 轻量接口自动化测试
jmeter，
b) APP UI层面的自动化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator，
iOS:基于Instrument的iOS UI自动化，
性能测试
a) Web前端性能测试
网络抓包工具：Wireshark
网页文件大小
webpagetest
pagespeed insight
chrome adb
b) APP端性能测试
Android内存占用分析：MAT
iOS内存问题分析：ARC模式
Android WebView性能分析：
iOS WebView性能分析
c) 后台服务性能测试
负载，压力，耐久性
可拓展性，基准
工具：apacheAB，Jmeter，LoadRunner，
专项测试
a) 兼容性测试
手工测试：操作系统，分辨率，rom，网络类型
云平台：testin，脚本编写，Android。
b) 流量测试
Android自带的流量管理，
iOS自带的Network
tcpdump抓包
WiFi代理抓包：Fiddler
流量节省方法：压缩数据，json优于xml；WebP优于传统的JPG，PNG；控制访问的频次；只获取必要的数据；缓存；
c) 电量测试
基于测试设备的方法，购买电量表进行测试。
GSam Battery Monitoe Pro
iOS基于Instrument Energy工具
d) 弱网络测试
手机自带的网络状况模拟工具
基于代理的弱网络的模拟:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner

28. 请你说一说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类型
• 代码错误
• 界面优化
• 设计缺陷
• 配置相关
• 安装部署
• 安全相关
• 性能问题
• 标准规范
• 测试脚本
• 其他

29. 请问你怎么测试网络协议

协议测试包括四种类型的测试
1、一致性测试：检测协议实现本身与协议规范的符合程度
2、互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
3、性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度，
4、健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断。

30. 请你说一说简单用户界面登陆过程都需要做哪些分析

一、功能测试
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. 同一用户能否在多台机器上登录。

五、可用性测试

是否可以全用键盘操作，是否有快捷键。
输入用户名，密码后按回车，是否可以登陆。
输入框能否可以以Tab键切换。

六、兼容性测试
1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同种浏览器不同版本下能否显示正常且功能正常。