代码随想录八股训练营 | 面试高频八股（测开部分）

Q1. 你对测试/测开这个岗位怎么理解的

1. 回答思路

测试的职责 → 测试的目的 → 测试需要的能力

2. 答案

1. 我认为测试/测开不仅仅是找出错误，而且还包括验证软件的功能、性能、可靠性以及用户体
   验等方面，通过与开发、产品和运维紧密合作，确保软件产品的质量。

2. 测试可以提前发现和修复缺陷，为开发团队提供改进产品的机会，减少未来的维护成本。

3. 测试开发（测开）不仅需要测试技能，还需要编程能力和对开发流程的理解，通常还作为开发和业务团队之间沟通的桥梁，确保需求被正确理解和实施。

Q2. 你觉得一个测试/测开应该具备哪些知识和能力？

1. 回答思路

编程、测试基本知识、如何分析需求测试和设计测试用例、常用测试工具

2. 答案

知识

• 编程技能：测试人员需要掌握至少一种编程语言，Java、Python，能够编写一些自动化测试脚本和工具。

• 掌握测试基本知识，比如理解不同类型的测试，如单元测试、集成测试、系统测试和验收测试，掌握黑盒测试和白盒测试的原理和适用场景。

• 知道如何进行测试需求分析，并能够设计有效的测试用例和测试计划。

• 熟悉常用的的测试工具和框架，例如Selenium，JMeter等。

能力

• 分析能力：测试开发首先要能够理解复杂的软件系统和业务需求，并设计有效的测试用例。

• 技术能力：对于测试开发职位，编程能力也是必要的，测试开发要求测试人员了解不同的编程语言和测试框架，能够编写自动化测试脚本。

• 细节和认真观察的能力：测试要对细节高度敏感，善于发现bug。

• 沟通能力：要与开发团队、产品经理进行沟通，确保测试的结果被正确传达。

• 学习能力：测试是一个不断发展的领域，需要学习相关的测试知识和业务知识。

• 解决问题的能力：遇到问题时，能够有效地分析问题根源并提出解决方案。

Q3. 为什么选择做测试/测开，而不是开发呢？

1. 回答思路

测开是测试和开发的工作都在做，用户角度考虑，另一方面项目中的角色重要程度，要求知识面广。

2. 答案

首先，我认为的测开是测试和开发工作都在做的。一方面，据我了解，在近几年，国内对软件测试越来越重视，并且从用户角度来说，对于同类产品，可能会更加注重产品的质量和服务，所以我觉得测试的发展前景是非常好的。
其次，测试在一个项目开发的过程中是非常重要的一环。测试人员的责任非常大，责任越大成就感就越大。我很喜欢这样的工作。另一方面，测开还有一部分开发工作，无论是自动化脚本还是测试工具或框架，都提高了测试的效率，为质量效率保证工作提供了有力的保障。并且测开的所需技术广度也是很高，所以我认为测开会激发我对这个岗位的热爱和持续学习的态度。（并且来说，我目前具备了一些测开所必备的理论知识和技能并且还在不断地学习中，我认为我可以较快地胜任这个岗位。）

Q4. 软件测试分为哪几个阶段？

1. 回答思路

功能 → 单元 → 集成 → 系统 → 回归 → 性能 → 验收(Alpha Beta)

2. 答案

1. 功能测试：检查软件的各项功能是否按照需求规格书执行，包括用户界面、数据库、安全性、功能等。

2. 单元测试：测试软件中最小的可测试部分，验证这些单元在各种条件下都按预期工作

3. 集成测试：测试多个单元、模块或组件协同工作时是否能正常运行。

4. 系统测试：测试完整的、集成的软件系统来评估系统的符合度。通常包括功能性和非功能性测试。

5. 回归测试：在发生修改之后重新测试先前的测试用例以保证修改的正确性。

6. 性能测试：检查软件的速度、响应时间、稳定性、资源消耗等性能指标。包括负载测试、压力测试和稳定性测试。

7. 验收测试：确定软件是否满足其业务需求。验收测试是软件交付之前的最后一阶段测试。验收测试包括 Alpha 测试和 Beta 测试。

   • Alpha 测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。

   • Beta 测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件

Q5. 讲一下你们的测试流程

1. 回答思路

需求分析 → 制定测试计划 → 编写测试用例 → 测试用例评审 → 搭建环境，执行测试，记录bug → 回归测试 → 性能测试 → 预生产环境测试 → 撰写测试报告 → 总结与复盘

2. 答案

1. 需求分析：测试首先要对软件需求有着深入的理解，所以我们会开需求评审会议，分析和讨论需求。

