测试用例或许不是了解产品的最好方式

测试行业长期存在的争论之一是，为什么功能测试用例在某种意义上可能是很有用的，是因为:

　　"Manual scripted test cases are a great way for new testers
to learn the product while they test"

　　“当测试新人着手产品测试时，以往的测试用例是一个非常好了解产品的方式”

　　这种说法貌似很有用:

　　“使用GPS来找路，是了解这个城市的极好途径”

　　其实这并不是真的。

　　主要原因是,尽管你是按照GPS的指令开车的,但你其实并没有积极参与到这一过程当中。

　　因此，到达目的地之后，你就会很难清楚地记得你如何到达那里的,实际上以后也很难自己找到那条路。

　　GPS

　　研究人员在过去一段时间，就开始研究“依靠GPS导航来驾驶，对人的大脑有什么影响?”有趣的是，事实证明,GPS是扰乱我们大脑中本应该天生擅长的东西,即找路、认路的能力。

　　当你用 “美好的旧方式” 开车时，你就被迫亲自参与到整个驾驶的过程中来。这意味着当我们开车时，我们就会记住我们周围的地标,十字路口,周围环境和道路。当我们这么做的时候，我们就创建了一个对道路的认知(心理地图）。

　　诺丁汉大学研究员加里·伯内特,在2005年,让一些志愿者运用模拟驾驶器来做实验,其中让一半的人有四个路线的详细说明,并让另一半只有一个传统的地图。之后要求他们勾勒出他们的路线。结果，有详细说明的人在各个方面都犯了明显的错误。

　　他们甚至没有注意到,他们从不同的角度被引导到了去过的地方。

　　2008年，Toru Ishikawa在东京大学的一项研究生成一个结果,他支持Burnett的观点,并且之后的研究也印证这一点。

　　一个由英国的神经学家Eleanor Maguire在2000年做的非常著名的研究显示, 在伦敦跑过了多年出租车司机，比那些人不是出租车司机的人在海马区(来自百度百科：海马体主要负责记忆和学习，日常生活中的短期记忆)有更多的记忆。

　　大脑是可塑的,我们经常使用的部分将变得越来越大,而我们不使用部分却越来越小。

　　通过指示或自己想办法解决谜题

　　我的朋友Duncan Nisbet（邓肯·尼斯贝特）认为(@DuncNisbet实际运行是一个有趣的实验,在实验里，他观察人们是通过指令还是自己想办法解决问题的。

　　当我们最后一次与DEWT见面的时候，我们同意一起开始做这个项目。我们希望在这个项目里能有一些有趣的事情发生,或者它可能只是我和邓肯聚在一起和闲逛的借口;-)

　　测试

　　所以这个时候，你可能会想，这一切是如何与测试发生联系的?

　　这就是，像我在这篇文章的开头指出的那样，通过运行测试用例不是一个了解产品的好方式。

　　就像我们通过GPS导航开车，我们并没有参与到整个过程中,不需要学习和了解,我们就不会对我们正在测试的产品形成记忆。

　　功能测试用例不是我们了解产品的好途径

提升一个测试人员的价值

　　在他的书“The Lost Art of Finding Our Way”（《寻找失落的艺术方式》）中，约翰·爱德华·胡特谈到了通过GPS导航驾驶对我们社会和我们所失去的能力的影响。

　　他提到的一件事，离开了GPS，我们正在积极转化为物理世界。

　　通过测试用例来测试会有相反的效果,它会把我们从我们的周边环境中分离开来。

　　胡特还说:

　　“You’re losing this chance to have a greater awareness of your environment”

　　“你失去了一个对你周围环境有一个更清晰的了解的机会。”

　　很多我们测试人员都知道的一件事,就是要成为一名优秀的测试人员远远超过了测试产品的技术。换句话说，你不仅仅是测试出什么可行、什么不可行就完事的。

　　一个好的测试人员同样需要在产品如何被使用,潜在的可改善的方法、潜伏危险和风险还有一些死角等等，有着足够的敏锐度。

　　如果我仅通过测试用例来“驾驶”（或理解为 驱动测试），那么你认为我作为一个测试人员应该还有怎样的能力去应对这类风险呢？

　　如果我没“看见”程序的应用，那我又怎么能期待发现到问题的所在，哪些方面可以改善，从而做出报告呢？

　　从错误中学习

　　GPS系统是一把双刃剑，好的方面是可以帮助我们开车时不犯错。

　　如果我们没有犯错，就没有任何反思和学习的空间了。

　　“嗯,我想知道我为什么在这里打住?”

　　测试用例总是指导我们朝着“正确”的路径走。所以几乎没有探索、尝试新事物和学习的机会。

　　而现在探索性测试,与它恰恰相反。作为一个测试人员,我必须参与到产品测试中,运用自己的头脑来把它做好。

　　我正在尝试从新事物中学习,从错误中吸取教训,形成新的测试用例,建立假设,否定他们,从而在思想上构建测试模型。

a81d
　　Landmarks being folders,log-files config-files,环境信息（诸如：操作系统,硬件和路径信息等) ,使得我们只需要通过在终端或GUI的测试。

　　如果我们真正参与进去了，就会在我们测试时形成一个心理地图/模型。

　　扔掉所有以往的功能测试用例

　　知道我在说什么吗?运行以往的功能测试用例将会减少你的大脑相关区域的大小?

　　我绝对没有这么说！:)  没有任何研究成果表明：做复杂的任务列表会如何如何影响大脑,至少我还没有找到任何相关研究。

　　说要扔掉所有的测试用例吗?

　　我也几乎没有这么说:) 虽然我承认我对它有轻微的厌恶。但是在某些情况下,上下文中的一些手工测试步骤会派上一些用场。

　　综合以上，我要说的其实是：简而言之，仅通过测试用例了解产品的一种极好方式，这种说法是不正确的

　　英文原文：http://t.cn/8sJINIt  作者：Kristoffer
Nordström