QA 实习生实操指南 — 配置摄像头、写 Test Case、提 Bug、JIRA 流程
场景：你作为 NCS QA Intern 第一天上班，完全不知道”配置摄像头”是什么意思、test case 怎么写、JIRA 是什么。 目标：用最直白的语言 + 真实例子，让你面试时能聊得具体，入职时不懵逼。
目录
1. KAI 平台到底长什么样
你是一个 QA 实习生。你打开浏览器，输入 KAI UP 的网址，登录。你看到的界面类似下面这样（文字描述）：
┌─────────────────────────────────────────────────┐
│ KAI Unified Platform 👤 Admin │
├─────────────────────────────────────────────────┤
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ 📹 │ │ 📹 │ │ 📹 │ │ 📹 │ │
│ │ 摄像头1│ │ 摄像头2│ │ 摄像头3│ │ 摄像头4│ │
│ │ 在线 │ │ 在线 │ │ 离线 │ │ 在线 │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
│ │
│ 直播画面 ┌──────────────────────────────┐ │
│ │ [ 摄像头1 实时画面 ] │ │
│ │ │ │
│ │ │ │
│ └──────────────────────────────┘ │
│ │
│ 告警列表 │
│ ⚠️ 10:23:45 区域入侵检测 - 摄像头3 │
│ ⚠️ 10:22:30 人员聚集检测 - 摄像头1 │
│ ⚠️ 10:20:15 车辆违停检测 - 摄像头2 │
│ │
│ 左侧导航栏: │
│ 📊 Dashboard │
│ 📹 摄像头管理 │
│ ⚙️ 视频分析配置 │
│ 📋 告警管理 │
│ 📈 报告 │
│ 👥 用户管理 │
└─────────────────────────────────────────────────┘KAI 的核心操作就几个页面：
- Dashboard — 总览，看所有摄像头在线/离线状态、最近的告警
- Live View — 看实时画面，支持 1/4/9 分屏
- 摄像头管理 — 添加/删除/配置摄像头（这是你测的最多的）
- 视频分析配置 — 给每个摄像头配置 AI 分析规则（入侵检测、人数统计等）
- 告警管理 — 查看和处理 AI 产生的告警
- 报告 — 导出各种统计报表
2. 配置什么摄像头？在哪配置？需要到现场吗？
2.1 配置什么摄像头？
IP Camera（网络摄像头）。就是监控摄像头的意思。品牌可能是 Hikvision、Dahua、Axis 等。
每个摄像头有一个 IP 地址，通过网线或 WiFi 连接到网络。
2.2 在哪配置？
不是在现场拧螺丝，而是在 KAI 平台网页上添加摄像头。
具体操作流程（你在 QA 测试时会这样操作）：
第1步：在浏览器打开 KAI UP 网站，登录
第2步：点击左侧导航 → 摄像头管理
第3步：点击 "+ Add Camera" 按钮
第4步：填写以下信息：
┌──────────────────────────────────────┐
│ Camera Name: 停车场入口摄像头 │
│ IP Address: 192.168.1.100 │
│ Port: 80 │
│ Protocol: ONVIF ← 行业标准协议│
│ Username: admin │
│ Password: ******** │
│ Location: 1楼停车场入口 │
└──────────────────────────────────────┘
第5步：点击 "Test Connection" 测试连接
第6步：如果显示 "Connection Successful"，点击 Save
第7步：回到 Live View，看到画面出来了 → 摄像头配置成功作为 QA，你配置摄像头就是在测这个 “Add Camera” 流程：
- 填正确的 IP → 能不能成功？
- 填错误的 IP → 会不会提示友好错误？
- 填空的字段 → 会不会报错？
- 连上之后，画面能不能正常显示？
- 同时添加 10 个摄像头会不会卡？
2.3 ONVIF 是什么？
ONVIF 就是摄像头界的 通用语言。不同品牌的摄像头说不同的话，但 ONVIF 协议让它们都能跟 KAI 平台交流。
打个比方：你有一个日本牌充电器和一台中国牌手机，但只要都用 USB-C 接口就能充。ONVIF 就是摄像头界的 USB-C。
你不用懂 ONVIF 的技术细节，只需知道：配置摄像头时选 “ONVIF” 协议，填对账号密码就行了。
2.4 需要到现场吗？
实习生大概率不需要。 测试主要在实验室（Lab）进行。
┌─────────────────────────────────────┐
│ NCS 测试实验室 │
│ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │CAM1│ │CAM2│ │CAM3│ │CAM4│ │
│ │ │ │ │ │ │ │ │ │
│ └──┬─┘ └──┬─┘ └──┬─┘ └──┬─┘ │
│ │ │ │ │ │
│ └───────┴───────┴───────┘ │
│ │ 交换机(Switch) │
│ │ │
│ ┌────┴────┐ │
│ │ KAI Node │ ← 一台小电脑 │
│ │(边缘设备) │ 跑视频分析 │
│ └─────────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ 云端 │ ← KAI UP 网页端 │
│ │ KAI UP │ │
│ └─────────┘ │
└─────────────────────────────────────┘
↑ 你就在这个电脑上操作实验室内：
- 摄像头装在架子上，对着测试场景（可能是一个假的停车场模型、一个人偶）
- 你用电脑浏览器操作 KAI UP 配置、测试
- 你会需要在摄像头物理设备和电脑之间切换
偶尔需要去现场的情况（但你作为实习生几乎不会去）：
- 客户现场部署后的验收测试
- 需要在真实场景下测试（比如去停车场测车牌识别）
2.5 KAI Node 又是什么？
KAI Node 是一台放在摄像头旁边的小电脑（边缘计算设备）。
摄像头 → 视频流 → KAI Node(跑AI分析) → 结果上传云端 → KAI UP(网页查看)KAI Node 负责：
- 接收摄像头的视频流
- 跑 AI 模型做实时分析
- 把告警结果上传到云端 KAI UP
你测的时候也会配置 KAI Node：设 IP、注册到云端、升级固件等。
3. 怎么写 Test Case？
3.1 一个 Test Case 长什么样
Test Case = 写给别人的操作说明书。告诉另一个测试员（或者你自己两周后）：
“打开什么 → 输入什么 → 点击什么 → 应该看到什么”
3.2 标准格式
┌──────────────────────────────────────────────────────────┐
│ Test Case ID: TC_CAMERA_ADD_001 │
│ Title: 验证添加一个有效的 ONVIF 摄像头 │
│ Module: 摄像头管理 │
│ Priority: High │
│ Preconditions: 1. KAI UP 已登录 │
│ 2. 一个 ONVIF 摄像头已接电接网 │
│ 3. 知道摄像头的 IP/用户名/密码 │
│ │
│ Test Steps: │
│ 1. 点击左侧导航 "摄像头管理" │
│ 2. 点击 "+ Add Camera" 按钮 │
│ 3. 在 Name 字段输入 "测试摄像头-01" │
│ 4. 选择 Protocol 为 "ONVIF" │
│ 5. 输入 IP Address: 192.168.1.100 │
│ 6. 输入 Port: 80 │
│ 7. 输入 Username: admin │
│ 8. 输入 Password: admin123 │
│ 9. 点击 "Test Connection" │
│ 10. 确认显示 "Connection Successful" │
│ 11. 点击 "Save" │
│ 12. 返回 Camera List，确认摄像头显示 "Online" │
│ 13. 点击摄像头，进入 Live View │
│ 14. 确认画面在 5 秒内加载 │
│ │
│ Expected Result: │
│ - 摄像头成功添加，状态显示 Online │
│ - Live View 能正常播放视频画面 │
│ - 没有报错信息 │
│ │
│ Postconditions: 无 │
│ Status: □ Pass □ Fail □ Blocked │
│ Actual Result: (留空，执行时填写) │
└──────────────────────────────────────────────────────────┘3.3 一个 Test Case 的 3 个黄金法则
| 法则 | 解释 | 正确例子 | 错误例子 |
|---|---|---|---|
| 1. 每一步都要别人能照着做 | 不能省略细节 | ”在 Name 字段输入 ‘测试摄像头-01’" | "添加摄像头” |
| 2. 预期结果要可验证 | 是/否，不需要主观判断 | ”画面在 5 秒内加载" | "画面应该正常” |
| 3. 一个 Test Case 只测一件事 | 失败了知道哪里出问题 | 只测”添加摄像头”这一个功能 | 同时测添加+删除+修改+查看 |
3.4 你要写多组 Test Case
对于"添加摄像头"这个功能，你需要写：
┌────────────────────────────────────┐
│ TC_CAMERA_ADD_001 正常添加 ✅ │ ← 正常路径 (Happy Path)
│ TC_CAMERA_ADD_002 错误的 IP ❌ │
│ TC_CAMERA_ADD_003 错误的密码 ❌ │ ← 异常路径 (Error Path)
│ TC_CAMERA_ADD_004 空字段 ❌ │
│ TC_CAMERA_ADD_005 IP 已存在 ❌ │
│ TC_CAMERA_ADD_006 摄像头离线 ❌ │
│ TC_CAMERA_ADD_007 同时添加10个 │ ← 边界条件 (Boundary)
│ TC_CAMERA_ADD_008 名字超长特殊字符 │
└────────────────────────────────────┘3.5 你用 Excel 还是 TestRail？
行业内常用工具：
- Excel / Google Sheets — 小团队、入门
- TestRail — 专业的测试用例管理工具
- JIRA + Zephyr — JIRA 的插件，测试用例和 Bug 在同一平台
面试不用纠结用哪个工具，核心是 format 对不对。
4. 怎么找 Bug？
4.1 Bug 不在”去找”，而是在”去试”的过程中碰到的
你按照 test case 一步步操作：
Step 3: 输入特殊字符 "!@#$%^&*()" 作为摄像头名称
Step 4: 点击 Save
预期结果：提示 "名称包含非法字符"
实际结果：页面崩溃，白屏，控制台报错
→ 恭喜，你找到了一个 Bug！4.2 QA 找 Bug 的”第六感”（你慢慢会有的）
| 场景 | 作为 QA 你要想 |
|---|---|
| 输入”测试用摄像头” | 正常，测了 |
| 输入空字符串 | 😏 会不会报错？ |
| 输入 500 个字符的名字 | 😏 会不会溢出？ |
输入 '; DROP TABLE cameras;-- | 😏 SQL 注入？ |
| 快速连续点击 Save 按钮 | 😏 会不会提交两次？ |
| 摄像头断网再重连 | 😏 能不能自动恢复？ |
| 同时添加 50 个摄像头 | 😏 会不会卡死？ |
QA 的思维方式 = 正常用户 + 故意搞破坏的用户
4.3 Bug 报告的格式
你在 JIRA 里提一个 Bug，大概长这样：
┌─────────────────────────────────────────────────────┐
│ Summary: 摄像头名称包含特殊字符时页面崩溃 │
│ ─────────────────────────────────────────────────── │
│ Project: KAI UP │
│ Issue Type: Bug │
│ Priority: Major │
│ ─────────────────────────────────────────────────── │
│ Steps to Reproduce: │
│ 1. 登录 KAI UP │
│ 2. 进入 摄像头管理 → Add Camera │
│ 3. 在 Name 字段输入 "!@#$%^&" │
│ 4. 点击 Save │
│ │
│ Actual Result: │
│ 页面白屏，浏览器控制台显示 TypeError: ... │
│ │
│ Expected Result: │
│ 提示 "名称包含非法字符，请重新输入" │
│ │
│ Environment: │
│ - Browser: Chrome 125 │
│ - KAI UP Version: 4.3.2 │
│ - OS: Ubuntu 22.04 │
│ │
│ Attachment: │
│ [截图：白屏页面] [录屏：操作过程] │
│ │
│ Assignee: (留给开发 Lead 分配) │
└─────────────────────────────────────────────────────┘4.4 Bug 的严重等级
| 等级 | 含义 | 例子 |
|---|---|---|
| Blocker | 不能继续测了 | 登录页面崩溃，谁都进不去 |
| Critical | 核心功能坏了 | 摄像头添加不了 |
| Major | 功能有问题但能绕过去 | 名字有特殊字符崩溃，但不用特殊字符就行 |
| Minor | 不影响功能但体验差 | 按钮颜色不对 |
| Trivial | 基本不算问题 | 某个拼写错误 |
5. JIRA 是什么？
5.1 一句话
JIRA = 跟开发团队沟通 bug 的官方平台。你发现 bug 后写在 JIRA 上，开发看到了去修，修完了通知你验证。
5.2 QA 跟 JIRA 的关系
你(QA) JIRA 开发(Dev)
│ │ │
│── 发现 Bug ──────────→ │ │
│ 在 JIRA 上创建 Issue │ │
│ │── Issue assigned ──────→ │
│ │ │── 分析、修复
│ │ │
│ │←── Status: Fixed ────── │
│←── 通知你验证 ──────── │ │
│ │ │
│── 验证 Bug 是否修好 ──→ │ │
│ 如果修好了 → Close │ │
│ 如果没好 → Reopen │ │5.3 JIRA 的常见状态流转
Open(你创建)
│
├──→ In Progress (开发开始修)
│ │
│ ├──→ Fixed (开发说修好了)
│ │ │
│ │ ├──→ Verified (你验证通过，关闭)
│ │ │
│ │ └──→ Reopened (你验证没通过，重新打开)
│ │
│ └──→ Won't Fix (开发认为不是问题或暂时不修)
│
└──→ Duplicate (别人已经报过了)
└──→ Cannot Reproduce (开发还原不了你描述的bug)5.4 不用 JIRA 的话用什么？
NCS 面试官履历里提到用过 Redmine（跟 JIRA 类似的工具）。核心概念都一样：
- 创建 Issue → 描述 Bug → 分配给开发 → 追踪状态 → 验证关闭
6. QA 实习生一天的工作流程
假设场景：新版本 v4.3 发布前，你要测”添加摄像头”功能
09:00 ─ 晨会 (Stand-up)
"昨天我测了添加摄像头，发现了一个特殊字符崩溃的 bug，已提 JIRA。
今天计划测删除摄像头和修改摄像头配置。"
09:15 ─ 打开 JIRA
检查有没有分配给你验证的 bug（开发说修好了的）
09:30 ─ 验证 Bug
重现之前提的 bug，确认开发修好了 → 状态改为 Verified
如果没修好 → 备注原因，Reopen
10:00 ─ 执行 Test Case
打开 TestRail（或 Excel），找到 TC_CAMERA_DELETE_001
按照步骤测"删除摄像头"功能
测了 5 个 test case，全部 Pass
11:30 ─ 自由探索测试 (Exploratory Testing)
你不按 test case 来，随便点
→ 发现：删除摄像头后，Live View 还在显示画面（Bug！）
→ 写 JIRA Issue，附截图
12:00 ─ 午饭
13:00 ─ 配置测试环境
需要在测试实验室装一个新的摄像头
→ 拿一个 Hikvision 摄像头，接网线，通电
→ 用笔记本电脑浏览器访问摄像头 IP，确认能连上
→ 在 KAI UP 上添加这个摄像头，为下午的测试做准备
14:00 ─ 继续执行 Test Case
测试"修改摄像头配置"
测了 8 个 test case，7 个 Pass，1 个 Fail
→ Fail 的那个：修改分辨率后不生效 → 提 Bug
15:30 ─ 写测试报告
今天执行了 15 个 test case
Pass: 12 | Fail: 2 | Blocked: 1
新提 Bug: 2 个
汇报给 Senior QA
16:30 ─ 学习/培训
看文档、学习 KAI 平台的新功能
或者 Senior QA 给你讲解某个功能怎么测
17:00 ─ 整理 JIRA、写明日计划
更新今天 Bug 的状态
"明天计划测：告警管理模块"7. 一个完整的实战例子
场景：你作为实习生，接到任务”测试摄像头添加功能”
Step 1：理解需求
开发说：这个版本支持通过 ONVIF 添加摄像头了
你想：
- 什么条件下能成功添加？
- 什么条件下会失败？
- 添加后画面能不能看？
Step 2：写 Test Case（在 Excel 里）
| ID | Title | Steps | Expected |
|---|---|---|---|
| TC-001 | 正常添加摄像头 | 1. 点添加 2. 填正确信息 3. 保存 | 添加成功，显示 Online |
| TC-002 | 错误的 IP 地址 | 1. 点添加 2. 填 999.999.999.999 3. 保存 | 提示”无法连接” |
| TC-003 | 错误的密码 | 1. 点添加 2. 填正确 IP，错误密码 3. 保存 | 提示”认证失败” |
| TC-004 | 名字超长 | 1. 点添加 2. 名字填 200 个字符 3. 保存 | 提示”名称最长 50 字符” |
| TC-005 | 重复添加同一摄像头 | 1. 添加摄像头A 2. 再添加一次摄像头A 3. 保存 | 提示”该摄像头已存在” |
Step 3：执行测试
TC-001: Pass ✅ → 正常
TC-002: Pass ✅ → 提示"Unable to connect to camera"
TC-003: Pass ✅ → 提示"Authentication failed"
TC-004: Fail ❌ → 页面崩溃了！ → Bug！
TC-005: Pass ✅ → 提示"Camera already exists"Step 4：提 Bug 到 JIRA
Summary: 摄像头名称输入超长字符导致页面崩溃
Priority: Major
Steps: 添加摄像头 → 名字填 200 个字符 → 保存 → 白屏
Expected: 提示"名称过长"
Actual: 页面崩溃，需要刷新Step 5：写测试报告
测试模块: 摄像头管理
Test Cases: 5 Pass, 1 Fail
新发现 Bug: 1 (名称超长崩溃)
状态: 阻塞 — 需要开发修完再继续测8. 面试能说的版本
面试官问”你理解 QA 实习做什么吗？”
推荐回答： “我理解 QA 实习生的核心工作是 通过执行测试用例来发现产品的问题。
具体来说，我了解到的工作流程是：
- 先看需求文档，理解这个功能应该怎么工作
- 写测试用例——包括正常路径（正常添加摄像头）和异常路径（错误的 IP、空字段）
- 执行测试，记录结果
- 发现问题就提 Bug 到 JIRA（或者 Redmine），附上操作步骤、截图、环境信息
- 开发修好后我再去验证，确认修好了就关闭
比如配置摄像头这个场景——不是在现场装硬件，而是在 KAI UP 网页上添加摄像头，测试添加流程有没有 Bug、配置页面能不能正常用、添加后能不能看到实时画面。
虽然一开始可能做的更多是 手动执行测试用例和提 Bug，但我希望在熟悉流程后，能主动把重复性的测试写成 Python 自动化脚本，提升效率。我在 Smart Bakery 项目里已经做过类似的事情——用 pytest 写 API 自动化测试。“
面试官问”你用过 JIRA 吗？”
“在学校项目里还没有实际用过，但我了解它的核心流程：提 Bug → 分配给开发 → 开发修复 → 我验证 → 关闭。它的概念跟 GitHub Issues 类似，都是追踪和管理问题的平台。如果公司用 JIRA，我相信半天就能上手。“
面试官问”你觉得什么样的 Bug 值得提？”
“只要是 用户实际使用中可能遇到的问题，都值得提。哪怕只是一个按钮颜色不对或者提示文字有错别字，因为这些问题会影响用户体验和专业度。
但我会判断优先级：登录不了（Blocker）> 添加摄像头失败（Critical）> 某次功能不正常（Major）> 界面排版问题（Minor）。
而且我发现 Bug 后会先确认能不能稳定复现——如果能每次都复现，我才会提；如果时好时坏，我会先录屏加上日志再提，方便开发定位问题。”
说明：本文档用最直白的语言解释 NCS QA Intern 的日常工作，把”配置摄像头”、“写 Test Case”、“JIRA”这些抽象概念变成你能看懂的实操场景。面试时不需要背所有细节，重点是用”我知道具体干什么活”来展示你做了功课。 最后更新: 2026-06-10