转载：测试之美--测试人员的心思你不懂

原文地址：http://www.cnblogs.com/fnng/archive/2013/01/23/2872378.html

By：虫师

希望阅读本文的朋友是做过测试并有一定经验的，不然，你明白我说的什么意思，但你对本文并不一定深有体会。

 

测试人员的定位

 

　　这其实是个有趣味且值的问题，包括经常跟测试人员打交道的开发人员，甚至测试人员自己都没弄清楚自己职位到底该如何的定位。当别人问人什么是软件测试时？ 噢！等等，我翻翻书，“软件测试是通过一定的测试方法和工具发现软件的中的缺陷从而来提高软件质量。”

　　噢？测试发现软件中的所有缺陷么？不能！

　　噢？测试真的可以提高软件质量么？这个还真不敢保证。

　　询问者轻蔑的的走开了，处于礼貌，他们可能没有笑出声来，但他们的眼神已经告诉了测试人员答案，测试是个可有可无的工作。留下测试员非常的窝火，但貌似真的找不出非常有力的证据，来证明自己的存在“不可或缺”和“不可代替”的价值。

 ----------------------------------------------------

　　软件测试人员接受专门的培训来发现并报告问题，他们通过发现和报告软件的异常问题和存在的风险，进而帮助公司、开发团队、客户和最终用户。

　　那么我们可以把测试人员比作警察吗？在软件开发过程中并没铁定的“宪法”，他们并不能依照“法律”是去“逮捕”任何人，尽管软件开发的世界里完全可以制定出一定的法律。在法律的世界里，一方受到惩罚，一定有另一方面受到的伤害。但软件缺陷不是这样，也许这个缺陷会造成巨大的伤害，也许一定伤害也没有。也许我们的“法律”根本无法评估一个的伤害到底有多大。

　　好吧！既然不能做警察，那来做法管好了，让测试人员来做“质量把关人”。这其实操作起来很困难，也不太公平。所谓“质量把关人”，就是在软件发布前将该软件看做一个商品。由测试人员来权衡风险、必要性、市场需求和成本开销。噢！测试人员的高度不够，评估和承担风险其实是项目管理者或公司管理层的任务。

　　到后面可能测试人员已经抛弃了测试人员的本质工作（发现并提交问题），而是花费大量的时间在权衡和评估每一个问题。其实，测试人员清楚地知道不客发现和解决多少问题。软件代码里总是还潜伏着一些问题，所以，他们一般不太情愿盖那个质检合格的红印。这就是说等“质量把关人”去确定产品合格，可能要猴年马月了。

　　测试人员其实更愿意做侦查取证小组或验尸法医。他们只提取证据。接下来的你们看着办吧。

　　好吧！软件测试人员的工作远不至这个，以下任何要求都可能决定测试人员的使命，你（测试人员）期望的是哪种要求？

• 快速找出重要的软件问题
• 对产品质量提出总体评估
• 确认产品达到某种具体标准
• 帮助客户改进产品质量和可测试性
• 保证测试过程能够达到可分清责任的标准
• 帮助预测和控制支持成本
• 帮助开发人员完成测试工作
• 参与需求并从测试的角度提高软件的可测性
• 为满足特定客户要求，完成所有必要的工作

　　对于测试人员来说这太啰嗦（复杂）了，他们只是单纯的喜欢找缺陷（bug），并像探秘一样的把缺陷定位出来。这就像好玩的寻宝游戏。没人事先知道答案，这样对测试人员来说才是有趣的挑战。

 

测试人员有趣的特质

 

　　好吧！为了完成这项有趣的挑战，测试人员应该具备什么样的特质呢？

　　首先要有好奇心，想弄清楚事物是怎么运行的；其次喜欢动手试验，想知道尝试使用功能演示时不同的用户场景和试验会发生什么。

　　再次，需要一点胆大精神，不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉。

　　善于分析，善于学习，事实上，测试人员一直在学习，他们的工作性质要求如此。技术总是在变化，接到的每个项目或多或少跟上一个项目不一样。有时候有很好的文档，有时候却没有，必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论。

