您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

当软件测试遇到算法和设计模式

发表于:2017-01-09 作者:搜狗测试 fangyu.me 来源:

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