日期：2026-6-29
🛠 一、 做了什么
全面执行用户端功能与专项测试用例：对之前设计好的 160 条+ 用户端核心用例进行了逐一的实操执行。
完成了用例状态的全面梳理：在本地的禅道开源版环境里，完成了对所有用例的实际结果判定（包括标记为“通过”、标记为“失败”、以及标记为“阻塞”的用例）。
完成了企业级 Bug 提报：在发现系统实际表现与预期不符时，独立在禅道中提交了多个维度的 Bug 单，打通了“用例 -> 缺陷”的闭环。
🔍 二、 遇到了什么问题
在实际点点点和走流程的过程中，遇到了好几个让我纠结和卡壳的经典实战问题：
状态判定纠结：由于手机注册的短信功能根本没闭环（发送不了验证码），导致后续步骤完全无法进行。我当时很纠结，在第二步我到底是该选“失败”还是选“阻塞”？
批量阻断不知所措：由此引出一大串依赖短信的同类用例，我是不是要把它们全部设为阻塞？这些被卡住的用例，我是应该每一个都提一个 Bug，还是合起来提一个总的 Bug？
工具限制与概念混淆：在禅道开源版里执行用例时，我一度执着于寻找“批量关联 Bug”的按钮，把“用例关联 Bug”和“一个 Bug 覆盖多个受影响用例”的概念搞混了。
Bug 类型分不清：在提 Bug 选择分类时，卡在了一些看似模糊的选项上，特别是搞不懂【代码错误】、【设计缺陷】与【标准规范】它们之间具体的边界在哪里。
专项测试无从下手：在测到一些非功能用例时（比如：“检查图片/链接是否是 HTTPS 加密传输”、“不同分辨率与缩放比下的自适应”），一时间不知道在电脑上具体该怎么搭建环境去测，有点抓瞎。
💡 三、 怎么解决的（How I Solved It）
在技术导师（AI）的引导下，我一步步解决了这些卡点：
理清了失败与阻塞的区别：明白了功能做完但结果不对叫“失败”，前置条件不通导致后面根本没机会测叫“阻塞”。所以手机号注册第二步我果断选了【阻塞】。
掌握了“阻断挂起”策略：
先在 Bug 模块单独提了一个大核心 Bug：
【阻断】由于短信通道未闭环...。然后在用例列表里，通过【批量执行】将 ID 13、14、15、17、18 等受影响用例一键置为“阻塞”。
野路子绕过开源版限制：因为禅道开源版没有原生的双向关联字段，我灵活运用了“穷人版双向绑定”——在用例批量编辑的【备注】里写上
关联 Bug #1，在 Bug 的【重现步骤】里写上受影响用例：#13, #14...。吃透了 Bug 类型的本质：
预期跳转与实际跳转不符：属于开发把正确的需求写错了，选【代码错误】。
裂图/破损图：选【代码错误】。
开发完全按需求写的但逻辑有漏洞（比如修改密码没设计“二次确认”）：选【设计缺陷】。
解锁了高级测试工具隐藏技能：
测加密传输：不要盲目去“另存为”，直接在网页右键
Inspect（检查元素）查看src源码，或者右键Copy image link，成功揪出了商城 Banner 图使用http裸奔的系统漏洞。测分辨率与缩放比：学会了不需要改 Windows 系统，直接用 Chrome F12 的Device Mode输入
1920x1080、1366x768模拟不同屏幕，用Ctrl + 加减号瞬间模拟 125% 和 150%的缩放，完美验证了界面的自适应兼容性。
🎯 四、 学到了什么
体验了完整的生命周期：这次实操让我真正完整走了一遍【用户需求 -> 研发需求 ->测试用例 ->执行用例 -> 提 Bug 追踪】的全流程。这种全链路的视角，让我不再是一个只会盲目点点点的局外人。
重新认识了 Bug 单的含金量：我知道了一个正规的企业级 Bug 单应该包含【缺陷标题】、【前置条件】、【复现步骤】、【预期结果】和【实际结果】，并且标题还要遵循
【系统/模块】+现象+特定条件的规范。不仅如此，我还学会了附带 F12 抓包定位作为加分项，给开发修 Bug 提速。再次感慨用例设计的精髓：在实际执行的时候，看着自己之前设计出来的那些多条件高级检索的“分层降维打法”、弱网下的“防抖/防重复点击”用例，在实际点击的一瞬间，真的非常感慨！那些看似死板的方法论在实操中完美闭环，极大地开拓了我的测试思维，让我真切感受到了作为测试的成就感。
