欢迎光临
梦想从学习开始!

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

本文主要介绍软件测试遇到算法和设计模式| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  
写在开始

  在做白盒测试调研走查代码时,听到大家抱怨最多的问题往往会涉及下面两点:

  
算法太复杂,看不明白

  一堆设计模式,感觉没啥用,看着还费劲,不明所以

  对于这两点,小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在学校里学的那些入门算法),但不断的认识和经历使我知道两者并不是对立的,相反必须并存。

  所以大家按需要或者兴趣去学习吧,建议广度上都要了解一点,深度上可以有所取舍。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 当软件测试遇到算法和设计模式| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