那些年的面试经验（一）

最近的一场面试，是面试官说到的问题，我也认可的一个点就是我缺乏结构化思维或者表达。意识到问题基本问题就解决了一半，慢慢总结优化吧~

问题1：手工case和AT case是否一致？

对于这个问题，第一反应会是什么呢？我回答得确实点比较散乱，以下是chat-gpt的回答，我感觉不用全部一样，但是可以借鉴以下他的分析思路：

在软件测试工作中，**手工测试用例**和**自动化测试用例**不一定是完全一致的。虽然它们在测试目标和逻辑上可能有很大重合，但由于手工测试和自动化测试的特点不同，二者在编写和执行上存在一定的差异。

1. **目标一致，但实现方式不同**
   - **手工测试用例**：主要通过人工操作来执行，测试人员会按照步骤手动操作应用程序并观察结果。手工测试的用例通常更加详细，描述如何执行每一步操作，并适应各种突发情况（如系统卡顿、延迟等）。
   
   - **自动化测试用例**：通过脚本或工具自动执行。由于自动化需要更高的稳定性和可复用性，自动化测试用例通常更加简洁、高效，避免复杂的人工步骤，且需要精确的数据和行为定义。

 2. **步骤和细节的差异**
   - **手工测试用例**：为了确保测试人员理解如何手动执行操作，手工测试用例的每个步骤往往非常详细。例如，点击某个按钮、输入某个文本字段的具体说明、页面加载时可能要等待的时间等。
   
   - **自动化测试用例**：自动化用例则会忽略一些手动步骤中不必要的细节，脚本会直接调用应用程序的接口或通过 DOM 操作来自动执行任务。对于等待时间等，自动化测试可能使用明确的等待条件，而不是人工判断。

3. **可维护性和可扩展性**
   - **手工测试用例**：手工测试不需要考虑脚本的可维护性，测试人员可以自由地调整操作步骤。因此，手工用例可以灵活应对某些无法自动化的复杂场景。
   
   - **自动化测试用例**：自动化测试需要考虑脚本的维护成本和可复用性。随着系统的变化，自动化脚本可能需要不断调整，以应对 UI 或业务逻辑的变化。通常，自动化用例会集中测试核心功能，避免覆盖过多边缘或不稳定的测试场景。

 4. **测试场景的选择**
   - **手工测试**：适用于**探索性测试**、**UI/UX 测试**、**异常场景测试**等较难自动化的测试场景，或需要人为判断和感受的功能。
   
   - **自动化测试**：更适合**重复性高**、**流程固定**、**结果明确**的场景，例如回归测试、性能测试、接口测试等。自动化用例更关注高效地覆盖关键路径。

 5. **失败处理**
   - **手工测试**：测试人员可以在用例失败时立即调查原因，并根据实际情况灵活调整后续测试。
   
   - **自动化测试**：自动化脚本在用例失败时，通常依赖于日志或错误信息来分析原因，无法灵活应对一些临时变化或偶发性错误。总结
- **测试目标上**，手工测试用例和自动化测试用例通常是一致的，因为它们都希望验证相同的功能、业务逻辑和系统行为。
- **执行方式上**，手工和自动化用例存在较大差异。手工测试用例更加详细且灵活，而自动化用例更关注稳定性和可维护性，因此自动化用例在实现上通常更简洁且高效。

在实际测试过程中，手工和自动化测试往往是互补的，选择合适的场景来分别应用手工或自动化测试是确保测试覆盖全面、效率最大化的关键。

通过分析手工执行和AT执行两个方法的特点和各自适用的场景的差异来分析为什么会存在不一致。会显得回答的不那么干瘪和没有思考过程。

问题2：如何保证用例已经被自动化了？

咋回答呢？看看GPT老师的回答吧

1. 用例选择与规划

• 评估自动化的可行性：在开始自动化之前，需要评估哪些手工测试用例适合自动化。通常会优先自动化那些高频、可重复执行、回归性强且结果可预期的用例。复杂、依赖人为判断的用例可能会保留为手工测试。

• 确定关键路径：自动化的首要目标是覆盖核心的功能和业务流程，这样可以确保系统在主要功能上是稳定的。

2. 跟踪测试用例状态

• 用例管理工具：使用测试管理工具（如 Jira、TestRail 等）跟踪手工测试用例和自动化测试用例的状态。在工具中标记哪些用例已经自动化，可以清楚地了解自动化的覆盖情况。

• 定期更新和回顾：随着系统的更新和需求的变更，自动化测试用例也需要定期更新和回顾，确保新功能或变更功能也能够被自动化覆盖。

3. 持续集成和自动化执行

• 集成自动化到持续集成（CI）管道：通过持续集成管道（如 Jenkins、GitLab CI 等）自动执行自动化测试用例，确保每次代码变更都能触发测试，自动化用例会作为代码质量的保障。如果某个用例已经自动化了，每次代码提交时自动化测试都会运行它，从而确保其持续有效。

• 报告和监控：通过自动化测试报告和监控工具（如 Allure、JUnit 报告等）可以定期查看自动化测试用例的执行情况，确认是否被正确执行。

4. 手工测试和自动化测试的平衡

• 手工测试补充自动化：对于那些自动化无法覆盖的场景，如 UI 视觉检测、复杂的用户交互、或非标准操作，手工测试依然是不可替代的。自动化用例的设计和手工用例会并行发展，在某些特定场景，手工测试用例可能会独立存在。

• 探索性测试：自动化测试无法替代手工探索性测试。测试人员通过手工方式可以发现一些自动化脚本无法捕捉的潜在问题。

相比之下，我回答的就很片面，所以面试官后面又继续问了用例状态什么的。。

问题3：框架后来交由别人维护是怎么交接的

面的时候只说了写文档和交接会议，然后，人没离职可以随时问。现在想想其实是可以结合自动化框架的设计，比如数据驱动、分层等，从整体上说明框架，让接手的同事能够更快速的上手。

问题4：日常的测试中有没有什么自己总结的经验