　　当然，测试人员也有不好的特质，尤其对于那些经验丰富的人为说，不容易信任人，这是从实践中历练出来的，别人总是告诉他们模块X不需要测试，或代码Y“没动过”，这种信息错的数多到数不清了。所以，就算你告诉测试人员草是绿的他们也要亲自过目才敢相信。当然了，不是所有的测试人员都具备这些特质。好吧！也许你做测试是为了一份稳定的工作来生活。也许你不是“真正的”测试员。

 

寻找测试的乐趣

 

　　只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。当一个测试人员运行一大堆已有的测试用例时，容易心生厌烦。可能会快运行这些测试，只是想让他们从眼前消失，这意味者他们可能不会非常关注执行的测试，当然也就不能像认真彻底的执行者一样找出某些问题。

　　很多测试人员觉得单调乏味而不屑运行回归测试，虽然大部分测试员都理解甚至同意回归测试的必要性。

　　一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。如果原来的分析实在很棒，寻阿能他们也找不出来太多可有更新充实的内容，进而增加了无聊指数。

 

 

 并非发现的所有问题都可以得到解决

  　　

　　虽然，看到这个结果会打击测试人员的积极性，但这是真的。最有经验的的测试人员会同情地拍拍你的肩膀说：地球人都知道事情不仅仅是发现问题那么简单。他们也会充分理解、会力支持你的决定：问题A、B、C 可以不解决，并不会有人对这样的决定怪罪你。拥有多年工作经验的测试人员会说出大家都愉悦的意见，因为他们从这家公司的项目经验中学乖了，知道这样会给他们（以及他们部门）带来最好的质量结果。但是需要记住，他们之所以肯牺牲问题A、B、C ，很可能是为了说服你解决更严重的问题D 和E 。当然，大多数测试员是希望发现的所有问题都能够得到处理，现实总没希望的那么好。

 

测试员只喜欢有趣的缺陷

 

　　所有的测试人员都会告诉你，缺陷是存在的，然后缺陷就真的存在了。一般来说，让事情变得好玩并非缺陷的数目。比如一个测试人员可以在大的网站应用程序中发现上千个表面错误，就是语句与错别字，给用户看的文本有语法错误，图标上的颜色不对，或都屏幕上有东西位置放得不对。

　　测试人员非常讨厌这样的错误，特别是发现有很多的时候。因为记录这类错误比发现它们所花费的时间更长。而且他们一般属于低优先级，很容易得到解决。对！测试人员就是变态的喜欢让开发员束手无策的问题，这样似乎更能体验他们的能力与价值。

 

不要去预测问题优先级

 

　　在IT领域经验丰富的前辈会告诉你，某个应用程序的最终用户可能会对你觉得微不足道的问题深切关注。这跟人的“烦恼因素”有很大关系，一个错别字或字体用得不恰当可能不会影响用户的使用，项目组的所有人都认为这是个小问题。但是对于每天要看两千遍的用户来说，“烦恼因素”是非常高的。

　　例一个双击鼠标就可以完成的操作，我设计成了三击，只是多点了一个鼠标而已。这也许有趣，但对于每天操作几百遍的用户来说，他会破口大骂地拿起鼠标甩到地上。这太令人讨厌了。这影响的他们的工作效率，也行效率与绩效、奖金挂钩。

　　测试人员报告他们发现的一切问题，其中经验丰富的人员会根据其理解来报告严重程度，但一般来说不要试图预测业务优先级。他们理解中的业务优先级通常就像开发团理解的一样，是不太完整的，并不是基于用户的个人体验做出的。经常有用户愿意“将就”使用有严重错误的代码，却在最后一刻强迫要求修改或添加看起来并不重要的东西。

测试人员的工作是寻找、发现、报告，而不是用神一样的能力去评判，测试人员应该随心所欲的提供他们的专业意见，事实上，项目组的所有人都应该随心所欲地提供专业意见。

 

 

报告你发现的所有问题

 