2. 制定测试计划：明确测试的范围、方法、资源分配、时间表和目标。

3. 测试用例设计：基于测试计划，设计详细的测试用例。这些用例应该覆盖所有功能点，包括正常情况和边界情况的测试。

4. 测试用例评审

5. 搭建和配置适合的测试环境，执行测试用例，记录测试结果（找 bug), 将在测试过程中发现的缺陷报告给开发团队

6. 回归测试：每当代码发生更改后，执行回归测试以确保新的更改没有破坏现有的功能

7. 性能测试：评估系统的响应时间、稳定性和扩展性。

8. 部署项目到预生产环境，在预生产环境测试

9. 编写测试报告，总结测试活动的结果，包括测试覆盖率、发现的缺陷和未解决的问题。

10. 项目上线后，根据反馈进行复盘和总结。

Q6. 什么是回归测试，如何做回归测试?

1. 回答思路

回归测试功能与目的 → 测试流程（确定测试范围 → 选择测试用例 → 执行测试）

2. 答案

回归测试是一种软件测试类型，旨在确保软件在经过修改或升级后，原有功能仍然按预期工作，并且新引入的更改没有引入新的错误。

执行回归测试主要包括以下步骤：
        1. 确定测试范围：确定哪些功能或模块需要重新测试。
        2. 选择测试用例：选择或更新相关的测试用例来覆盖更改的部分。
        3. 执行测试：运行测试用例并记录结果。

Q7. 你对单元测试和集成测试有哪些了解

1. 回答思路

单元测试最小可测部分，通常用自动化工具实现；集成测试多个模块集成后，单元测试之后系统测试之前。

2. 答案

1. 单元测试是针对软件的最小可测试部分（通常是一个函数、方法或类）进行的测试。通常在编写或修改代码后立即进行，以快速发现和修正代码中的错误，常用的工具包括JUnit（Java）、PyTest（Python）等。

2. 集成测试是在多个模块或组件被集成在一起后进行的测试，用来验证不同模块之间的接口和交互是否按预期工作，通常使用集成测试框架，比如Postman（API测试）、Selenium（Web应用集成测试）来进行。

Q8. 系统测试和集成测试的区别和使用场景是什么

1. 回答思路

系统测试定义 → 集成测试定义 → 两个使用场景

2. 答案

1. 系统测试是在整个软件系统完成集成后进行的测试。它的目的是验证整个系统是否符合指定的需求，关注整个系统的行为，测试涵盖所有集成的模块，以确保它们作为一个完整的系统正确地协同工作，包含功能性测试（如功能完整性、用户界面、用户流程）和非功能性测试（如性能、安全性、兼容性）。

2. 集成测试是在多个软件模块或组件被集成在一起时进行的测试。它的目的是验证这些模块或组件之间的交互，关注于模块之间的接口和交互。确保不同模块的数据交换和功能协作符合预期，主要用来检查数据传递、接口调用、异常处理等模块间交互的方面。

3. 集成测试通常在单元测试之后、系统测试之前进行，当整个应用开发接近完成时，进行系统测试。

Q9. 什么是黑盒测试和白盒测试

1. 回答思路

黑盒测试定义，使用范围，常用方法（等价类划分、边界值分析） → 白盒测试定义，适用范围，常用方法（路径、条件、循环、语句）

2. 答案

1. 黑盒测试，也被称为功能测试或行为测试，测试者只关注软件的输入和输出，不需要了解程序的内部实现，主要验证软件的功能是否符合用户需求和规格说明。常用的测试方法包括等价类划分、边界值分析、因果图法、状态转换测试、错误猜测等。

2. 白盒测试，也称为结构测试或透明盒测试，测试者需要了解程序的内部工作机制，包括代码、逻辑流程、内部结构，主要验证代码的逻辑路径、分支覆盖、循环、语句覆盖等，常用的测试方法包括路径覆盖、条件覆盖、循环覆盖、语句覆盖等，主要适用于单元测试和集成测试。

Q10. 说一下等价类划分和边界值分析法

1. 回答思路

等价类划分思想 → 等价类划分分类 → 边界值法定义

2. 答案

等价类划分：等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类划分认为如果一个测试用例在某个等价类中的一个值上通过测试，那么它在这个类中的其他值上也会通过，适用于输入数据较多的情况，有助于减少测试用例的数量并保证覆盖率。

• 有效等价类：符合规格说明的输入条件。

• 无效等价类：不符合规格说明的输入条件。

        通过 有效等价类 来验证系统的正确性，通过 无效等价类 来验证系统的鲁棒性。

