用Fiddler发现这些问题

　　前面我详细说明了二类低级错误的危害，下面再来说说如何尽早地发现它们。

　　我想许多人都应该用过Fiddler，它能够方便地让我们知道浏览器发起的每个请求的Request/Response，通常用于调试程序。

　　在Fiddler中，404错误的请求会用红字醒目地显示，每个请求的响应长度也会单独地显示出来，貌似直接用Fiddler也能容易发现404错误以及较大的响应输出问题。

　　然而，当访问过多的页面后，Fiddler会显示非常多的请求记录，因此，那些低级问题会被淹没，我们要想发现它们，可能需要花费一点时间。

　　针对这个问题，我为Fiddler定义了二个规则：

　　只要打开它们，前面所说的二类低级问题很容易能发现：

　　注意：这里只显示符合规则的请求（存在低级问题的请求）。

　　该怎么合理地使用这个方法呢？

　　1、如果你是开发人员，请在自测时，打开Fiddler，并选择我定义那二个规则，

　　2、如果你是测试人员，请在测试时，打开Fiddler，并选择我定义那二个规则，

　　3、然后，你们平时该做什么做什么吧，。。。。。。

　　4、测试结束后，再看一下Fiddler窗口，有没有记录显示出来，如果有，那是发现低级问题了。

　　所以，我认为这个方法不会给开发人员以及测试人员带来过多的负担，毕竟，这个方法不会给他（她）们测试时增加任何负担，唯独要求打开一下Fiddler，后在测试完成后，再来看一眼，仅此而已。

　　或许有些人认为：分析服务器的IIS日志，也能发现这二类问题。

　　是的，我知道分析IIS日志也能发现这些问题，但是，分析IIS日志，是不是晚了？

　　你想过没有：这样的问题是不是已经影响了用户？

　　反之，不让用户【体验】这些问题，是不是更好？

　　换句话说：你是否希望发布一个有缺陷的程序？