　　有一个令人遗憾的现实，那就是测试人员不将他们发现的所有错误报告出来。原因可能有很多，但最常见的是他们觉得报告某一种或某一类错误没有意义，因为反正都不会被解决的。这是从实践中“学”来的，你通常会发现有这类态度的测试人员不抱幻想、厌倦、愤世嫉俗、对工作不感兴趣。他们报告缺陷的兴趣和热情已经被工作环境慢慢消磨掉了。另一个原因也许是他们相信从政治上和实际上来说，报告他们发现的一切东西是不“聪明”的，他们应该只报告那些公司在乎的东西。那么，如果公司看不到整个大局，怎么知道在不在乎呢？每个人都明白很多错误是不能（或者从财务的角度来说不应该）在产品发布前解决的。成功项目管理的“艺术和工艺”的一个要素是对推迟和解决哪些缺陷做出正确的决策。比如，项目组决定解决1 4 个缺陷，推迟另外3 2 个。但是测试人员选择不报告3 2 4 个缺陷，因为开发团队“从不解决”字段错误，这意味着项目经理和上层的管理者正在根据错误、不全面的信息作决策。在这个例子里，用户界面就不能在万众瞩目的黄金时段隆重登场。

　　另外，就算是在一个并不解决某类错误的公司，报告每个错误也可能会最终改变公司的政策（或称之为“一直实行的陈规”）。如果一个测试人员报告了4 0 个错误，一个都没解决，应用程序就发布了，然后用户以紧急的优先级报告同样的错误并要求尽快地解决它们，那么开发团队和项目经理以后就会开始注意这类缺陷

 

 

测试员一直在想法破坏你的程序

 

　　好的测试人员同时是富有创造力和想象力的。测试通常是一个破坏的过程，正因为如此，在正式产品环境下运行测试需要非常谨慎的决策。好的测试人员不必试图证明软件运行正常，他们是来证明软件不能正常运行的。这一态度差异是测试人员能发现如此多缺陷的主要原因，他们就是想发现缺陷。他们分析手上所有的信息，坐下来思考怎么才能破坏应用程序。项目组里没有其他人有这样的使命。开发人员一般甚至没有足够的时间持续写代码，更不要说试图挤出足够的时间来想怎么破坏代码了。最终用户通常只是执行日常工作的操作，如果有东西“坏掉了”，他们可能陷入恐慌和沮丧之中。另一方面，只有测试人员勇敢地参与进来，使出吃奶的劲儿去发现软件中的缺陷，他们却为发现另开发人员痛苦的缺陷而兴奋不已。

　　这正好应验了妈妈一直告诉我们的话，要是你只盯人身上坏的一面，那你就只能发现坏的东西。测试人员全面地盯着系统中出错的一面找问题，顺便也就检验了运行正常的部分。但他们关注的焦点总是向着错的东西，而不是对的东西

 

 

测试角色的本质

 

　　很久之前，就有关于测试人员的角色的争论，我们再来总结性的说说测试角色的本质。

　　一些人认为测试人员的角色是保证质量，如果有人能决定到底“质量”指什么？ 这个似乎很难说清。

　　另一些人认为他们的角色是通过训练开发人员的寻找缺陷帮助他们编写出更好的代码----在开始编写的时候就不存在错误的编码；

　　还有一些测试专家集中精研究为何以及如何找到缺陷：在不同的环境下寻找缺陷所涉及的策略、技术和术语。

　　所有这些说法都很有趣，在某种意义上都是对业界有溢的。但是，从本质上来说，测试的意义就是发现缺陷。测试人员通过项目组和管理层展示缺陷、问题或瑕疵“保证质量”，进而帮助他们做出更好的决策；他们通过向开发人员展示其代码中的错误，使其知错就改引以为戒，进而帮助他们改进工作；他们学习新的策略和技术以便发现更多的（或者更重要的）缺陷，他们把工作归类到新的策略里，如游历式，进而帮助 其他人发现缺陷。如果在测试过程中没有发现（或者只发现了很少的）错误，那么这也是重要的信息。

------------------------------------------------------------------------------

注：本文内容取自《测试之美》第1章 “这对你有好处么”，这是一本很好的书，读完第1章收获颇多，但正如不少人说话，作者写得太散了，没有条理。好吧！我把这一部分的精彩抽取出来与各位分享。