边界值法：软件错误往往发生在输入或输出范围的边缘，所以边界值分析专注于测试输入数据的边界条件，而不是中间值，包括正常边界值（最大、最小值）和异常边界值（最大值+1、最小值-1），适用于测试那些对输入数据有明确范围或限制的功能。

Q11. 功能测试用例一般包含哪些内容

1. 回答思路

ID、优先级、标题、功能模块、目的、前置条件、测试步骤、测试数据、预期结果、实际结果、通过或失败标准、测试环境、备注信息、缺陷或问题ID

2. 答案

1. 测试用例ID：一个唯一标识符，用于区分和引用测试用例。

2. 用例优先级：该测试用例的优先执行程度。

3. 测试用例标题：简短描述测试用例的目的或主要功能。

4. 功能模块：指明此测试用例所属的软件功能模块或部分。

5. 测试目的/描述：对测试用例的目标和测试内容的详细描述。

6. 前置条件：执行测试用例之前需要满足的条件，如特定的系统状态或配置。

7. 测试步骤：详细描述如何执行测试，包括用户如何与系统交互，每一步应该输入什么数据，选择哪些选项等。

8. 测试数据：在测试中使用的具体数据，包括输入值和需要验证的输出值。

9. 预期结果：描述在成功执行测试步骤后预期的系统行为或输出。

10. 实际结果：在执行测试后记录的实际结果，用于与预期结果进行比较。

11. 通过/失败标准：定义何种条件下测试用例被认为是通过或失败。

12. 测试环境：描述执行测试用例所需的软件、硬件、网络配置等环境信息。

13. 备注信息：任何额外的信息，比如相关的依赖、特殊注意事项等。

14. 缺陷/问题ID：如果测试失败，关联的缺陷或问题的标识符。

Q12. 说一下设计测试用例有哪些方法

1. 回答思路

黑盒测试（等价类划分法、边界值分析法、因果图法、决策表测试、状态转换测试）
白盒测试（语句覆盖、分支覆盖、路径覆盖、条件覆盖、循环覆盖，玉芬寻条路）

2. 答案

黑盒测试方法：

• 等价类划分法：将输入数据划分为不同的等价类，每个等价类都有相似的行为。然后从每个等价类中选择测试用例。

• 边界值分析法：关注输入值的边界情况，测试接近边界值和边界之间的情况。

• 因果图法：使用因果图来识别和描述系统中各种因果关系，辅助设计测试用例。

• 决策表测试：创建决策表，列出不同的输入组合和相应的输出，确保所有可能的组合都得到测试。

• 状态转换测试：适用于有状态的系统，测试系统在不同状态下的行为和状态之间的转换。

白盒测试方法：

• 语句覆盖：确保每个源代码语句都至少执行一次。测试用例的目标是覆盖代码的所有语句。

• 分支覆盖：确保每个分支语句都至少执行一次，以测试代码中的条件语句。

• 路径覆盖：通过执行代码的所有可能路径来测试系统，包括所有可能的条件分支和循环。

• 条件覆盖：测试代码中条件表达式的所有可能取值，以确保所有条件的不同情况都被覆盖。

• 循环覆盖：确保测试覆盖了循环的不同情况，包括循环的入口、中间和退出。

Q13. 如何写测试用例

1. 回答思路

理清需求 → 参考过去 → 明确测试用例结构 → 明确输入输出及应用方法 → 根据特性补充测试用例 → 根据经验 → 总结提高

2. 答案

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

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

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

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

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

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

Q14. 如何提高用例的覆盖率，减少漏测

1. 回答思路

根据需求写文档 → 挖掘隐藏需求 → 考虑异常情况 → 多维度测试 → 用户角度 → 用例评审

2. 答案

1. 根据需求文档编写用例，确保每条需求都能被对应的用例覆盖

2. 要充分理解业务，挖掘隐形需求，并编写对应的用例

3. 除了正常的业务场景，多考虑一些异常的场景和数据

4. 要从多个维度对软件进行测试，功能、性能、安全等各方面来考虑

5. 多站在用户的角度去思考问题，模拟用户的使用场景

6. 组织用例评审

Q15. 为什么要做接口测试, 你是怎么测试接口的

1. 回答思路

为什么：验证功能性 → 检查数据交换 → 发现集成问题 → 提高稳定性与可靠性 → 早发现问题
怎么做：理解接口文档 → 编写测试用例 → 使用测试工具 → 验证结果

2. 答案

为什么要做接口测试

• 验证接口的功能性：确保接口按照预期的方式工作，能够接收正确的输入并返回正确的输出。

• 检查数据交换：确保接口能够正确地在不同组件之间传递数据。

