虫子狩猎策略？

假设您在软件相当复杂的部分的功能测试中发现了一个错误.它可能源于数据库中的错误/意外数据,中间层代码或前端的某些内容.

精细.我们都去过那儿.

你有单元测试来编写和运行,调试/记录语句要插入,sql语句要编写和运行,你要用FireBug检查的东西等等.

假设第一步是提出您想要调查的潜在原因列表.

现在你必须决定做什么顺序.

你呢:

根据直觉调查订单中的原因？

调查原因从最快检查到最慢检查？

假设该错误是特定于此功能的,并从大多数特定于功能的代码调查到最不具体的特定代码？

假设这是别人的错,并从最常见的代码调查到您的特定代码？

我没有提到的其他东西？

我有一种感觉,第一种策略是最常用的.也许只是因为我不与许多初级开发人员合作,而更多高级开发人员倾向于拥有体面的直觉.或许我们只是认为我们有不错的直觉,但应该使用更系统的方法.

有什么想法吗？

1> John Paulett..：

---

我发现Rubber Duck Debugging策略也很有效.

---

我一直听到计算机科学教授在他办公室前面有一只毛绒熊的故事(可能是伪造的).在办公时间内,任何想要问他问题的学生都必须先问熊.如果学生在询问熊之后仍然无法解决问题,那么学生可以询问该教授.我的妻子正在学习编程 - 我想我会尝试在这个角色中雇用我的猫(特别是那个聋哑人.)