Day5:用户端用例执行与缺陷管理

日期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 提速。再次感慨用例设计的精髓在实际执行的时候看着自己之前设计出来的那些多条件高级检索的“分层降维打法”、弱网下的“防抖/防重复点击”用例在实际点击的一瞬间真的非常感慨那些看似死板的方法论在实操中完美闭环极大地开拓了我的测试思维让我真切感受到了作为测试的成就感。