• 发现集成问题：在开发过程中，不同组件可能独立开发，接口测试有助于发现这些组件在集成时可能出现的问题。

• 提高系统的稳定性和可靠性：通过接口测试可以确保系统的各个部分能够协同工作，从而提高整体的稳定性和可靠性。

• 安全性测试：接口测试还可以帮助发现潜在的安全漏洞，比如数据泄露或未授权访问。

• 性能测试：接口测试可以评估在高负载下接口的性能，确保系统在实际使用中能够满足性能要求。

• 文档验证：接口测试可以用来验证接口文档的准确性，确保开发人员和用户对接口有正确的理解。

• 兼容性测试：确保接口能够与不同的系统或版本兼容。

• 回归测试：在对接口进行更改后，接口测试可以确保这些更改没有破坏现有的功能。

• 早期发现问题：接口测试可以在开发周期的早期发现问题，从而减少修复这些问题的成本和时间。

怎么测试接口的

• 理解接口文档，了解接口的业务功能，请求方法、请求参数、响应结构、错误码以及对应的数据库存储

• 编写测试用例，涵盖正常的输入情况（验证接口的功能性）和异常的输入情况（验证接口的健壮性和错误处理

• 使用测试工具，比如 Postman 执行测试用例，观察响应是否符合预期，验证响应的状态码、响应体内容、响应时间等、

• 结果验证和报告，验证测试结果，并编写测试报告，记录发现的问题和测试结论。

Q16. 接口测试用例的编写需要注意哪些要点

1. 回答思路

明确接口规格 → 看返回值是否正常 → 接口逻辑和功能是否正常 → 数据库 → 性能测试 → 安全性

2. 答案

1. 明确接口规格：理解接口的功能、输入输出参数、数据格式、请求方法（如GET、POST、PUT、DELETE等）和预期的行为。

2. 返回值：各种情况下（正确的输入值和异常的输入值）下的响应内容是否正常。

3. 接口的业务逻辑和功能是否正常。

4. 数据库校验。

5. 性能测试（接口 TPS, 响应时间等）。

6. 安全性：敏感信息加密，权限控制等。

Q17. 你使用过哪些接口测试的工具

1. 回答思路

工具适用范围 → 熟悉度 → 使用经验 → 测试流程

2. 答案

• Postman: API测试工具，用于发送各种HTTP请求，易于使用，适合快速测试RESTful API，并且可以组织和分享API测试集合，也支持自动化测试脚本编写。
• Apifox: 集API设计、‌开发、‌测试于一体的协作工具, 功能强大，适合团队协作。

• JMeter: 主要用于性能测试和负载测试，但也可以用于API测试。

• Swagger UI: 用于设计、构建、文档化和测试REST API的工具

Q18. 接口测试流程

1. 回答思路

接口测试流程大体和功能测试流程一样（区别在于多了接口文档，使用工具执行测试）

2. 答案

1. 分析需求文档和 接口文档（URL、入参、返回值等）
2. 制定测试计划
3. 根据需求文档编写接口测试用例
4. 测试用例评审
5. 根据用例，使用接口测试工具执行测试
6. 提交bug、回归测试
7. 预生产环境测试
8. 输出接口测试报告
9. 上线

Q19. 性能测试中，一般关注哪些指标

1. 回答思路

性能测试目的 → TPS吞吐量、平均响应时间、并发用户数、错误率、内存占用、资源利用率

2. 答案

做性能测试的目标是，在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而分析出系统瓶颈，提高系统的稳定性。

• TPS 吞吐量: 系统在单位时间内处理请求的数量，代表了性能的好坏，TPS越高，性能越好

• 平均响应时间：接口从请求到响应、返回的时间。请求的平均消耗时间，时间越短，性能越好

• 并发用户数: 同一时间点请求服务器的用户数，支持的最大并发数。

• 错误率：失败的请求比例。

• 内存占用：内存开销。

• 资源使用率：CPU占用率、内存使用率、磁盘I/O、网络I/O。

Q20. 说一说你知道的自动化测试框架有哪些？

1. 回答思路

列举常见框架  → 框架特点 → 使用场景 → 优缺点 → 发展趋势

2. 答案

• Selenium：广泛用于Web应用的自动化测试，提供了丰富的API来模拟用户在浏览器中的操作，如点击、输入文本和选择下拉菜单等。它还支持各种浏览器和操作系统。

• Appium：用于移动应用程序的自动化测试框架，它支持iOS和Android平台上的原生、混合和移动Web应用程序。

