关于程序测试小记

忙乎了近一个多礼拜，所有的时间和精力都花在了程序的测试上面。比较写code的时间，这已经是它好多倍了。让我有些措手不及的是，程序没有编译上的错 误，但是测试运行的结果并非像我们预测的那样的完美。我完全不清楚是自己算法本身的缺陷，造成某个问题没有办法很好解决，还是我在编写程序上有了失误。因 为测试的结果有一部分显示很正常，而似乎在处理有些条件下的输入的时候就有了差错了。我们想无头苍蝇那样，撞了很多次壁，也没有弄清楚问题所在，有些沮 丧。

  程序中有一个函数，其自变量d的取值为[min,max],我们要在这个区间中找到是有能让f(x)为零变量，及测试f(x)在这个区间上是否穿越了X 轴。使用的方法很简单，先用粗略的采样区间比如t=(max-min)/10000.0这样的间隔来分别算出各自的值，然后判断相邻的两个数的成绩是否小 于零。当然有时候你的取样间隔就成了关键的问题所在。一种先入为主的观念就是轨迹圆的方程不会很大，所以这个d的取值范围应该很小才对，一直认为他们之间 [max-min]在平分多少份就可以满足需求了。结果这个陷入为主的想法，把我挡在了正解的边缘。

Thread 5 has entered into ^_^
 max and min are 73.04481725355387:0.4966007122005891
 original d is 0.5328748204712658 distance is 0.2412947474691374
 original d is 0.5691489287419425 distance is 0.4509871765772213
 original d is 0.6054230370126191 distance is 0.5994128821785287

而后来的测试结果，令我大吃一惊。max的最大值为73多，所以无论你在平分多少万份都不能达到一个很精确的效果。正常情况下的精确值为10的负8次方。 所以这样一来间隔就很大了，就会略过许多值了。结果可以想象。继续测是发现，在[0.49,73.0]中真正有效值仅为[0.49,16.5]，所以这个 73.0首先把你的取样间隔放大，然后在让程序做一些无效的计算。所以要考虑优化算法。

  所以，总结起来，不要盲目去测试和调试程序，如果不知道真正的问题所在，首先确保程序编写没有问题，然后再去检查测试的结果，分析其执行的过程的数据，我想这样是有一定帮助的。

  这是一门好大的学问，只有经验的积累和自己的探索，才能做得又快又好。