满打满算，我也做过四年的测试，老是有后来人前辈前辈的请教测试的问题，但我不知道该如何回答这些问题。经常有一些想法不时的冒出，萦绕在我的脑海里。不如记下来，和大家探讨探讨，供大家参考。
什么是测试
以前也会当面试官，好像这个题目没有提出。如果还是有机会面试偏测试的人员的话，这个题目当然是居家旅行，必备良药了。
经典的 《软件测试的艺术》 (已经出到第三版了)曾经这样定义软件的测试：测试是为了发现错误而执行程序的过程。其实这个就是俗称找bug，几乎测试人员大部分时间就是在干这些活。具体一点，就是每个产品都是明确的需求，它会有很严格的功能说明，这个过程就是通过使用软件，来找出那些实际结果和预期结果不同的情况。如果找到了，恭喜您，赶紧报bug吧。
但是我认为，测试人员还有一个非常重要的任务，就是去明确产品里不确定的那些需求。千万不要小看这个任务，我觉得这才是体现一个测试人员核心价值之所在。神马意思？产品的功能不都写在需求文档里面的吗，白字黑字，就差一个公章了，难不成还有漏网之鱼？
对了，还真有，而且找到了，都是大鱼，肥硕肥硕的，够开发吃好几顿呢。我举个最简单的例子，世人皆知 1+1=2这个朴实的真理，不然怎么赚钱呢？但是任何真理只在特定场景中生效。不信？草原东有一群羊，西有一群羊，两群羊合并到一起，还剩几群羊呢？要是东有一群羊，西有一群狼，呃…当然这些个例子不是太合适。还是举一个测试例子，比如有这样一个输入框，需求写着输入数字。这就是一个典型的不确定的需求，这个数字是正整数，负数，有理数，无理数，难不成虚数也可以？
当然这需要测试人员有很深厚的功力，对产品有很深刻的见解，具体怎么做，不是我所能够解释得了的。
测试方法
以前面试，我喜欢问一些教科书的理论知识，比如一些常见的黑盒白盒测试方法，一些家伙对此很不理解，觉得这些玩意有啥用啊，就背书没意义吧。
其实，所有人都知道，测试用例是无限的，而测试资源却是有限的，这有限的资源，如何去执行无限的测试用例呢？这时，这些知识就派上用场了。比如等价类划分吧，既然测试用例是无限的，那就把这些无限的用例划分成有限的集合，这样不是把无限变有限了吗？这时，只需要抽取有限集合的代表元素执行就行了。
还有一些是从实际中来，根据一些统计得出软件在什么情况下最容易出错，而得出的一些方法。比如边界值分析，呵呵，一般测试边界值，一抓一个准啊。
总之，一些测试理论方法还是要学习，并用到具体测试中去。
测试工程师的未来
现在流行啥全栈工程师，就是有很扎实的基础，然后在具体方向上多点开花。不过对于测试工程师的未来，向开发工程师的偏向，应该是一个方向。因为随着技术的发展，很多以前手工的测试，已经可以通过自动化方式进行了。所以测试工程师需要很好的开发基础，也是避免不了的。
当然按全栈工程师的倾向，也许测试工程师也需要运维等能力。个人觉得以后测试项目就是一个开发项目了，需要运维搭建测试环境，开发测试脚本，执行测试脚本，分析测试结果。所以，似乎开发、测试好像也不会分得那么清楚了。
只是谈谈个人的曾经从事过的测试行业经验，希望对一些人有一点点帮助。