• Junit: 用于Java应用程序的单元测试框架。它提供了一种编写可重复的测试用例的方法，并且能够自动运行这些测试用例并生成详细的测试报告。JUnit还支持参数化测试和测试套件，方便组织和管理大量的测试用例。

• TestNG：TestNG 是一个基于 Java 的测试框架，可以用于编写和运行各种类型的测试，包括单元测试、集成测试和端到端测试。它提供了丰富的注解和配置选项，支持并行执行和数据驱动测试，可以生成详细的测试报告。

• Robot Framework：Robot Framework 是一个通用的自动化测试框架，支持多种应用程序和平台。它使用关键字驱动的测试方法，支持多种编程语言和关键字库，并提供了丰富的测试库和插件，方便编写和管理测试用例。

• JMeter：主要用于性能测试，但也可用于自动化测试某些接口。

Q21. web自动化中元素定位方式有哪些？

1. 回答思路

ID 定位、名称属性定位、类名定位、连接文本定位、标签名定位、XPath 定位、CSS 选择器、部分链接文本定位

2. 答案

• ID定位：通过元素的ID属性进行定位，这是最简单和最快速的定位方式。

• 名称属性定位：通过元素的name属性进行定位，适用于input、form等元素。

• 类名定位：通过元素的class属性进行定位，当页面上有多个相同类名的元素时，可能需要结合其他属性或方法来进一步定位。

• 链接文本定位：通过链接的文本内容进行定位。

• 标签名定位：通过元素的标签名进行定位。

• XPath定位：XPath是一种在XML文档中查找信息的语言，它可以用来定位HTML中的元素。XPath支持非常复杂的定位方式，如通过元素的属性、文本内容、层级关系等。

• CSS选择器：CSS选择器是一种用于定位HTML元素的模式，它与CSS样式表中用于选择元素的语法相同。

• 部分链接文本定位：通过链接文本的一部分进行定位。

Q22. 定位不到元素的原因

1. 回答思路

定位错误 或 元素不在当前页

2. 答案

• 定位器选择错误

• 定位字符串错误

• 元素嵌套在 frame 当中

• 页面元素没有及时加载

• 元素在新窗口中

• 脚本流程与实际不符

• 元素不在当前页

Q23. 显式等待和隐式等待的区别

1. 回答思路

隐式等待定义 → 显示等待定义 → 区别（全局与条件、灵活与方便）

2. 答案

• 隐式等待：设置一个统一的等待时间，这个时间将应用于测试脚本中所有的元素定位操作。当你需要在整个测试脚本中对所有元素的查找操作应用统一的等待时间时使用。

• 显式等待：是针对特定条件的等待，直到某个条件成立或者超时。它提供了更多的灵活性，因为你可以根据需要等待不同的条件。通常与 WebDriverWait 和 expected_conditions 一起使用。当你需要等待某个特定元素或条件出现时使用，例如等待一个弹窗出现或者一个按钮变为可点击状态。

• 区别：

  • 隐式等待是全局性的，而显式等待是条件性的。

  • 显式等待提供了更高的灵活性，因为它允许你为不同的元素或条件设置不同的等待时间。

  • 显式等待通常比隐式等待更高效，因为它只在必要时等待，而不是对所有元素的查找操作都应用统一的等待时间。

  • 隐式等待在 WebDriverWait 初始化时设置一次，而显式等待则在需要等待特定条件时设置。

Q24. 你是如何处理 iframe 里面元素定位的?

1. 回答思路

切换到 ifream  → 定位元素 → 执行操作 → 切换回主文档

2. 答案

• 切换到 iframe：在定位 iframe 中的元素之前，首先需要将自动化工具的上下文切换到 iframe中。这通常可以通过发送一个切换命令来实现。

• 定位元素： 一旦切换到iframe，就可以使用常规的定位方法（如 ID、XPath、CSS选择器等）来定位元素了。

• 执行操作：定位到元素后，就可以执行所需的操作，如点击、输入文本、获取文本等。

• 切换回主文档：完成iframe中的操作后，通常需要切换回主文档的上下文，以便继续其他操作。

Q25. App 测试和 Web 测试有什么区别

1. 回答思路

系统架构、性能、兼容性、App特有的测试（异常场景、安装卸载更新、界面操作）

2. 答案

