测试开发常见面试题
谈一谈你对测试的理解？
Section titled “谈一谈你对测试的理解？”- 我认为测试不仅仅是找出错误，而且还包括验证软件的功能、性能、可靠性以及用户体验等方面，发现其中的问题并及时解决。
- 测试可以提前发现和修复缺陷，减少未来的维护成本，对于保障软件质量和提升用户满意度十分重要。
- 我了解多种测试方法，比如功能测试、性能测试、安全测试等，也知道多种测试工具的使用。
测试开发需要哪些知识？
Section titled “测试开发需要哪些知识？”- 编程技能：测试人员需要掌握至少一种编程语言，如 Java、Python，能够编写自动化测试脚本和工具。
- 测试基础知识：理解不同类型的测试，如单元测试、集成测试、系统测试和验收测试，掌握黑盒测试和白盒测试的原理与适用场景。
- 测试分析与设计能力：知道如何进行测试需求分析，并能够设计有效的测试用例和测试计划。
- 测试工具和框架：熟悉常用测试工具和框架，例如 Selenium、JMeter、Jenkins 等。
测试需要哪些能力？
Section titled “测试需要哪些能力？”- 分析能力：能够理解复杂的软件系统和业务需求，并设计有效的测试用例。
- 技术能力：对于测试开发岗位，编程能力是必要的，需要了解不同的编程语言和测试框架，能够编写自动化测试脚本。
- 细节观察能力：测试要对细节高度敏感，善于发现 Bug。
- 沟通能力：要与开发团队、产品经理进行沟通，确保测试结果被正确传达。
- 学习能力：测试是一个不断发展的领域，需要持续学习相关测试知识和业务知识。
- 解决问题的能力：遇到问题时，能够有效分析问题根源并提出解决方案。
讲一下你们的测试流程
Section titled “讲一下你们的测试流程”我参与项目和实习中的测试流程通常按照下面这些步骤进行：
- 需求分析：测试首先要对软件需求有深入理解，所以会参加需求评审会议，分析和讨论需求。
- 制定测试计划：明确测试范围、测试方法、资源分配、时间表和目标。
- 测试用例设计：基于测试计划，设计详细的测试用例，覆盖所有功能点，包括正常情况和边界情况。
- 测试用例评审
- 环境搭建与执行测试：搭建和配置合适的测试环境，执行测试用例，记录测试结果，发现 Bug 后提交给开发团队。
- 回归测试：每当代码发生更改后，执行回归测试，确保新的更改没有破坏现有功能。
- 性能测试：评估系统的响应时间、稳定性和扩展性。
- 预生产环境测试：将项目部署到预生产环境并进行测试。
- 编写测试报告：总结测试活动的结果，包括测试覆盖率、发现的缺陷和未解决的问题。
- 上线后复盘：项目上线后，根据反馈进行复盘和总结。
实际工作流程可能会根据公司的具体情况和项目特点有所不同。
针对测试流程，会输出哪些材料？
Section titled “针对测试流程，会输出哪些材料？”- 测试计划：描述整个测试过程的策略、范围、资源、时间表和目标。
- 测试用例：详细的步骤、预期结果和测试数据，用于验证软件功能是否符合需求。
- 测试脚本：自动化测试的脚本代码。
- 错误报告：测试过程中发现的缺陷，包括缺陷描述、重现步骤、影响范围和严重程度。
- 测试执行日志：记录测试执行的详细过程，包括测试用例的执行结果。
- 测试环境配置文档
- 测试报告：总结整个测试周期的活动、发现的缺陷、测试覆盖率和最终评估结果。
请你说一下测试的常用方法
Section titled “请你说一下测试的常用方法”- 功能测试：检查软件各项功能是否按照需求规格说明执行，包括用户界面、数据库、安全性、功能等。
- 单元测试：测试软件中最小的可测试部分，验证这些单元在各种条件下都按预期工作。
- 集成测试：测试多个单元、模块或组件协同工作时是否能正常运行。
- 系统测试：测试完整的、集成的软件系统来评估系统的符合度，通常包括功能性和非功能性测试。
- 回归测试：在发生修改之后重新测试先前的测试用例，以保证修改的正确性。
- 性能测试：检查软件的速度、响应时间、稳定性、资源消耗等性能指标，包括负载测试、压力测试和稳定性测试。
- 验收测试：确定软件是否满足业务需求，是软件交付前的最后一阶段测试。
验收测试包括
Section titled “验收测试包括”- Alpha 测试：由用户在开发者场所进行，在受控环境中完成。
- Beta 测试：由最终用户在实际使用场景中进行，开发者通常不在现场，用户记录问题并反馈给开发者，开发者据此进行最后修改并准备正式发布。
你对单元测试和集成测试有哪些了解？
Section titled “你对单元测试和集成测试有哪些了解？”- 单元测试：针对软件的最小可测试部分（通常是函数、方法或类）进行测试。通常在编写或修改代码后立即进行，以快速发现和修正代码中的错误。常用工具有 JUnit（Java）、PyTest（Python）等。
- 集成测试：在多个模块或组件集成后进行测试，用来验证不同模块之间的接口和交互是否按预期工作。通常使用 Postman（API 测试）、Selenium（Web 应用集成测试）等工具。
集成测试方式
Section titled “集成测试方式”- 增量集成：逐步添加新的模块并测试。
- 大爆炸集成：同时集成所有模块后一次性测试。
系统测试和集成测试的区别和使用场景是什么？
Section titled “系统测试和集成测试的区别和使用场景是什么？”- 系统测试：是在整个软件系统完成集成后进行的测试。目的是验证整个系统是否符合指定需求，关注整个系统的行为。测试内容涵盖功能完整性、用户界面、用户流程，以及性能、安全性、兼容性等非功能性测试。
- 集成测试：是在多个软件模块或组件被集成在一起时进行的测试。目的是验证这些模块或组件之间的交互，主要检查数据传递、接口调用、异常处理等模块间交互是否符合预期。
集成测试通常在单元测试之后、系统测试之前进行；当整个应用开发接近完成时，再进行系统测试。
什么是黑盒测试？
Section titled “什么是黑盒测试？”黑盒测试，也称为功能测试或行为测试，测试者只关注软件的输入和输出，不需要了解程序的内部实现，主要验证软件功能是否符合用户需求和规格说明。
- 等价类划分
- 边界值分析
- 因果图法
- 状态转换测试
- 错误猜测法
黑盒测试就像玩一款新游戏，你只关心游戏的功能、操作和画面，而不需要知道游戏源码或内部实现。
什么是白盒测试？
Section titled “什么是白盒测试？”白盒测试，也称为结构测试或透明盒测试，测试者需要了解程序的内部工作机制，包括代码、逻辑流程、内部结构等，主要验证代码的逻辑路径、分支覆盖、循环、语句覆盖等。
- 路径覆盖
- 条件覆盖
- 循环覆盖
- 语句覆盖
白盒测试就像你是游戏开发者，需要检查源代码，确保每个功能都按照设计要求正确实现。
说一下等价类划分和边界值法
Section titled “说一下等价类划分和边界值法”1. 等价类划分
Section titled “1. 等价类划分”等价类划分是将系统的输入域划分为若干部分，然后从每个部分中选取少量代表性数据进行测试。其核心思想是：如果某个测试用例在一个等价类中的某个值上通过，那么这个类中的其他值通常也会表现一致。
- 有效等价类：符合规格说明的输入条件。
- 无效等价类：不符合规格说明的输入条件。
通过测试有效等价类来验证系统的正确性，通过无效等价类来验证系统的健壮性。
2. 边界值法
Section titled “2. 边界值法”软件错误往往发生在输入或输出范围的边缘，因此边界值分析重点测试边界条件，而不是中间值。
常见测试点包括：
- 最小值
- 最大值
- 最小值 - 1
- 最大值 + 1
适用于对输入数据有明确范围或限制的功能。
等价类划分的难点是什么？
Section titled “等价类划分的难点是什么？”- 正确定义等价类：难点在于正确理解需求和规格说明。如果理解不准确，等价类划分就可能不准确，从而影响测试覆盖率和有效性。
- 识别有效和无效等价类：不仅要识别有效等价类，还要能识别无效等价类。
- 处理复杂输入条件：当输入条件复杂或者存在依赖关系时，定义清晰准确的等价类会更加困难。
接口测试用例的编写需要注意哪些要点？
Section titled “接口测试用例的编写需要注意哪些要点？”- 明确接口规格：理解接口的功能、输入输出参数、数据格式、请求方法（GET、POST、PUT、DELETE 等）和预期行为。
- 返回值校验：各种情况下（正确输入和异常输入）的响应内容是否正常。
- 业务逻辑校验：接口的业务逻辑和功能是否正常。
- 数据库校验
- 性能测试：如接口 TPS、响应时间等。
- 安全性测试：敏感信息加密、权限控制等。
接口测试有哪些工具？
Section titled “接口测试有哪些工具？”- Postman：API 测试工具，用于发送各种 HTTP 请求，并检查响应，支持自动化测试脚本编写。
- JMeter：主要用于性能测试和负载测试，也可以用于 API 测试。
- Swagger UI：用于设计、构建、文档化和测试 REST API 的工具。
你是怎么测试接口的？
Section titled “你是怎么测试接口的？”- 理解接口文档，了解接口的业务功能、请求方法、请求参数、响应结构、错误码以及对应的数据库存储。
- 编写测试用例，涵盖正常输入情况（验证功能性）和异常输入情况（验证健壮性和错误处理）。
- 使用测试工具（如 Postman）执行测试用例，观察响应是否符合预期，验证状态码、响应体内容、响应时间等。
性能测试时，一般关注哪些指标？
Section titled “性能测试时，一般关注哪些指标？”- TPS：每秒事务数，代表性能好坏，TPS 越高，性能通常越好。
- 平均响应时间：请求的平均耗时，时间越短，性能越好。
- 并发数：同时向服务端发起请求的虚拟用户数。
- 错误率：失败请求的比例。
功能测试用例一般包含哪些内容？
Section titled “功能测试用例一般包含哪些内容？”- 测试用例 ID
- 测试用例标题
- 功能模块
- 测试目的/描述
- 前置条件
- 测试步骤
- 测试数据
- 预期结果
- 实际结果
- 通过/失败标准
- 测试环境
- 备注信息
- 缺陷/问题 ID
如何写测试用例？
Section titled “如何写测试用例？”- 测试人员尽早介入，彻底理解需求，这是写好测试用例的基础。
- 如果以前有类似需求，可以参考类似需求的测试用例和历史 Bug。
- 清楚输入、输出的各种可能性，以及输入之间的关联关系，理解执行逻辑。
- 通过等价类、边界值、判定表等方法找出大部分用例。
- 找到需求相关特性，补充测试用例。
- 根据经验分析遗漏的测试场景。
- 多总结类似功能点的测试点，提高用例质量。
- 书写格式清晰。
请你说一下设计测试用例的方法
Section titled “请你说一下设计测试用例的方法”黑盒测试方法
Section titled “黑盒测试方法”- 等价类划分法
- 边界值分析法
- 因果图法
- 决策表测试
- 状态转换测试
白盒测试方法
Section titled “白盒测试方法”- 语句覆盖
- 分支覆盖
- 路径覆盖
- 条件覆盖
- 循环覆盖
如何提高用例的覆盖率，减少漏测？
Section titled “如何提高用例的覆盖率，减少漏测？”- 根据需求文档编写用例，确保每条需求都被对应的用例覆盖。
- 充分理解业务，挖掘隐性需求，并编写对应的用例。
- 除了正常场景，还要考虑异常场景和异常数据。
- 从多个维度对软件进行测试，如功能、性能、安全等。
- 多站在用户角度思考问题，模拟真实使用场景。
- 组织用例评审。
Bug 的生命周期
Section titled “Bug 的生命周期”- New（新的）：测试人员首次发现并确认问题是 Bug 后，记录下来并设为 New。
- Assigned（已指派）：Bug 被指派给开发人员处理。
- Open（打开的）：开发人员开始处理 Bug。
- Fixed（已修复）：开发人员认为已修复，提交给测试组验证。
- Pending Retest（待测试）：Bug 返回测试组，等待重新验证。
- Retest（再测试）：测试人员重新测试该 Bug。
- Closed（已关闭）：经验证确认 Bug 已解决。
- Reopen（重新打开）：复测发现 Bug 仍然存在，则重新打开。
- Pending Reject（待拒绝）：开发认为该问题不是 Bug，等待确认。
- Rejected（已拒绝）：经过确认，该问题确实不是 Bug。
- Postponed（延期）：由于特殊原因暂时延期处理。
Bug 类型
Section titled “Bug 类型”- 代码错误
- 界面优化
- 设计缺陷
- 配置相关
- 安装部署
- 安全相关
- 性能问题
- 标准规范
- 测试脚本
- 其他
常见的测试工具有哪些？
Section titled “常见的测试工具有哪些？”1. 自动化测试工具
Section titled “1. 自动化测试工具”- Selenium：用于自动化 Web 应用测试，支持多浏览器和多编程语言。
- Appium：用于自动化移动应用测试，支持 iOS 和 Android。
2. 性能测试工具
Section titled “2. 性能测试工具”- JMeter：用于测试 Web 应用的性能和负载。
- LoadRunner：支持模拟大量用户并测量系统性能。
3. 接口测试工具
Section titled “3. 接口测试工具”- Postman：用于 API 开发和测试。
- Swagger UI：用于设计、构建、文档化和测试 REST API。
4. 单元测试工具
Section titled “4. 单元测试工具”- Pytest：用于 Python 应用程序测试。
- JUnit：用于 Java 应用程序单元测试。
- Fiddler：常用抓包工具。
说一说你知道的自动化测试框架
Section titled “说一说你知道的自动化测试框架”- Pytest：Python 的测试框架，支持单元测试、功能测试、接口自动化测试（pytest + requests）、Selenium/Appium 自动化测试等。
- JUnit：Java 语言的单元测试框架。
- Selenium：用于 Web 自动化测试。
- Appium：支持 iOS 和 Android 平台上的原生应用、Web 应用及混合应用自动化测试。
- LoadRunner：通过模拟大量并发用户进行性能测试。
App 测试和 Web 测试有什么区别？
Section titled “App 测试和 Web 测试有什么区别？”1. 架构区别
Section titled “1. 架构区别”- Web 项目：一般是 B/S 架构，基于浏览器。
- App 项目：一般是 C/S 架构，必须有客户端。
Web 更新服务器端后，用户端通常同步生效；而 App 需要用户更新客户端版本，因此回归测试范围通常更大。
2. 性能方面
Section titled “2. 性能方面”- Web：更关注响应时间。
- App：除了响应时间，还要关注流量、电量、CPU、GPU、内存等。
3. 兼容性方面
Section titled “3. 兼容性方面”- Web：主要关注浏览器兼容性和电脑系统兼容性。
- App：需要关注设备型号、分辨率、屏幕尺寸、操作系统版本以及厂商定制系统等。
4. App 特有专项测试
Section titled “4. App 特有专项测试”- 异常场景测试：来电、短信、关机、重启、中断等。
- 弱网测试：弱网、网络切换、丢包、延迟、重复提交等。
- 安装/卸载/更新测试：包括异常安装、强制更新、增量更新、断点续传等。
- 界面操作测试：手势、横竖屏切换、多点触控、点击热区等。
软件质量的六个特征
Section titled “软件质量的六个特征”- 功能性：满足明确和隐含需求的能力。
- 可靠性：在特定条件下持续正常运行的能力。
- 易用性：是否易于理解、学习和使用。
- 效率：对系统资源的有效使用。
- 可维护性：修正和改进软件的能力。
- 可移植性：从一个环境迁移到另一个环境的能力。
任何事物的用例设计，都可以按照软件质量六大特征来分类说明。
如果做一个杯子的检测，你怎么测试？
Section titled “如果做一个杯子的检测，你怎么测试？”从软件质量六大特征类比来看，可以这样测试杯子：
1. 功能性
Section titled “1. 功能性”- 测试杯子是否适合装水、茶、咖啡等。
- 检查容量标识是否准确。
- 检查是否符合健康和安全标准。
2. 可靠性
Section titled “2. 可靠性”- 测试正常使用下是否容易破裂。
- 测试高温、跌落等非常规场景下的表现。
3. 易用性
Section titled “3. 易用性”- 检查是否容易握持和使用。
- 是否有清晰使用说明，如是否可微波。
- 特殊功能杯子是否容易学习使用。
- 对保温杯可测试保温时长。
- 评估材料利用效率。
5. 可维护性
Section titled “5. 可维护性”- 是否容易发现损坏或磨损。
- 是否便于清洗和维护。
6. 可移植性
Section titled “6. 可移植性”- 是否适用于不同场景，如室内、户外。
- 是否便于清洁、收纳和携带。
给你一个页面，如何开展测试？
Section titled “给你一个页面，如何开展测试？”- UI 测试：页面布局、样式、控件长度、显示是否截断、快捷键、Tab 焦点切换等。
- 功能测试：页面各类控件的功能测试，例如密码框是否隐藏、输入是否做
trim处理等。 - 安全测试：特殊字符、SQL 注入、脚本注入、后台校验、数据传输是否加密等。
- 兼容性测试
- 性能测试
请你说一说用户界面登录过程都需要做哪些测试
Section titled “请你说一说用户界面登录过程都需要做哪些测试”1. 功能测试
Section titled “1. 功能测试”- 输入正确的用户名和密码，验证是否能正确登录。
- 输入错误的用户名或密码，验证登录失败并提示正确信息。
- 登录成功后是否跳转到正确页面。
- 用户名和密码长度限制。
- 用户名和密码包含特殊字符、空格、非英文字符的情况。
- 记住用户名功能。
- 登录失败后不记录密码。
- 用户名和密码前后空格处理。
- 密码是否非明文显示。
- 验证码是否清晰、可刷新、易辨认。
- 注册、忘记密码、切换账号等链接是否正确。
- 开启大写锁定时是否有提示。
- 空输入提交后的提示是否正确。
2. 界面测试
Section titled “2. 界面测试”- 布局是否合理。
- 页面风格是否与设计稿一致。
- 是否存在错别字，文案是否清晰。
3. 性能测试
Section titled “3. 性能测试”- 登录页面加载时间是否符合要求。
- 登录成功后页面跳转时间是否符合要求。
- 高并发登录情况下系统是否正常。
4. 安全性测试
Section titled “4. 安全性测试”- 登录成功后生成的 Cookie 是否设置
HttpOnly。 - 用户名和密码是否加密传输。
- 用户名和密码校验是否在服务端完成。
- 是否防 SQL 注入。
- 是否防 XSS 攻击。
- 是否限制错误登录次数，防止暴力破解。
- 是否支持多用户同机登录。
- 同一用户能否多设备同时登录。
5. 可用性测试
Section titled “5. 可用性测试”- 是否支持全键盘操作。
- 回车键是否可直接登录。
- 输入框是否支持 Tab 切换。
6. 兼容性测试
Section titled “6. 兼容性测试”- 不同浏览器是否正常显示和使用。
- 同一浏览器不同版本是否正常。
- 不同平台（Windows、Mac）是否正常。
- 移动设备（iPhone、Android）是否正常。
- 不同分辨率下显示是否正常。
7. 本地化测试
Section titled “7. 本地化测试”- 不同语言环境下页面显示是否正确。
测试提交一个 Bug，开发认为不是 Bug，你会怎么办？
Section titled “测试提交一个 Bug，开发认为不是 Bug，你会怎么办？”- 告知开发自己判断 Bug 的依据，同时明确开发认为不是 Bug 的理由。
- 对开发给出的理由进行校验，校验依据包括：
- 需求文档
- 与产品经理沟通确认
- 如果最终确认不是 Bug，则关闭；如果确认是 Bug，则继续提交开发处理，确保产品质量。
发现一个 Bug，如何定位是客户端还是服务端的问题？
Section titled “发现一个 Bug，如何定位是客户端还是服务端的问题？”- 首先复现问题：确保能够稳定复现，并记录复现步骤、输入、环境等信息。
- 查看错误日志：查看客户端和服务端日志，分析是否有异常日志。
- 分析客户端：使用开发者工具检查网络请求、响应数据、控制台输出等。如果响应数据正确但页面表现异常，可能是客户端问题。
- 分析服务端：检查服务端处理逻辑，确认请求是否被正确处理、响应是否正确返回。如果服务端处理或返回异常，则问题可能在服务端。
- 验证网络通信：确认客户端和服务端之间的网络通信是否正常，因为网络问题也可能导致异常。