写在开始
在做白盒测试调研走查代码时，听到大家抱怨最多的问题往往会涉及下面两点：
-
算法太复杂，看不明白
-
一堆设计模式，感觉没啥用，看着还费劲，不明所以
对于这两点，小W也是深有体会。第一点也许还好点，以前是从算法和数据结构入门的，但曾经也被我们浏览器里的一个名单算法折腾过一个礼拜；第二点就经常被戏弄了，看到个observer 或者adapter，一开始时甚至于看到个singleton还得一点点看源码实现，不仅效率低，而且经常把自己看的晕晕乎乎，就算看明白了，往往也抓不住要害。正如 singleton里，代码基础不好又没接触过单例模式的，就很有可能就把那个static给忽略了，还会埋怨开发闲的蛋疼搞这么个东西。
那么有什么好办法吗？很遗憾，目前小W还没有发现。所以我也一直认为一个优秀的测试开发要具有一定的开发经验。最理想是你能知道产品代码这么设计、算法这么搞，会有哪些隐患问题。当然现状下这些并不现实（至少小W自己做不到），所以退而求其次应该能看懂（至少开发给你讲后能听懂）代码里的各种算法和设计模式。
当然，这篇文章也不能白写，下面就简单介绍小W在这方面的一些测试经验。
算法的测试
还是上面说的，你能看懂当然最好，针对不同的逻辑分支设计测试用例，考虑各种边界情况。不过除此之外，也还有些别的办法：
-
让算法的实现者给你讲解一遍这个算法，最好能对着代码讲，要是讲不清楚那代码质量可想而知，讲清楚了往往就能发现一两个Bug（代码有Bug的前提下）；
-
借鉴一些已有的数据，用来测试你的算法（比如以前测试URL时，找网址导航、淘宝之类网站抓几百个URL测试下，至少能保证大部分情况是OK的）
-
用随机算法生成一些测试用例（这个是以前做算法比赛得出的经验，代码不正确，随机生成几百几千条Case看看，一般都能找到错误）
设计模式
这里为何不加测试二字，因为设计模式不是代码，只是因为你不了解某个设计模式，让你在看代码时特别难受。也没什么好的办法，把设计模式都了解下当然好，不过解不了燃眉之急，下面小W就把一些常见的设计模式以及关键词罗列下，大家看到一个查一个好了。
23种常见的设计模式：
创建型
-
Factory Method（工厂方法）
-
Abstract Factory（抽象工厂）
-
Builder（建造者）
-
Prototype（原型）
-
Singleton（单例）
结构型
-
Adapter Class/Object（适配器）
-
Bridge（桥接）
-
Composite（组合）
-
Decorator（装饰）
-
Facade（外观）
-
Flyweight（享元）
-
Proxy（代理）
行为型
-
Interpreter（解释器）
-
Template Method（模板方法）
-
Chain of Responsibility（责任链）
-
Command（命令）
-
Iterator（迭代器）
-
Mediator（中介者）
-
Memento（备忘录）
-
Observer（观察者）
-
State（状态）
-
Strategy（策略）
-
Visitor（访问者）
写在最后
看完这些有些同学可能已经想去学了，这时疑问又来了，哪个更重要？
曾经一度痴迷于算法小W连OO都少用更别说设计模式了，可是工作后接触实际的项目多了，发现现软件设计不是一两个算法和数据结构就能解决，当我不断地怀疑的时候，于是我找到了OO，接触了框架，然后遇上了设计模式（都是入门级）。然后又因为OO而藐视算法（小W在学校里学的那些入门算法），但不断的认识和经历使我知道两者并不是对立的，相反必须并存。
所以大家按需要或者兴趣去学习吧，建议广度上都要了解一点，深度上可以有所取舍。