• 系统架构：Web 一般是b/s架构，只要更新了服务器端，客户端会同步更新。App 则是c/s 架构 只能用户更新，如果 App 下修改了服务器，意味着 客户端 用户使用的核心版本都要进行回归测试。
• 性能：Web 只需要检测响应时间、CPU、内存；App 还需要额外测试 GPU、流量、电量。
• 兼容：Web 一般是基于浏览器的，兼容性一般是选择不同的浏览器内核进行测试；App 测试兼容测试需要测试不同系统、分辨率、屏幕尺寸等。
• App 测试特有的：
  • 一些 异常场景 及 弱网测试。异常场景指中断、来电、短信、关机、重启等。弱网测试是 App测试中必须的，包括弱网 和 网络切换，弱网重点考虑回退和刷新是否会造成二次提交，需要测试丢包、延迟的处理机制，避免用户流失。
  • 安装卸载更新，除了常规的，还要考虑 强制更新、非强制更新等。
  • 界面操作，App 测试还要注意手势、横竖屏切换、多点触控、事件触发区域等。

Q26. 怎么测试APP的兼容性

1. 确定目标平台和设备：包括操作系统、设备型号、屏幕分辨率等。
2. 设计测试环境和工具；
3. 确定测试用例和场景：包括 App 的关键功能、界面、设备传感器、网络连接等
4. 执行兼容测试；
5. 验证 App 的功能完整性：确保在不同平台都能正常使用。
6. 观察和记录问题；
7. 性能和稳定性测试：包括启动时间、响应时间、内存占用、电量流量消耗等。
8. 回归测试；
9. 分析和报告问题；
10. 迭代测试和持续改进：随着新版本的发布和目标平台的变化，进行迭代的兼容性测试，并持续改进测试方法和流程，即使评估新设备和操作系统的兼容性。

Q27. App做过哪些专项测试

• 安全性测试：包括应用权限、数据存储、网络通信等方面的安全测试。
• 兼容性测试：包括不同设备、操作系统版本、屏幕尺寸、分辨率上的表现，还有新老版本兼容，确保新版本不会影响旧版本的使用。
• 性能测试：包括响应时间、内存使用、CPU 使用、电量消耗等。
• 流量测试：应用在不用场景下的流量消耗。
• 稳定性测试：使用 Monkey 测试，确保应用在长时间运行或高负载下的稳定性。
• 内存泄漏测试：连续操作是否存在内存泄漏。
• UI 测试：确保在不同设备上使用 UI 显示正确。
• 版本升级测试；
• 功耗测试；
• Monkey 测试；
• MonkeyTestUI 测试；
• 广播接收测试；
• 拒绝服务攻击检测；
• 权限提升测试。

Q28. 常用的测试工具有哪些？

自动化测试

• Selenium：用于自动化Web应用程序测试的工具，支持多种浏览器和多种编程语言。
• Appium：移动应用自动化测试框架。

接口测试

• Postman/Apifox: 用于API开发和测试的流行工具
• Swagger UI：用于设计、构建、文档化和测试REST API的工具。

性能测试

• JMeter：用于Web应用程序性能测试和压力测试的工具。
• LoadRunner：性能测试工具，模拟多用户并发。

单元测试

• Pytest：用于Python应用程序的测试框架，支持简单和复杂的测试场景。
• JUnit：用于Java应用程序的单元测试框架，支持自动化测试脚本的执行和报告生成。

抓包工具

• Fiddler：网络调试代理工具，用于捕获和分析HTTP/HTTPS流量。
• Wireshark：网络协议分析工具，用于深入分析网络数据包。

Q29. fiddler 的工作原理是什么?在项目测试过程中主要在哪些场景下使用？

1. 回答思路

2. 答案

fiddler 是在客户端和服务器之间起到一个代理作用，可以监听客户点和服务器的 HTTP 通信，把请求和相应的数据都抓下来，另外还可以左请求/响应拦截、修改报文 以及 弱网测试等。

应用场景：

• 当测试出 bug 时，通过 fiddler 抓包，分析 bug 是客户端还是服务器的问题；
• 做接口测试时，可以通过抓包获取接口的 入参 和 返回值，包括接口之间的数据关联；
• 当做弱网测试时，可以修改网络模拟参数，模拟出不同的网速；

Q30. Jmeter 做接口测试的流程

1. 通过借口文档 或 抓包，获取接口的 url 和参数；
2. 创建线程组、HTTP请求，根据接口地址设置相关的信息；
3. 根据测试用例情况，修改接口参数，调用接口；
4. 对接口返回值做判断

Q31. Jmeter 中常用的断言方式

• 响应断言：检查 HTTP 响应是否符合预期，检查响应消息是否包含特定文本。
• JSON 断言：检擦 JSON 响应是否包含特定键值对，JSON 结构是否符合预期模式。
• 断言持续时间：检查请求的响应时间是否在设定的阈值内。

Q32. 使用 Jmeter 如何做接口之间的数据关联

