答案

问题历史：

随着软件复杂性的增长，人们发现有些bug仅在测试用例或规范之外被发现——通常这些bug对真实用户而言是最关键的。为了寻找此类缺陷，测试人员使用特殊的技巧，结合标准测试与自身经验。

问题：

与组件交互、对不明显情况的处理不当或缺乏要求相关的隐藏bug是最难发现和记录的。测试人员常常不确定是否要记录发现的问题，如果它“未在技术规范中列出”。

解决方案：

使用探索性测试、对等测试的方法，结合对类似产品的经验。始终尽可能详细地记录此类bug：步骤、观察结果、为什么认为它们是缺陷、相关需求的链接或已接受的逻辑。

关键特点：

• 需要主动性和批判性思维。
• 重要的是要论证为什么这确实是个缺陷。
• 在某些情况下，需要参与与分析师/PO的讨论。

陷阱问题。

可以不记录或忽略未在需求中描述的bug吗？

不可以，始终要报告，即使没有确切的要求链接，否则严重的问题会传递给客户。

用户不便是bug还是改进（功能请求）？

如果行为明显不合逻辑，导致混淆或风险，则记录为bug，否则记录为改进。

测试人员是否应就每个不明显的bug与团队咨询？

建议事先与分析师或开发人员讨论有争议的案例，以避免无意义的工单。

常见错误和反模式

• 忽视用户明显的缺陷，这些缺陷未在需求中列出。
• 对隐藏bug的记录不足/不完整。
• 缺乏对bug报告的论证。

生活实例

负面案例

测试人员注意到，当同时打开两个窗口时，系统会崩溃，但没有记录bug，因为该场景未在需求和测试用例中描述。

优点：

• 没有增加“多余”的bug，给开发人员的其他任务留下了空间。

缺点：

• 系统以严重的漏洞发布，客户受到影响。

正面案例

测试人员记录了一个bug，描述了步骤（打开两个窗口，操作顺序），附上了截图，解释了为什么认为这是个bug（真实用户可能会遇到这种情况）。

优点：

• bug迅速被修复，最终用户没有遇到问题。

缺点：

• 需要时间与分析师讨论场景。