胡侃测试

满打满算,我也只做过不到四年的测试,奇怪老是有后来人前辈前辈的请教测试的问题。每当此时,我都心怀愧疚,因为我实在对测试没有什么很深的体会,也不知道如何回答这些问题。虽然已经两年多不做测试了,但是一些想法仍不时的冒出,萦绕在我的脑海里。不如记下来,大家探讨探讨吧。不过这里讨论的只是普通测试人员的一些事情,毕竟我入行尚浅,且半途而废,实在讨论不了什么高深的玩意。

什么是测试

以前也会当面试官,好像这个题目没有提出。如果还是有机会面试偏测试的人员的话,这个题目当然是居家旅行,必备良药了。

经典的《软件测试的艺术》(已经出到第三版了)曾经这样定义软件的测试:测试是为了发现错误而执行程序的过程。其实这个就是俗称找bug,几乎测试人员大部分时间就是在干这些活。具体一点,就是每个产品都是明确的需求,它会有很严格的功能说明,这个过程就是通过使用软件,来找出那些实际结果和预期结果不同的情况。如果找到了,恭喜您,赶紧报bug吧。

但是我认为,测试人员还有一个非常重要的任务,就是去明确产品里不确定的那些需求。千万不要小看这个任务,我觉得这才是体现一个测试人员核心价值之所在。神马意思?产品的功能不都写在需求文档里面的吗,白字黑字,就差一个公章了,难不成还有漏网之鱼?

对了,还真有,而且找到了,都是大鱼,肥硕肥硕的,够开发吃好几顿呢。我举个最简单的例子,世人皆知 1+1=2这个朴实的真理,不然怎么赚钱呢?但是任何真理只在特定场景中生效。不信?草原东有一群羊,西有一群羊,两群羊合并到一起,还剩几群羊呢?要是东有一群羊,西有一群狼,呃…当然这些个例子不是太合适。还是举一个测试例子,比如有这样一个输入框,需求写着输入数字。这就是一个典型的不确定的需求,这个数字是正整数,负数,有理数,无理数,难不成虚数也可以?

当然这需要测试人员有很深厚的功力,对产品有很深刻的见解,具体怎么做,不是我所能够解释得了的。

测试方法

以前面试,我喜欢问一些教科书的理论知识,比如一些常见的黑盒白盒测试方法,一些家伙对此很不理解,觉得这些玩意有啥用啊,就背书没意义吧。

其实,所有人都知道,测试用例是无限的,而测试资源却是有限的,这有限的资源,如何去执行无限的测试用例呢?这时,这些知识就派上用场了。比如等价类划分吧,既然测试用例是无限的,那就把这些无限的用例划分成有限的集合,这样不是把无限变有限了吗?这时,只需要抽取有限集合的代表元素执行就行了。

还有一些是从实际中来,根据一些统计得出软件在什么情况下最容易出错,而得出的一些方法。比如边界值分析,呵呵,一般测试边界值,一抓一个准啊。

总之,一些测试理论方法还是要学习,并用到具体测试中去。

测试工程师的未来

现在流行啥全栈工程师,就是有很扎实的基础,然后在具体方向上多点开花。不过对于测试工程师的未来,向开发工程师的偏向,应该是一个方向。因为随着技术的发展,很多以前手工的测试,已经可以通过自动化方式进行了。所以测试工程师需要很好的开发基础,也是避免不了的。

当然按全栈工程师的倾向,也许测试工程师也需要运维等能力。个人觉得以后测试项目就是一个开发项目了,需要运维搭建测试环境,开发测试脚本,执行测试脚本,分析测试结果。所以,似乎开发、测试好像也不会分得那么清楚了。

胡侃一下曾经从事过的测试行业,希望对一些人有一点点帮助