【Access小品】吹毛求疵－－测试与容错的思路和方法

时　间:2012-11-14 18:51:40
作　者:煮江品茶   ID：10802  城市：武汉
摘　要:【Access小品】吹毛求疵－－测试与容错的思路和方法
正　文:

　　一个程序编写完成后，总是需要进行一些测试的。程序的测试据说分为“白盒”和“黑盒”两种，白盒大体是指已知程序的处理逻辑，测试其输入是否能得到正确的输出。黑盒大体是未知程序的处理逻辑，测试输入后是否得到合理的结果。黑盒测试对于优化程序，特别是设计容错功能非常重要。

　　到底黑盒测试怎么个搞法，以及搞完了还能干些什么呢？这个问题不能泛泛而论，弄一个例子你就清楚了。于是乎决定就借用王站最近对论坛的一个小的修改来进行说明。王站最近似乎在对OFFICE中国论坛进行一些优化，今天我看见其中对分页导航上加了一个功能，这个功能是通过一个文本框输入数字，回车后直接跳转到指定页面。对这个功能做了一下测试，发现不够完美，其容错功能写得不够好。

　　测试情况如下：

　　１、当输入1到1000的整数时，页面跳转正常。
　　２、当输入小于0的整数时，页面跳转到1。
　　３、当输入大于1000的整数时，页面跳转到1。
　　４、当输入1到1000含有小数的实数时，页面跳转到取整后的值。
　　５、当输入非数字字符时，页面跳转到1。

　　从测试结果看，有这么几个问题，其一是1000以后的分页导航功能没有（Access常规交流目前实际为1176页）；其二是大于1000页时（合理的是大于1176页时），不应跳转到1而应该是尾页；其三是非整数（包括含小数的实数和其他字符）的处理均需要访问服务器，而不是在浏览器端得到校验。

　　从测试的结果，该如何最简单合理的进行改进呢？最容易想到的思路是按照既有的文本框控件来增加容错的处理逻辑，不过这个方法并不好，因为需要写许多的代码。那么什么是比较好的处理方法呢？这就要提到一个html标签了，它就是select，这个select有些近似于Access中的组合框控件，在html或者web中人们多称其为下拉列表框。这个控件与Access中的组合框有一个显著的区别，就是不能接收输入的字符，而只能进行选择。它的这个特点常常使人头疼，有好事者为此写过多种将文本框与下列列表框合并起来的ui控件，我记得我也曾在论坛中写过一个。不过恰恰是这个特点用于分页导航是再好不过了，因为你不必去做1到1176页以外任何其他情况的校验，这些例外或异常的情况本身就不在你的select所呈现的数据中间。所以用一个下拉列表框来做分页导航，你只是需要将分页的数据从服务器端写到浏览器端而已，甚至在数据量很大（1176就算比较大了）还可以按照10进位或者20进位，以使分页导航更为合理。

　　就这个问题再仔细观察一下，分页导航还可以进一步优化。用一个span标签标注一个1000页似乎没有任何意义（除非确实不允许查询1000页以后的内容）。我在想可能王站觉得读取论坛标题记录条数并换算成总页数太麻烦，可是我又不理解总页数似乎已经得到了（因为我看到了总页数就是1176），所以这是个令人费解的问题。还有一个问题也是令人费解，就是那个下一页的导航按钮，既然有下一页的导航按钮，那么总应该有上一页的导航按钮。不过用上一页和下一页导航与直接点击当前页前后的数字其功能是完全相同的。所以删除现在的下一页按钮，是不影响导航功能的。如果是需要照顾到用户的不同使用习惯，那就应该再加上一个上一页的导航按钮。更完美一些，还应该加上首页和尾页导航按钮。

　　说了这么多，好像都很有道理，真是这样吗？其实不然！为什么呢？因为我讨论的是局部问题。就局部来看，以上的论述确有其道理。对局部问题的评估需要放在整体上考虑，从整体上讲王站修改前后的导航功能实际上没有大的问题，也就是说上述讨论到的问题都不可能导致导航功能上的重大缺陷。那么这样看问题，就不必在此类问题上纠结了。这样说的目的是要告诉同志们，在程序开发中我们通常都需要注意不要纠缠于细微的缺陷，把大把的时间耗费在没什么意义的事情上去，我们只要知道在那些局部存在些什么不够完善的地方就行了。