• 添加HTTP请求：在测试计划中添加两个或更多的HTTP请求，以便模拟接口之间的调用。
• 执行第一个请求：首先执行需要获取数据的HTTP请求。
• 提取响应数据：
  • 使用JMeter的“正则表达式提取器”或“JSON提取器”来从第一个请求的响应中提取所需的数据。
  • 配置提取器，指定要提取的数据的模式或路径。
• 存储提取的数据：提取器会将提取的数据存储在一个变量中。
• 使用提取的数据： 在后续的HTTP请求中，使用 ${变量名} 的方式来引用之前提取的数据。
• 配置数据关联：在需要使用关联数据的HTTP请求的参数中，使用 ${变量名} 来引用提取的数据。

Q33. 软件质量的六个特征

1. 回答思路

功能性、可靠性、效率、易用性、可维护性、可移植性

2. 答案

• 功能性：表示软件能够提供满足明确和隐含需求的功能。
• 可靠性：软件在各种条件下都能稳定运行，不出现意外故障。
• 效率：软件响应迅速，资源消耗合理，满足性能要求。
• 易用性：软件界面友好，用户容易理解和操作。
• 可维护性：在必要时能够有效地进行修正和改进软件的能力。
• 可移植性：表示软件能够从一个环境迁移到另一个环境的能力。

Q34. 在项目中如何保证软件质量？时间紧张如何开展测试工作呢？

1. 回答思路

how：整个团队一起努力。产品逻辑正确，设计满足要求，开发保证细节，测试验证逻辑
what：尽早介入，开发自测，回归可以做成自动化，调整优先级，加班。

2. 答案

如何保证软件质量

项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，在公司级别需要有一个规范的项目流程

• 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案
• 设计，满足产品表达的同时，保证设计的延续性
• 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循开发规范操作
• 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量

时间紧张如何做？

• 测试尽量提前介入，提前开展工作
• 要求开发自测，提高提测质量
• 对于重复执行的回归测试，如果可以的话，使用技术手段做成自动化，提高测试效率
• 根据模块和功能的重要性和优先级，合理安排测试顺序
• 有必要的话，向领导申请更多的测试资源和人力或者通过加班来追赶下进度

Q35. 没有需求文档，如何开展测试

1. 回答思路

分析用户界面、多沟通、其他形式文档、风险评估先测试关键功能

2. 答案

• 通过分析用户界面、观察系统输出和查看日志文件来理解现有系统的功能，或者分析竞争对手的产品了解需求。
• 与产品经理、开发人员、设计师和其他利益相关者进行沟通，了解软件的预期功能和目标。
• 检查是否有其他形式的文档，如设计文档、用户手册等。分析历史数据，如用户反馈、缺陷记录等，以发现潜在问题。
• 进行风险评估，确定哪些功能是关键的，哪些是次要的，并优先测试关键功能。
• 测试用例设计，并不断更新和完善测试计划。
• 使用自动化测试工具来帮助识别和记录软件的行为，尤其是在没有明确需求的情况下。
• 总之，一个原则：没有需求文档的情况下，自己多主动，去了解，去梳理，去反向推动。

Q36. bug的生命周期

1. 回答思路

新、分配、打开、已修复、待测试、再测试、已关闭、再打开、拒绝中、被拒绝、延期

2. 答案

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“

Q37. 如何定位bug 是给前端还是后端

1. 回答思路

复现问题 → 产看错误日志 → 分析客户端（前端）→ 分析服务端（后端）→ 验证网络通信

2. 答案

1. 复现问题：确保能够可靠地重现这个bug。记录重现bug的具体步骤、输入、环境设置等。
2. 查看错误日志：通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因
3. 分析客户端：使用开发者工具（如浏览器的开发者控制台）来检查网络请求、响应数据、控制台输出等，如果客户端收到的响应数据是正确的，但表现异常，可能是客户端问题
4. 分析服务端：检查服务端的处理逻辑。确保服务端正确处理了来自客户端的请求，并返回了正确的响应。如果服务端在处理请求时出现错误或返回了错误的数据，问题可能在服务端
5. 验证网络通信：还要确认客户端和服务端之间的网络通信是否正常。有的时候网络问题可能会导致错误。

Q38. 你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决？

1. 回答思路

明确不是bug理由 → 参照文档校验，和产品经理沟通 → 判断是否为bug

2. 答案

1. 告知开发bug的判断依据，同时明确开发说不是bug的理由。
2. 对开发的理由进行校验，校验依据
   • 参照需求文档
   • 跟产品经理进行沟通确认
3. 校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量

Q39. 给你一个页面，你如何测试？

