软件测试思想浅谈

   也许细心的读者注意到了,本公众号改名了,从“张老师的小黑屋”改成了“软件测试经验与教训”。
     去年写过几篇关于测试思想的文章 ,就测试员的思维方式进行了一些探讨。主要目的是为刚入行的测试新手纠正一些错误的“常识”。从反响来看,读者寥寥,远不如探讨诸如“面试”、“工具”等话题那般火热。对此,我能理解,却难以接受。
     常听到一句话“不怕走弯路,就怕走错路”。不过当一个测试员花费三年、五年甚至更多的时间走了弯路的时候,跟走了一条错路又有什么区别?思想指导行动,作为刚入行的测试新手来说,多看一些测试工具、测试技巧固然能快速见效提升实力,但从长期来看,多看一些测试思想却可以让自己少走弯路,少一些遗憾。
     言归正传。其实直到今天,在外行人看来(甚至包括很多项目经理/程序员),我们测试人员找bug,靠的是对系统的无知、靠好奇心、靠良好的思维发散度、靠直觉、靠“消极”的思维方式。。。这就引出了两个问题:到底什么才是测试最重要的品质?优秀的测试员和平庸的测试员区别在哪里?
    我得承认,前面提到的几点外行人对测试的印象,都是有一定道理的,甚至有些是需要我们去培养的品质。但这并非最重要的。
    当初由于公司的安排,从开发转了测试。之后很长一段时间都处于野蛮生长的状态,懵懵懂懂干了两年, 深知一个测试人员在没有好的导师是多么不易。后来有同事问我,为什么选择测试这条路,我给他一个当时我自己都信以为真的理由:做测试找bug很有成就感,有征服感。到今天我明白了,其实我并不喜欢征服,只是喜欢打破产品没有问题的幻觉。我也并不喜欢报告一些坏消息,但是喜欢将客户从虚假信息中解放出来。
 
我的看法
     对于测试员最重要的品质,在之前的文章中有提到,测试员最宝贵的财产是自己受过训练的大脑,也就是思维方式,跟开发相比我们测试员的思维方式确实是不同的。
     同样的,优秀测试和平庸测试之间的差别在于他们如何思考:如何进行测试设计选择,如何解释所观察到的现象,以及如何分析和描述这些现象并且让人信服。。。 下面简单说几点。
 
测试运用的是认识论
     也许看到这个题目,会有人说:这是什么鬼?我没学习过认识论也做得很好,别装X,好好说人话不行吗?——请相信我,认识论是帮助测试员更好测试的一个哲学分支。 
     认识论研究如何认识所了解的东西:研究证据和推理。这是科学实践的基础。研究认识论的目标是了解怎么样才能改进我们的思维,按照测试员的方式思考意味着实践认识论 。遇到以下类似问题的时候需要用到认识论:
  • 怎么知道软件足够好?
  • 如果软件并不是足够好,怎么样才能知道?
  • 怎么知道已经完成了足够好的测试?
另外,直接与软件测试有关的认识论问题包括:
  • 如何收集和评估证据
  • 如何进行有效的推论
  • 如何使用不同逻辑形式
  • 拥有合理的信念意味着什么
  • 形式和非形式推理之间的差别是
  • 非形式推理的常见谬误
  • 自然语言的含义与模糊性
  • 如何做好决策
 
     的确,从来没有研究这些问题的人,也能把测试做得很好(比如只掌握了我之前分享的测试框架)。但是想要做的比很好更好,就得研究这些问题。研究认识论可以帮助测试员设计有效的测试策略。更好的意识到自己工作中的错误,理解自己的测试能够证明什么,不能证明什么,并写出无懈可击的测试报告。
     苏格拉底早在2400年前就提倡并描述了对信念的批判性观察,直到今天哲学家、心理学家都还在继续研究认识论。作为测试人员,很有必要好好利用这份遗产。
 
大胆假设小心求证
     依靠“直觉”做测试是很多测试员(包括资深的)的测试手段,但需要注意的是,“直觉”很有用,但只在开始的时候有用,而不是其他时候。不可把由直觉做出的判断作为测试报告或者质量评估的依据。除非大家都有这种直觉,否则不会相信或者采纳你的建议。直觉适合用作指南,而不能用作合理性证明。当你凭借直觉找到测试方向时,就需要用严谨的测试行为进行验证。 总之,用直觉开始工作时不错的,但用直觉做为工作的结束又是非常糟糕的。
     当然有“这是问题,因为它显然是问题”的想法时,可以换一种方式进行沟通:“这是问题,因为我看到产品的行为与需求1、2和3冲突,而我们的客户很看重这些需求。”
 
所有的测试都是基于模型
      每次培训新人,我都会郑重申明这一点:在设计测试时,头脑中要创建一个产品模型(比如一个想象的图景,一份功能清单或者某个图表,知道有谁是用户,用户关心什么)。不管模型是什么,测试都主要基于产品模型进行,而不是实际产品。如果程序员怎么做你就怎么测,那相当于你默认了程序员做出来的就是对的——这是一种很危险的情况——任何时候我们都要相信,程序员是很有“创造力”的,他们能创造出各种匪夷所思的逻辑!
     有缺点的模型会产生有缺点的测试。学会一种对产品建模的新方法,就像是学会了观察产品的一种新方法。 作为测试员,有责任去研究建模问题。对建模艺术越精通,越能够更好的测试。
 
关于黑盒测试
     黑盒测试意味着软件内部知识在测试中不起重要作用。需要花更多的时间在了解用户,了解他们的期望和需要,了解技术,了解软件运行环境的配置,了解与这个软件进行交互的其他软件,了解软件必须管理的数据,了解开发过程,了解竞品,等等(更多请参考我的测试框架)。我们测试员的工作就是收集信息,而收集上面这些信息的目的是为了更好的进行测试策略的制定。比如说近期软件进行了一次改动,如果说我们只去了解这次改动的内容,而不了解改动的原因(项目背景),那我们怎么能保证这次开发出来东西是用户想要的?永远对项目经理/开发说的“我们已经跟客户做过需求确认”这句话保持质疑。从我个人经验来看,很多“隐式需求”都隐藏在这些问题中。
     记住,所有的活动都试图回答某些问题,任何测试活动中,都要问自己什么样的问题能够推动自己评估测试策略,否则就会更像是一个游客,而不是测试员。
     做黑盒测试并不反对大家去了解软件代码,如果有能力,多去了解软件工作原理。了解产品的方式越多,越能更好的测试。
 
按照惯例,给大家推荐几本书:
《批判性思维的工具:心理学的元思想》
《思考与决策》
《研究的技巧》

你可能感兴趣的:(软件测试思想浅谈)