写在开始
　　在做白盒测试调研走查代码时，听到大家抱怨最多的问题往往会涉及下面两点：
　　算法太复杂，看不明白
　　一堆设计模式，感觉没啥用，看着还费劲，不明所以
　　对于这两点，小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在学校里学的那些入门算法），但不断的认识和经历使我知道两者并不是对立的，相反必须并存。
　　所以大家按需要或者兴趣去学习吧，建议广度上都要了解一点，深度上可以有所取舍。