level 5
西安恩仪联教育
楼主
1. 软件测试的基本流程
需求分析与评审、制定测试计划、设计测试用例、执行测试并记录缺陷、回归测试与报告输出、测试总结与闭环。
2. 当你拿到一个需求之后，你是怎么分析及设计测试用例呢
（1）. 需求分析：彻底理解"要做什么"
这是最基础也最重要的一步。我会先把需求文档反复看几遍，确保自己完全理解。
识别功能点：把大需求拆解成一个个小功能点。比如"用户登录"可以拆成输入账号、输入密码、点击登录按钮等。
明确验收标准：找出每个功能点的成功标准。比如"输入正确账号密码后，应成功跳转至首页"。
挖掘隐藏需求：思考用户没明说但默认需要的功能。比如密码输入框需要有隐藏/显示密码的切换按钮。
（2）. 用例设计：构思"如何验证"
理解需求后，我会用不同方法来设计测试用例，确保覆盖各种情况。
等价类划分法：把输入数据分成有效和无效的类别。
- 有效等价类：比如输入
正确的
手机号格式
- 无效等价类：比如手机号为空、只有10位数字或包含字母
边界值分析法：专门测试输入值的边界情况，因为这是最容易出错的地方。
- 例如密码要求6-20位，我会测试5位、6位、20位和21位的情况
场景法：模拟用户的真实使用流程。
- 比如用户下单的完整流程：浏览商品 → 加入购物车 → 结算 → 选择支付方式 → 完成支付
错误推测法：基于经验和直觉，猜测可能出现问题的地方。
- 比如网络突然断开时，App是否能友好提示而不是直接闪退
3. 讲一下bug的生命周期
Bug从发现到关闭的完整流程为：New（新建）→Open（确认）→Assign（指派）→Fix（修复）→Retest（验证）→Closed（关闭），可能包含Reopen/Reject等状态。
4. 如何提交一个高质量的bug
一个高质量的 bug 报告，核心目标是让开发同事能一眼看懂，并且能快速复现和定位问题。
简单来说，就是：标题清晰 + 复现步骤明确 + 信息完整（预期结果与实际结果：对比鲜明、附件与环境：提供线索，辅助定位）。
5. 黑盒测试与白盒测试
（1）. 黑盒测试（Black-box Testing）
这种方法把软件看作一个黑盒子，不关心内部代码结构，测试人员只关注输入数据和输出结果是否符合需求规格。
- 等价类划分：将输入数据分成若干个等价类，从每个类中选一个代表性数据进行测试，可减少测试用例数量。
- 边界值分析：专门测试输入数据的边界情况，如最大值、最小值、临界点等，因为很多缺陷都出现在边界上。
- 场景法：模拟用户的实际使用流程来设计测试用例，更贴近真实使用场景。
（2）. 白盒测试（White-box Testing）
这种方法需要了解软件的内部逻辑和代码结构，测试人员会根据代码的逻辑路径来设计测试用例。
- 语句覆盖：设计足够的测试用例，使得程序中每条语句至少执行一次。
- 判定覆盖：也叫分支覆盖，确保程序中每个判断的取真和取假分支都至少执行一次。
- 条件覆盖：确保判断中的每个条件的可能取值都至少执行一次。
总的来说，黑盒测试关注"做什么"，白盒测试关注"怎么做"。
（3）.区别：黑盒测试关注输入输出，不关心内部代码，如功能测试；白盒测试基于代码逻辑设计用例，如单元测试。黑盒面向需求，白盒面向实现；黑盒由测试人员执行，白盒多由开发完成。
6. 你知道哪些测试类型？这个问题可以从不同维度来回答，比如：
- 按开发阶段：单元测试、集成测试、系统测试、验收测试。
- 按测试目标：功能测试、性能测试、安全测试、兼容性测试、易用性测试
7. 什么是回归测试，怎么做回归测试
回归测试：回归测试就是为了验证新的代码改动，没有破坏已有的功能。
回归测试的核心目的是"防劣化"。当开发修复了一个bug或增加了新功能后，我们需要确保这些改动没有影响到其他原本正常工作的模块。
测试方法：
手动回归：由测试人员手动执行测试用例。
- 适合改动范围小、影响面可控的场景
- 优点是灵活，可以随时发现新问题
- 缺点是耗时费力，容易遗漏
自动化回归：通过编写的自动化脚本来执行测试。
- 适合核心功能和稳定的业务流程
- 优点是速度快、覆盖率高、结果可靠
- 每次代码提交后可自动运行，快速反馈问题
冒烟测试：回归测试的"精简版"。
- 只验证最核心、最基础的功能点
- 目的是快速判断新版本是否稳定，是否值得进行更全面的测试
- 如果冒烟测试失败，通常会直接打回给开发团队
8. 自动化测试工具有哪些？你了解Selenium吗？
Web自动化工具有Selenium、Cypress；接口测试工具有Postman、JMeter；性能测试工具有LoadRunner、JMeter。Selenium是开源Web自动化工具，支持多浏览器，需配合WebDriver使用，常用于UI自动化测试。
9. 如何保障一个测试的覆盖率
保障测试覆盖率，核心在于建立一套标准化的流程和方法，确保我们的测试活动能够尽可能全面地覆盖产品的各个方面。
方法：
1. 基于需求的覆盖
这是最根本的一步。我们需要确保每一个需求点都有对应的测试用例来验证。
- 建立需求与用例的映射关系：可以用表格或工具将每个需求点和验证它的测试用例关联起来。
- 定期进行需求评审：确保测试团队对需求的理解是准确且全面的，避免因理解偏差导致的测试遗漏。
2. 运用多样化的测试用例设计方法
不要只用一种方法设计用例，多种方法结合使用才能覆盖更全面。
- 等价类划分和边界值分析：这两种方法主要用于覆盖输入输出的数据范围，确保各种数据组合都被考虑到。
- 场景法：模拟用户的真实使用流程，确保核心业务流程的完整性。
- 错误推测法：基于经验和直觉，去猜测那些容易出错的地方，补充一些"非常规"的测试点。
3. 引入自动化测试
自动化测试是提升覆盖率和效率的利器。
- 自动化回归测试：将核心的、重复的测试用例自动化，每次版本更新后自动运行，确保核心功能不被破坏。
- 自动化脚本的持续维护：随着产品迭代，自动化脚本也需要不断更新，以适应新的功能和需求。
4. 进行代码层面的覆盖分析（可选）
如果条件允许，可以借助工具进行代码覆盖率分析。
- 这能从技术角度告诉你，我们的测试用例执行了多少行代码、多少个函数。
- 这是一个很客观的指标，但不是唯一标准。高代码覆盖率不代表产品就一定没有bug。
10. 如何评估一个版本是否上线
一个版本能否上线，通常会综合评估以下几个方面，由产品、开发、测试等多方共同决定。
1. 核心功能是否稳定
这是最基本的门槛。所有计划在本版本上线的新功能，以及核心的旧功能，都必须正常工作。
- P0/P1级别的Bug必须全部解决：影响核心功能、用户体验或造成数据问题的严重Bug必须100%修复。
- 核心流程必须走通：比如电商App的"浏览-加购-下单-支付"流程必须顺畅无误。
2. 线上监控与灰度情况
如果项目有灰度发布或A/B测试的机制，这是评估的重要参考。
- 灰度用户的反馈：观察灰度用户的使用情况，是否有新的问题被发现。
- 关键指标变化：监控Crash率、ANR率、接口成功率等技术指标，以及活跃用户数、留存率等业务指标是否有异常波动。
3. 性能与兼容性表现
技术层面的表现同样重要，直接影响用户体验。
- 性能达标：App的启动时间、页面响应速度、内存占用等性能指标是否在可接受范围内。
- 兼容性良好：在目标用户群体的主流机型和系统版本上，App能够正常运行，UI显示正常。
4. 文档与发布准备
上线不仅仅是技术工作，还包括运营和客服的准备。
- 相关文档是否齐全：比如给运营的更新日志、给客服的常见问题解答(FAQ)等。
- 发布计划是否清晰：是否有明确的上线时间、回滚预案，以及出问题后的应急响应流程。
11. 如何应对测试时间被大幅度压缩的情况
1. 立即沟通，评估风险
首先，不要默默接受。你需要和产品经理、开发负责人进行沟通。
- 说明影响：清晰地告知他们，如果测试时间被压缩，可能会导致哪些风险。
- 提出建议：主动提出替代方案，如"我们可以优先保证核心功能的测试，非核心功能可以延后到下个版本"。
- 争取支持：目的不是为了"讨价还价"，而是为了让大家对风险有共识，并共同寻找最优解。
2. 迅速调整测试策略
如果沟通后时间无法延长，那就要立刻调整测试计划。
- 聚焦核心功能：把所有测试资源都投入到产品的核心路径和高风险模块上。
- 简化或暂停次要任务：可以暂停一些非核心功能的测试，或简化某些测试类型。
- 增加自动化回归：如果有自动化脚本，要优先运行，快速覆盖大量基础功能。
3. 提升执行效率
在执行层面，也要想办法提高效率。
- 尽早介入：在开发写代码的阶段就开始介入，进行需求评审和用例设计。
- 采用探索性测试：在时间非常紧张时，可以减少编写详细用例的时间，采用探索性测试。
- 持续反馈：一旦发现严重Bug，立刻反馈给开发，而不是等到测试结束才集中报告。
12. 如何测试一个Web登录页面？跟我讲一下你的整体设计思路。
- 可从功能测试（如用户名和密码的正确/错误输入验证、登录按钮功能等）、性能测试（如登录响应时间）、安全性测试（如密码是否加密传输、防止暴力破解等）、兼容性测试（在不同浏览器、设备上的显示和功能是否正常）等方面进行设计。
13. 项目版本执行过程中，测试人员如何把控测试进度？
测试负责人要及时了解测试进度，跟踪BUG提交、修复及验证情况以及系统的拷机情况。根据实际开发进度调整测试计划，及时反馈问题并处理，当测试进度出现延期时，要及时确认原因并采取相应措施。
14. 什么是软件测试？测试的目的是什么？
软件测试是通过手动或自动手段验证软件是否满足需求的过程。核心目的包括发现缺陷、验证功能是否符合需求、评估软件质量，降低上线风险。
15. 发现一个Bug后，你会怎么处理？
发现Bug后，我会先在Bug管理工具（如Jira）中详细记录。记录内容包括Bug标题、复现步骤、实际结果、预期结果、截图或录屏等。然后将Bug提交给开发人员。开发修复后，我会进行回归测试，确认Bug已被正确修复。
16. 什么是测试用例？一个测试用例通常包含哪些要素？
测试用例是为了验证某个特定功能而设计的一套详细步骤。一个标准的测试用例通常包含：用例ID、模块、测试标题、前置条件、测试步骤、预期结果和实际结果。
2025年09月28日 08点09分
1
需求分析与评审、制定测试计划、设计测试用例、执行测试并记录缺陷、回归测试与报告输出、测试总结与闭环。
2. 当你拿到一个需求之后，你是怎么分析及设计测试用例呢
（1）. 需求分析：彻底理解"要做什么"
这是最基础也最重要的一步。我会先把需求文档反复看几遍，确保自己完全理解。
识别功能点：把大需求拆解成一个个小功能点。比如"用户登录"可以拆成输入账号、输入密码、点击登录按钮等。
明确验收标准：找出每个功能点的成功标准。比如"输入正确账号密码后，应成功跳转至首页"。
挖掘隐藏需求：思考用户没明说但默认需要的功能。比如密码输入框需要有隐藏/显示密码的切换按钮。
（2）. 用例设计：构思"如何验证"
理解需求后，我会用不同方法来设计测试用例，确保覆盖各种情况。
等价类划分法：把输入数据分成有效和无效的类别。
- 有效等价类：比如输入
正确的
手机号格式
- 无效等价类：比如手机号为空、只有10位数字或包含字母
边界值分析法：专门测试输入值的边界情况，因为这是最容易出错的地方。
- 例如密码要求6-20位，我会测试5位、6位、20位和21位的情况
场景法：模拟用户的真实使用流程。
- 比如用户下单的完整流程：浏览商品 → 加入购物车 → 结算 → 选择支付方式 → 完成支付
错误推测法：基于经验和直觉，猜测可能出现问题的地方。
- 比如网络突然断开时，App是否能友好提示而不是直接闪退
3. 讲一下bug的生命周期
Bug从发现到关闭的完整流程为：New（新建）→Open（确认）→Assign（指派）→Fix（修复）→Retest（验证）→Closed（关闭），可能包含Reopen/Reject等状态。
4. 如何提交一个高质量的bug
一个高质量的 bug 报告，核心目标是让开发同事能一眼看懂，并且能快速复现和定位问题。
简单来说，就是：标题清晰 + 复现步骤明确 + 信息完整（预期结果与实际结果：对比鲜明、附件与环境：提供线索，辅助定位）。
5. 黑盒测试与白盒测试
（1）. 黑盒测试（Black-box Testing）
这种方法把软件看作一个黑盒子，不关心内部代码结构，测试人员只关注输入数据和输出结果是否符合需求规格。
- 等价类划分：将输入数据分成若干个等价类，从每个类中选一个代表性数据进行测试，可减少测试用例数量。
- 边界值分析：专门测试输入数据的边界情况，如最大值、最小值、临界点等，因为很多缺陷都出现在边界上。
- 场景法：模拟用户的实际使用流程来设计测试用例，更贴近真实使用场景。
（2）. 白盒测试（White-box Testing）
这种方法需要了解软件的内部逻辑和代码结构，测试人员会根据代码的逻辑路径来设计测试用例。
- 语句覆盖：设计足够的测试用例，使得程序中每条语句至少执行一次。
- 判定覆盖：也叫分支覆盖，确保程序中每个判断的取真和取假分支都至少执行一次。
- 条件覆盖：确保判断中的每个条件的可能取值都至少执行一次。
总的来说，黑盒测试关注"做什么"，白盒测试关注"怎么做"。
（3）.区别：黑盒测试关注输入输出，不关心内部代码，如功能测试；白盒测试基于代码逻辑设计用例，如单元测试。黑盒面向需求，白盒面向实现；黑盒由测试人员执行，白盒多由开发完成。
6. 你知道哪些测试类型？这个问题可以从不同维度来回答，比如：
- 按开发阶段：单元测试、集成测试、系统测试、验收测试。
- 按测试目标：功能测试、性能测试、安全测试、兼容性测试、易用性测试
7. 什么是回归测试，怎么做回归测试
回归测试：回归测试就是为了验证新的代码改动，没有破坏已有的功能。
回归测试的核心目的是"防劣化"。当开发修复了一个bug或增加了新功能后，我们需要确保这些改动没有影响到其他原本正常工作的模块。
测试方法：
手动回归：由测试人员手动执行测试用例。
- 适合改动范围小、影响面可控的场景
- 优点是灵活，可以随时发现新问题
- 缺点是耗时费力，容易遗漏
自动化回归：通过编写的自动化脚本来执行测试。
- 适合核心功能和稳定的业务流程
- 优点是速度快、覆盖率高、结果可靠
- 每次代码提交后可自动运行，快速反馈问题
冒烟测试：回归测试的"精简版"。
- 只验证最核心、最基础的功能点
- 目的是快速判断新版本是否稳定，是否值得进行更全面的测试
- 如果冒烟测试失败，通常会直接打回给开发团队
8. 自动化测试工具有哪些？你了解Selenium吗？
Web自动化工具有Selenium、Cypress；接口测试工具有Postman、JMeter；性能测试工具有LoadRunner、JMeter。Selenium是开源Web自动化工具，支持多浏览器，需配合WebDriver使用，常用于UI自动化测试。
9. 如何保障一个测试的覆盖率
保障测试覆盖率，核心在于建立一套标准化的流程和方法，确保我们的测试活动能够尽可能全面地覆盖产品的各个方面。
方法：
1. 基于需求的覆盖
这是最根本的一步。我们需要确保每一个需求点都有对应的测试用例来验证。
- 建立需求与用例的映射关系：可以用表格或工具将每个需求点和验证它的测试用例关联起来。
- 定期进行需求评审：确保测试团队对需求的理解是准确且全面的，避免因理解偏差导致的测试遗漏。
2. 运用多样化的测试用例设计方法
不要只用一种方法设计用例，多种方法结合使用才能覆盖更全面。
- 等价类划分和边界值分析：这两种方法主要用于覆盖输入输出的数据范围，确保各种数据组合都被考虑到。
- 场景法：模拟用户的真实使用流程，确保核心业务流程的完整性。
- 错误推测法：基于经验和直觉，去猜测那些容易出错的地方，补充一些"非常规"的测试点。
3. 引入自动化测试
自动化测试是提升覆盖率和效率的利器。
- 自动化回归测试：将核心的、重复的测试用例自动化，每次版本更新后自动运行，确保核心功能不被破坏。
- 自动化脚本的持续维护：随着产品迭代，自动化脚本也需要不断更新，以适应新的功能和需求。
4. 进行代码层面的覆盖分析（可选）
如果条件允许，可以借助工具进行代码覆盖率分析。
- 这能从技术角度告诉你，我们的测试用例执行了多少行代码、多少个函数。
- 这是一个很客观的指标，但不是唯一标准。高代码覆盖率不代表产品就一定没有bug。
10. 如何评估一个版本是否上线
一个版本能否上线，通常会综合评估以下几个方面，由产品、开发、测试等多方共同决定。
1. 核心功能是否稳定
这是最基本的门槛。所有计划在本版本上线的新功能，以及核心的旧功能，都必须正常工作。
- P0/P1级别的Bug必须全部解决：影响核心功能、用户体验或造成数据问题的严重Bug必须100%修复。
- 核心流程必须走通：比如电商App的"浏览-加购-下单-支付"流程必须顺畅无误。
2. 线上监控与灰度情况
如果项目有灰度发布或A/B测试的机制，这是评估的重要参考。
- 灰度用户的反馈：观察灰度用户的使用情况，是否有新的问题被发现。
- 关键指标变化：监控Crash率、ANR率、接口成功率等技术指标，以及活跃用户数、留存率等业务指标是否有异常波动。
3. 性能与兼容性表现
技术层面的表现同样重要，直接影响用户体验。
- 性能达标：App的启动时间、页面响应速度、内存占用等性能指标是否在可接受范围内。
- 兼容性良好：在目标用户群体的主流机型和系统版本上，App能够正常运行，UI显示正常。
4. 文档与发布准备
上线不仅仅是技术工作，还包括运营和客服的准备。
- 相关文档是否齐全：比如给运营的更新日志、给客服的常见问题解答(FAQ)等。
- 发布计划是否清晰：是否有明确的上线时间、回滚预案，以及出问题后的应急响应流程。
11. 如何应对测试时间被大幅度压缩的情况
1. 立即沟通，评估风险
首先，不要默默接受。你需要和产品经理、开发负责人进行沟通。
- 说明影响：清晰地告知他们，如果测试时间被压缩，可能会导致哪些风险。
- 提出建议：主动提出替代方案，如"我们可以优先保证核心功能的测试，非核心功能可以延后到下个版本"。
- 争取支持：目的不是为了"讨价还价"，而是为了让大家对风险有共识，并共同寻找最优解。
2. 迅速调整测试策略
如果沟通后时间无法延长，那就要立刻调整测试计划。
- 聚焦核心功能：把所有测试资源都投入到产品的核心路径和高风险模块上。
- 简化或暂停次要任务：可以暂停一些非核心功能的测试，或简化某些测试类型。
- 增加自动化回归：如果有自动化脚本，要优先运行，快速覆盖大量基础功能。
3. 提升执行效率
在执行层面，也要想办法提高效率。
- 尽早介入：在开发写代码的阶段就开始介入，进行需求评审和用例设计。
- 采用探索性测试：在时间非常紧张时，可以减少编写详细用例的时间，采用探索性测试。
- 持续反馈：一旦发现严重Bug，立刻反馈给开发，而不是等到测试结束才集中报告。
12. 如何测试一个Web登录页面？跟我讲一下你的整体设计思路。
- 可从功能测试（如用户名和密码的正确/错误输入验证、登录按钮功能等）、性能测试（如登录响应时间）、安全性测试（如密码是否加密传输、防止暴力破解等）、兼容性测试（在不同浏览器、设备上的显示和功能是否正常）等方面进行设计。
13. 项目版本执行过程中，测试人员如何把控测试进度？
测试负责人要及时了解测试进度，跟踪BUG提交、修复及验证情况以及系统的拷机情况。根据实际开发进度调整测试计划，及时反馈问题并处理，当测试进度出现延期时，要及时确认原因并采取相应措施。
14. 什么是软件测试？测试的目的是什么？
软件测试是通过手动或自动手段验证软件是否满足需求的过程。核心目的包括发现缺陷、验证功能是否符合需求、评估软件质量，降低上线风险。
15. 发现一个Bug后，你会怎么处理？
发现Bug后，我会先在Bug管理工具（如Jira）中详细记录。记录内容包括Bug标题、复现步骤、实际结果、预期结果、截图或录屏等。然后将Bug提交给开发人员。开发修复后，我会进行回归测试，确认Bug已被正确修复。
16. 什么是测试用例？一个测试用例通常包含哪些要素？
测试用例是为了验证某个特定功能而设计的一套详细步骤。一个标准的测试用例通常包含：用例ID、模块、测试标题、前置条件、测试步骤、预期结果和实际结果。