面向测试用例的编程思想和学习方法

面向测试用例的编程思想和学习方法

最近想到的一些东西，也许比较肤浅，也有些论据不太准确。

关键词：

演绎法 实验数据 图灵的模仿游戏 构造好的用例 触发各层逻辑 分析问题 检验结果

困难的问题分析起来其实是很有意思的，特别是对于一些已经有答案的问题，如果回溯回去按照答案分析一遍往往会有脑洞大开的感觉，很多人逃避困难的问题实际上是不知道解决和分析问题其中的乐趣。

最近看到KMP字符串匹配的算法，感觉如果使用实际的比较好的例子推演一遍的话，就能够深入分析到其中的精髓了，也就是使用一个能够触发算法各个逻辑的用例来，从底层的计算过程推演一遍，就能够深入了解到算法的过程。

同时我们也知道其实很多物理学理论是猜出来的，比如牛顿的重力加速度定理，也许开始就是猜的，之后的实验一再验证他的证券性，我们也就认定它这是对的了。

还有相对论，具体证明过程估计也很复杂，但是当时没有例子证明他成立的时候，很多人也是抱着怀疑的态度的，直到相对论的一些推论、一些预测到的现象被观测到，科学界才真正认可了这一理论。

还有之前看的模仿游戏，也就是图灵实验，如何验证机器具有智能，就是找来机器和人类同时问一些问题，看回答是否一致，以此判断机器是否具有智能。

我们放开了说，你想知道你老婆爱不爱你，该怎么做？是去找算命的算，还是钻进你老婆的脑子里看看你老婆真的想的是什么。但是我们都知道其实这些都不靠谱，最靠谱的方法是从一些实际的事情中去验证，如果她爱你会怎么样，如果她不爱你会怎么样。学过概率论的人都知道，样本越大，可信度越高。同样，一些事情的权重也是不同的，一两件事也许说明不了什么随机性比较高，几百上千件事情就很能说明问题了。

还有些人喜欢胡思乱想，其实想到的一些东西如果永远触发不了，那这些想法也是没有意义的。计算机是一门科学，而科学最重要的就是可验证性。就如实验物理学和理论物理学同等重要。以前一直不理解实验物理学的发现为什么也能获得诺贝尔奖，后来才认识到发现一些例子的重要性，没有被验证的理论还是比较单薄的。

回到正题我们编写的程序，你怎么知道结果对不对？还是要通过用例验证，比较菜的人很多时候写代码的时候感觉是对的，但是写完结果就是不对，很多时候就是这么邪门，那么最好的办法就是边写边测。不要堆到最后再测，也就是单元测试越早越好。

同时怎么学东西最快？还是用例，构造一些好的用例，能够覆盖学习目标的所有重点难点以及各种场景，从头到尾演绎一遍，整个东西也就懂了至少7成，剩下几成多练几遍自然就懂了。我们学东西的时候要多想想这些东西在实际生活中或模型中是如何触发和起作用的。真的想明白了才算是真的懂了。

还有你怎么知道哪些东西是重点，有用的？还是通过用例，有些东西永远都触发不了如何证明他是有用的。而你写的一些代码如果没有完善的用例又如何证明他是健壮和有用的。

也许是我孤陋寡闻，眼见许多程序员和设计者不重视用例和可测性，写出来的东西都是坑，真的很惋惜。

程序员做的东西很多bug明明自己在开发阶段的单元测试就能测出来，非要放到集成测试的时候交给测试人员搞白盒测试，然后经历漫长的测试定位过程和一个又一个通宵，劳命伤财。

有些所谓的架构师和设计人员，在设计阶段就没有考虑清楚实际的场景，没有充分模拟实际情况，就草率的给出方案，结果到了coding和部署阶段，所有的问题都堆到苦逼的程序员和交付人员那里，从底层开发考虑解决上层设计的问题，算起来浪费了大量人力物力。

所以我的建议是要重视测试和测试用例，包括在设计阶段和coding阶段，为了自己，也为了他人。