前言
这是一篇写给测试新手的文章。
常有朋友来问：在职业规划方面，功能测试和自动化测试两条路该如何选择？或者什么时候适合转为自动化测试工程师？
在这个问题上，我的一贯看法是：自动化是趋势，但功能测试是根本。
那么功能测试又是什么呢？
研究自动化测试，沉淀下来的是实实在在的技术上的提升，而且这种变化会让我们更加自信、心中更有底气。那么研究功能测试，我们沉淀下来的又是什么呢？
思考这个问题，我觉得可以从另一个问题来入手：软件测试该如何做？
搜索“功能测试”的词条，网上给出的答案是：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
那么，我们再深入思考一下：
用户的的要求我们需要完全满足吗？怎么判断用户的要求是否合理？我们测试人员在这个过程中能做些什么？
软件的设计真的合理吗？我们怎么来判断设计是否有遗漏？
需求真的清晰吗？需求不清晰甚至没有需求的情况下，我们怎么开展工作？
软件产品怎么算测试通过？标准在哪里？
功能测试用例应该从哪些方面来考虑？既然用例来源于需求，那么需求又有哪些获取渠道？
如果没有用例，我们该如何开展测试？
在设计用例方面，怎么既保证用例的覆盖度，又能保证用例执行时的高效性？
有了用例，仅仅执行就够了吗？执行用例时，可以借助哪些工具、方法来提高我们的执行效率和执行质量，最终让我们的工作真正有效？
发现了问题，仅仅督促开发人员修复问题就够了吗？常常遇到的一种情况就每个项目都提了一大堆bug却没有时间修复，最后草草上线。有没有真正有价值的方法可以让我们跳出这个”死循环“?
进入了一个全新的项目，以前的项目经验有哪些可以复用？这点很重要，想清楚这一点，可以让我们进入一家新企业时缩短“适应期”，这也意味着我们在面试时可以有更强的竞争力。
......
上面的多数问题，都是我们做“功能测试”时不得不面对的问题。乍看之下，可能跟“测试技术”不相干，不过以我个人经验来看，我们“功能测试工程师”就是在这一条条问题的锻炼之下提升的，是我们“功能测试工程师”的立身之本。从这个角度来说，功能测试与其说是一种“测试方式”，不如说它是一种“思维方式”。
面试题：
下面以一道面试题来更直观的聊聊功能测试。
这是一道我曾经出过的笔试题：按照你平时使用记事本的经验，找出下图中的bug。
印象里有三四十人做过这道题，测试经验从一年到六七年不等，少的能找出一两个，多的也就五六个，尚无一个人能找出全部的bug。
如果是真实的产品，可能并不会出现在这个情况（因为需求可能明确的多）。所以这又带来一个问题：我希望通过这个面试题来考察什么？
日常观察能力？ 包括这一方面，因为我们做测试时经常需要做“基准测试”，也就是对比市面上一些UI或易用性方面做得更优秀的产品。这需要我们具备一定的观察能力。
bug探索能力？当然也包括这方面。我曾经录用过对用例设计毫无经验，但bug探测方面很有天赋的应聘者，而且他的后期表现很不错。但面试官总是贪心的，仅仅能发现很多bug就意味着这道题回答的不错吗？显然不是。
其实还包括应聘者的“测试思维”，假设一个人写出来的bug虽多，但东一块西一块（比如文件名、快捷键、数字、快捷键、菜单....），而另一个人虽然发现的bug较少，但更有步骤（比如标题图标、文件名后缀、菜单、子菜单、快捷键、快捷键....），那我会觉得后者的做事更条理，做测试有一套自己的方式，相比前者，更容易减少“漏测”。
从面试题反推尝试用例怎么设计
最后我们再来看一下，假设这个是一个产品，我们怎么思考测试点？简单一点，我们只讨论文件操作的需求。
产品名称：记事本
功能需求（文件）：
用户可以新建文件；
用户可以打开一个已经存在的文件；
用户可以保存编辑结果；
用户可以把编辑结果另存为一份新文件；
用户可以打印文本内容，且支持页面格式设置；
用户可以随时推出编辑。
测试新手会想到新建文件、打开文件、另存为文件、关闭文件等等这一些测试点，略有经验的测试人员会考虑到更多，比如：
存储路径的长度是否有影响
存储路径是否支持手写
如果保存时填写的文件名已经被占用，此时如何处理？
存储目标磁盘是否有影响，比如保存到不同磁盘、U盘、网盘；磁盘存储空间不足时如何处理？
是否可以成功保存为各种不同的文件名格式
文本内容的长短对文件的编辑、保存、另存为、打开、打印等功能是否有影响
在各类操作系统上操作
在不同语言环境下操作
快捷键
那么，这个过程中怎么体现我们的“测试思维”呢？或者或测试人员怎么借助“测试思维”来让我们在设计测试用例时表现的更好呢？
在这里，我觉得可以引用《清单革命》一书中的思想。这本书提出如下几个观点：
要相信我们每个人都会犯错，都会遗漏一些重要的环节
要相信我们当今所面对和需要处理的场景复杂度超过了我们的把控能力，需要清单来帮助我们减少记忆错误或判断错误的机率
清单可以是 checklist，task list，guidance，一切有助于降低决策难度和应对复杂场景难度的文字。
清单的目的是将工作不断标准化、量化、规范化。
从事故或失败中分析来获得下次如何应对的清单，并且努力让清单变得清晰，准确，简短，使得别人乐于采纳和实践。
在书中作者提到了一个例子，关于试飞员的故事。
说的是在20世纪50年代，试飞员还是一个非常讲究个人天资和经验的行业，虽然有1/4的试飞员命陨天际，但是因为这个工作的难度太大，胜任者都是人中龙凤，所以无论是从业者的自我感知还是社会对其的认可，都让这个行业闪耀着光辉。但随着飞行清单和模拟器的越来越普及和易操作，这个行业变成了需要严谨和一丝不苟执行操作的行业，试飞员从此不再像摇滚明星那样耀眼。
而医生这个行业也一样，或者说任何一个行业都一样。在早期刚刚出现一个行业的时候，先驱者们靠着过人的天资和勤奋探索出整个领域的知识、方法论和哲学思想，但自从整个世界进入理性科学的工业化时代以后，任何工作都在用科学的手段研究、分析、规范自身，让原本依靠特别的人才能做的事情，变得简单、可重复，变得让能力一般的人也可以胜任。
可能使用清单进行了50次检查有49次都没有发现问题，但发现问题的那1次却可以让你规避重大的损失
使用清单，在操作者没有显著提高专业技能的同时，却提高了绩效。
简单来说，我们可以将我们的经验制作成类似下图的表格：
需要说明的是，在此我想表达的并非是我们可以借助这个框架来让我们的测试点更完善，虽然这也很重要，而是我们当遇到类似或者完全不同的情况下，要有解决这些情况带来的问题的意识！这才是我所更看重的、真正的”测试思维“。
总结：
常有人说”功能测试“很简单，你是否也如此认为呢？做功能测试的难点之一就是，你如何能下结论说一个功能是正确的？工作过程中我们要怎么锻炼我们的”测试思维“来保证我们的工作真正有效？这是一个需要持续研究的能力。真正希望在测试工作上有所造诣的人，是不会认为功能测试很简单的。也许今天的话题，有点偏离“功能测试”这个主题，但只要对测试新手有帮助，偏一偏又有何妨。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