1. 回答思路

功能测试 → UI 测试 → 性能测试 → 安全性测试 → 兼容性测试 → 易用性测试

2. 答案

1. 功能测试：检查页面的所有功能是否按预期工作，包括链接地址、表单提交和用户交互。
2. UI测试：验证页面的布局、颜色和字体是否符合设计要求。
3. 性能测试：评估页面加载时间和响应速度
4. 安全性测试：通过输入特殊字符，sql注入，脚本注入测试等方式检查页面的输入验证（比如信息提交是否验证，数据传输是否加密），从而发现潜在的安全漏洞。
5. 兼容性测试：在不同的浏览器和设备上测试页面，确保兼容性。
6. 易用性测试：模拟用户操作，确保用户能够顺畅地完成任务。

Q40. 说一说用户界面登录过程都需要做哪些测试

1. 回答思路

功能测试 → UI 测试 → 性能测试 → 安全性测试 → 兼容性测试 → 易用性测试

2. 答案

1. 功能测试
   正确用户名密码，能否正常登录；
   错误用户名密码，是否会提示错误信息；
   什么都不输入点击登录
   用户名密码太长或太短；
   用户名有特殊字符；
   记录用户名功能；
   记录密码功能；
   用户名密码前后有空格；
   是否有非明文提示；
   验证码考虑是否容易辨认，色盲色弱；
   输入密码时，开启大写键盘提示。
2. UI 测试
   布局是否合理；
   界面有无错别字；
   风格是否统一。
3. 性能测试
   打开登陆界面，需要时间是否在请求时间内；
   登陆成功后跳转时间；
   大量用户同时登录压力测试。
4. 安全性测试
   登陆成功后的Cookie是否容易被盗取；
   用户名密码是否加密；
   用户名密码输入框是否屏蔽 SQL 注入攻击；
   错误登录次数；
   是否支持多端登录；
   是否支持同一设备双开。
5. 兼容性测试
   是否可以全键盘操作；
   回车是否可以登录；
   输入框能否 Tab 切换。
6. 易用性测试
   不同浏览器能否正常显示；
   不同版本把能否正常显示；
   移动设备能否正常工作；
   不同平台；
   不同分辨率

Q41. 如果做一个杯子的检测，你怎么测试

1. 功能测试
2. UI 测试
3. 性能测试
4. 安全性测试
5. 兼容性测试
6. 易用性测试

Q42. 微信发红包，你怎么测试

1. 功能测试
2. UI 测试
3. 性能测试
4. 安全性测试
5. 兼容性测试
6. 易用性测试

Q43. 微信朋友圈，你怎么测试

1. 功能测试
2. UI 测试
3. 性能测试
4. 安全性测试
5. 兼容性测试
6. 易用性测试

Q44. 购物车测试用例设计？

1. 功能测试
2. UI 测试
3. 性能测试
4. 安全性测试
5. 兼容性测试
6. 易用性测试

Q45. Python都有那些数据类型

• 数值类型：int, float
• 布尔类型
• 字符串：
• 列表：
• 元组：
• 字典：
• 集合：自动去重

Q46. 元组和列表的区别

• 都是序列，可以存储不同类型数据，都可以通过索引访问
• 元组不可以改，用（）；列表可以改，用 [ ]
• 列表适用于存储需要修改的数据集合。元组适用于存储确保数据不会被修改的情况，比如字典的key。

Q47. 迭代器和生成器有什么区别？

迭代器：有__iter__() 和 __next__() 方法的对象叫做迭代器。迭代器是一个类，用于任何可迭代对象。

生成器：是一种特殊的迭代器，是一个函数，通过使用 yield 关键字在函数中创建，从 yield 处退出，从 yield 处进入。

Q48. 装饰器有什么用

装饰器允许在不修改原有函数或类定义的情况下，增加函数或类的功能。装饰器本质上是一个函数，它接收一个函数作为参数并返回一个新的函数。装饰器可以用于多种场景：

1. 日志记录：在函数执行前后添加日志记录，便于调试和监控。
2. 性能测试：测量函数执行时间，帮助分析性能瓶颈。
3. 权限校验：在函数执行前检查用户权限，确保安全性。
4. 缓存：对函数结果进行缓存，避免重复计算，提高效率。
5. 参数校验：在函数执行前校验输入参数，确保数据的正确性。
6. 事务处理：在数据库操作前后自动开始和提交事务。
7. 异步处理：将同步函数转换为异步函数，提高并发性能。
8. 重试机制：在函数执行失败时自动重试。
9. 装饰器组合：将多个装饰器组合使用，实现复杂的功能扩展。