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

什么是测试

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

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

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

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

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

测试方法

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

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

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

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

测试工程师的未来

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

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

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