用Fiddler发现这些问题
前面我详细说明了二类低级错误的危害，下面再来说说如何尽早地发现它们。
我想许多人都应该用过Fiddler，它能够方便地让我们知道浏览器发起的每个请求的Request/Response，通常用于调试程序。
在Fiddler中，404错误的请求会用红字醒目地显示，每个请求的响应长度也会单独地显示出来，貌似直接用Fiddler也能容易发现404错误以及较大的响应输出问题。
然而，当访问过多的页面后，Fiddler会显示非常多的请求记录，因此，那些低级问题会被淹没，我们要想发现它们，可能需要花费一点时间。
针对这个问题，我为Fiddler定义了二个规则：
只要打开它们，前面所说的二类低级问题很容易就能发现：
注意：这里只显示符合规则的请求（存在低级问题的请求）。
该怎么合理地使用这个方法呢？
1、如果你是开发人员，请在自测时，打开Fiddler，并选择我定义那二个规则，
2、如果你是测试人员，请在测试时，打开Fiddler，并选择我定义那二个规则，
3、然后，你们平时该做什么就做什么吧，。。。。。。
4、测试结束后，再看一下Fiddler窗口，有没有记录显示出来，如果有，那就是发现低级问题了。
所以，我认为这个方法不会给开发人员以及测试人员带来过多的负担，毕竟，这个方法不会给他（她）们测试时增加任何负担，唯独要求打开一下Fiddler，最后在测试完成后，再来看一眼，仅此而已。
或许有些人认为：分析服务器的IIS日志，也能发现这二类问题。
是的，我知道分析IIS日志也能发现这些问题，但是，分析IIS日志，是不是晚了？
你想过没有：这样的问题是不是已经影响了用户？
反之，不让用户【体验】这些问题，是不是更好？
换句话说：你是否希望发布一个有缺陷的程序？
