当软件测试遇到算法和设计模式
作者:搜狗测试 fangyu.me 发布时间:[ 2016/7/7 10:07:25 ] 推荐标签:算法 设计模式 框架
写在开始
在做白盒测试调研走查代码时,听到大家抱怨多的问题往往会涉及下面两点:
算法太复杂,看不明白
一堆设计模式,感觉没啥用,看着还费劲,不明所以
对于这两点,小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在学校里学的那些入门算法),但不断的认识和经历使我知道两者并不是对立的,相反必须并存。
所以大家按需要或者兴趣去学习吧,建议广度上都要了解一点,深度上可以有所取舍。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11