0402 —— 美团测开二面

1.实习项目

2.Docker命令【学习 】

3.接口测试

4.手撕（给定一个整数数组，将正数移动到左边，将负数移动到右边）

然后根据代码设计测试用例

5.HTTP返回状态码

6.结合自身和实习经历 ：一个好的Bug表单包含哪些内容？

一个好的Bug报告（表单）是确保有效沟通和快速问题解决的关键。基于实习经验和软件测试的最佳实践，一个高质量的Bug报告通常包括以下内容：

1. 唯一标识符（Bug ID）

• 为每个Bug分配一个唯一的标识号，方便追踪和引用。

2. 标题（Title）

• 提供一个简洁且描述性强的标题，能够概括Bug的本质，使人一眼就能大致理解问题。

3. 严重性（Severity）

• 根据Bug对系统的影响程度来评定其严重性，如阻塞性（Blocker）、严重（Critical）、一般（Major/Minor）等。

4. 优先级（Priority）

• 优先级指明了Bug修复的紧迫性，通常由项目管理者或团队根据Bug的严重性和业务需求来确定。

5. 描述（Description）

• 对Bug进行详细描述，包括出现Bug的上下文、预期行为与实际行为的差异等。

6. 复现步骤（Steps to Reproduce）

• 详细列出重现Bug的具体步骤，最好是条理化的列表形式，每一步都清晰明确，确保其他人可以准确地复现问题。

7. 环境（Environment）

• 包括操作系统、浏览器版本、设备型号、应用版本等详细信息，确保Bug的复现和测试是在相同或类似的环境下进行。

8. 截图或录屏（Screenshots/Videos）

• 提供问题发生时的截图或录屏，有助于更直观地展示问题，特别是对于UI问题或复杂的交互问题。

9. 日志文件（Log Files）

• 如果可能，附上相关的系统或应用日志文件，这对于开发人员定位问题源头非常有帮助。

10. 重现率（Reproducibility）

• 指明Bug的重现率，如总是发生（Always）、偶尔发生（Sometimes）、难以重现（Rarely）等。

11. 报告人（Reporter）

• 记录提出Bug报告的人员信息，包括姓名和联系方式，以便需要时进行进一步的沟通。

12. 状态（Status）

• Bug当前的状态，如新提交（New）、已确认（Confirmed）、正在处理（In Progress）、已解决（Resolved）、已关闭（Closed）等。

13. 修复信息（Resolution Details）

• 包括修复Bug的开发人员信息、修复日期、修复版本号等，如果Bug被标记为无需修复或作为特性接受，也应说明原因。

给的建议：学好基础知识