一、前言

我从事测试工作将近八年了,从起初的不懂测试,怀疑测试,到相信测试,再到坚定测试,其中经历的辛酸、煎熬无法言表。在从事测试工作的这八年里,有人质疑,也有人追捧,唇枪舌剑,没完没了,貌似测试永远都是个站在舆论风口浪尖的角色。本文乃在下之精血所作,是我对测试的高度概括,旨在帮助大家了解测试,新人可以更好地从事测试工作,老人可以进行测试探讨,交流思想。为了尽量让更多的人理解测试,本文重在述道,少说测试之术,相信看完之后,各位自有论断,功过是非留于各位看官说。

二、 测试的万能模型

为什么上来就谈这个?测试的模型既是我对测试认知的高度建模,也是帮助大家理解测试,理解我观点的出发点,正所谓 “风,生于地,起于青萍之末”,任何事情都是有本因的,大道至简,理解了核心思想再看观点,就有了论据,这正如修炼武功,根基决定了以后武术达到的高度,否则就如 “无本之木,无源之水”,虽然我言之凿凿,但大家却都不知吾之所云。
  

佛家修炼有三个境界:看山是山,看水是水;看山不是山,看水不是水;看山还是山,看水还是水。从我对测试的经历和认知来说非常吻合,起初开始做测试的时候感觉测试工作是无聊的,枯燥的,而且并没有太大技术含量,以为这就是测试。但是随着工作阅历的增加,觉得测试越来越难,面对各种被测系统,我真的无法用一种通用的方法,或者通用工具满足所有的测试需求。于是开始拼命学习各种系统的实现,尝试去了解我的被测系统。我测试过的系统有 java 开发的,也有 C++ 开发的,也有其它语言开发的,于是我对各种语言都有一定了了解,开始研究如何测试他们。随着光阴流逝,对测试认识的逐步加深,我发现所有的测试理念都是相通的,渐渐的,我悟出了万能的测试模型:y= f(x)。对,你没看错,就是我们所学的函数表达式。

image

x 是我们的输入,y 是 f(x) 的输出,f(x) 表示的是被测系统的功能。测试的思路就是:选择适当的 x,代入 f(x),得到 y,跟我的预期结果 y’ 进行对比,从而得出被测流程是 pass 还是 fail。用图表示:

对于测试人员来说 SUT(System Under Test,被测系统)是个黑盒,测试人员一般不太会关注 f(x) 的具体实现逻辑,只会关注 f(x) 的功能。比如,假设 f(x)= 2x,程序可以用 “x 个 2 相乘” 实现,也可以用 “左移位” 的方法实现,作为测试人员关注点只在于 “有没有正确实现需求?”,“功能满足后性能如何?有没有安全问题?”,关注点不在 “怎么实现”,而在 “实现的怎么样” 上面(这也是测试思维跟开发思维的本质区别)。是故,弄懂业务,理解产品需求是测试的前提。

也许有人会问,没那么简单吧,系统那么复杂,仅仅一个 y= f(x),怎么能全部归纳?你这里只有一个请求,一个响应,系统那是多复杂啊,数据库,缓存,异步消息,日志等。这里得强调的是,x,y 表示的绝不仅仅是 request 和 response,而是广义的输入和输出,什么区别?request 和 response 只是输入输出的一种,对于 SUT 来说,只要是读的数据都算输入,比如:用户登陆的功能,当我填入一个用户名进行登录时,我的输入除了在页面上填入的 “用户名” 和 “密码”,DB 中也必须有这条用户记录(当然用户不存在也是一种测试场景),所以 DB 中的这条用户记录也算输入,甚至如果登录系统处理过程中去查询安全系统,安全系统返回的 “用户安全策略” 也算输入。所以,这里的输入是广义的输入,包含了用户页面填入的 “用户名/密码”,DB 中的 “用户记录”,安全返回的 “用户安全策略” 等。同理,输出也是广义的,包括 “DB 的写”,“对其它系统的请求”,“打印的日志”,“对缓存的 put”,“发出的异步消息” 等。于是我们的测试万能公式可以进化成下面的样子:y1,y2,y3,…,yn= f(x1,x2,x3,…,xn)。我们测试工作其实就是确定每一个 x 的取值范围,然后选用合适的 x1 到 xn 的组合数据(一组数据其实就是一个测试用例),代入 f,然后将得到的 y1…yn 跟预期的 y1’…yn’ 进行比较,从而判断被测场景的正确性。用图表示:

 所以,一个合格的测试,必须理清 “SUT 的功能”,“SUT 的所有输入”,“每一个输入的取值范围”,“SUT 的所有输出”,“根据功能推出每一个输出的预期值”。

这里还要强调的一点是,这里的 SUT 是很有讲究的,在我看来除了静态走读代码的方式算是白盒测试外,其它的一切测试都算黑盒,只是这个 “盒子” 的大小不同而已。单元测试中 “盒子” 比较小,就是一个或者若干个方法;接口测试的 “盒子” 就会扩大到应用级别;集成测试的 “盒子” 就会扩大到系统级别。
弄懂了测试的模型,就可以开始剖析测试各个的关键点。

三、测试的目的

测试的目的就是规避 Bug。为什么用 “规避” 而不是 “找”?因为对于所有的测试用例来说,并不是每一条都能测出 Bug,对于没能测出 Bug 的用例执行,你能说测试工作没有价值吗?显然不能,对于测试人员来说,在未执行测试之前,假设的前提是所有的被测流程都处于未知状态,只有执行完对应的测试用例这个流程状态才变得可知——pass 或者 fail,对于 fail 的测试用例我们是找到了 Bug,而对于 pass 的测试用例我们没有也不可能找到 Bug,所以不管 pass 还是 fail,测试执行工作都是有价值的,这里只能用 “规避 Bug” 来精确地阐述测试工作的目的。

四、测试的步骤

再来看一下测试的模型图:

image

如前面所述,测试工作其实就是确定每一个 x 的取值范围,然后选用合适的 x1 到 xn 的组合数据(一组数据其实就是一个测试用例),代入 f,然后将得到的 y1…yn 跟预期的 y1’…yn’ 进行比较,从而判断被测场景的正确性。由此可以总结出,测试工作步骤就是:

五、测试的难点

对于上面四步,第 3 点和第 4 点相对容易,测试的主要难点在于第 1 点和第 2 点:

1. 如何找齐所有的 x 和 y?

想要找齐所有的 x 和 y,就必须要求你对系统非常熟悉,对流程非常熟悉。系统依赖如何?流程调用,系统如何处理、交互?产生哪些反应?典型的输入有:调用请求,读 DB 数据,读缓存数据,被依赖系统的返回数据,收到的异步消息等;典型的输出有:写 DB,写缓存,写日志,调用依赖系统的请求,发出的异步消息等。所以这个需要你对你的被测系统和流程必须非常非常的熟悉。

2. 如何确定合适的 x1 至 xn 的组合?

首先,你要熟悉每个 x 的可能取值,除了正常值,还有异常值,这个对测试工程师的要求非常高。为了清楚所有 x 的可能取值:

其次,当所有的 x 可能取值确定以后,这里就会利用专业的测试用例设计方法,对 x1 至 xn 的组合进行设计。设计方法有:等价类,边界值,因果图,判定表,正交法等等,这些在很多的软件测试书中都有详细的介绍,在此不作细表,有兴趣的可以自行查阅。

3. x1 至 xn 如何传入 SUT?

这个用一个词来精准形容就是 “驱动”,如何驱动你的测试流程?其实这个很体现测试工程师的水平。如果你用的是手工测试,那肯定得搭建测试环境,必须让你的 SUT 运行起来,然后预置各种数据,调用你的流程。如果你是自动化测试,这里其实是有两种方式:

如前面所述,测试工作的步骤就是:

我们对上述步骤的产出进行分析,1、3 两点产出的是 “数据”,2、4 两点产出的是 “逻辑”。第 4 点的逻辑非常固定,就是预期输出结果和实际输出结果的比对逻辑,而第 2 点的 “驱动” 逻辑虽然有代码驱动和协议驱动,而且协议驱动也有很多种,但是因为涉及到的是接口和协议,相对还是比较固定的,不容易发生变化,非常适合将 2、4 做成应用。我们想象一下,如果有一个测试系统,能根据传给它的数据,完成对各种 SUT 的测试,那岂不是测试工程师只要产出数据(测试用例)就行了。思路完全可行,因为测试用例本质上就是一个 “描述,” 一个 “用什么样的数据,调用什么样的流程,预期会产生什么样的结果” 的描述。这种描述可以是汉语,也可以是英文,也可以是 xml 格式,又或者是脚本,只要能描述清楚这种语义即可,只不过我们肯定需要对这种描述制定一些格式规范,保证测试系统能够识别这种描述。这样我们的测试系统就可以集用例管理、测试执行、Bug 提交、测试报告于一身,成为测试中台(不知道这个用词对不对)的完美转身。我大胆画出这种测试系统的架构示意图:

目前我正在这个方面做一些研究,也有一些实质性的产出(驱动模块和用例管理模块),但还待琢磨完善,如果有人有兴趣的也欢迎一起探讨。
      

七、测试人员的核心价值

常常被人问起,测试人员的核心价值是什么?跟 PD、开发比区别是什么?如果没有经过上面的一系列分析,被人炸一问起还真不好回答。可是今天就不一样了,今天我就谈一下自己认识的测试人员的核心价值。这些是每个测试 Leader 必须清楚的东西,否则你如何给你团队的成长指明方向,为你的组员答疑解惑授业?

测试的核心价值就是:对于任何被测系统,能够全面、高效地规避 Bug——发现、定位、解决。注意,这里有四个要素:任何被测系统,全面,高效,Bug

1.  要素一:任何被测系统

  系统的多样性可能会迷惑你的双眼,正如人往往容易在这花花世界中迷失一般,认识不到什么才是真正值得追求的东西,什么才是真财富。有了上面的分析做铺垫,这个就很简单了,其实就是解决 “驱动问题嘛”。总是有人对测试框架的搭建,测试环境的搭建产生畏惧,弄懂了这个原理,你就会变得一往无前,就两种驱动嘛,万变不离其宗,只是根据不同的语言略有差异而已,但是我们都已经看到明灯的方向了还会恐惧吗?

2. 要素二:全面

这个其实就是测试用例的设计问题。这个上面已经分析的很清楚了不在赘述,请参看上面 x1,x2,…,xn 组合数据的设定。

3. 要素三:高效

这个主要体现在三个方面:数据准备服务,自动化测试,测试的维护和传承。

4. 要素四:Bug

什么是 Bug?只要不能满足预期的东西都可以称之为 Bug。所以,Bug 也是广义的 Bug,可以分为功能 Bug,性能 Bug,安全 Bug,甚至流程 Bug。对于一个 Bug,优秀的测试工程师要能够定位 Bug 原因,并给出解决方案。
对于功能性 Bug,没什么好说的,测试工程师的大部分时间都花在了这里。Bug 定位的方法,主要的手段就是看日志,Debug。

对于非功能性 Bug,就有点复杂了,不能一概而论,但还是有方法的。如性能测试中,发现程序卡住了,你会猜测是否出现了线程死锁,对于 java 应用,你需要使用一些 jvm 工具去查看线程堆栈,根据线程状态做出判断。只要掌握了一些非功能性 Bug 的定位方法,定位起来也是有迹可循,最后做到游刃有余的。Bug 的定位和解决考验的不仅是测试人员的技术深度,更是知识的广度,所以这一点也是判断一个测试工程师能力水平的重要方面。
另外,对于一些流程上面的问题,考验的又是测试工程师的沟通、协调能力。因为真的很难,主导权在 PD、开发,作为最后一个环节的测试,有时候真的需要用一些沟通技巧,和修炼出的人格魅力去说服和推进。

八、 测试岗位性质

总结来说,测试属于软件质量把控的最后一环,测试的好坏直接决定了软件质量的好坏。历史上面不乏因为测试不力而造成重大损失的案例:如,程序 bug 导致了天大的损失,要枪毙程序猿吗?同时,测试又是一个支撑型的岗位,虽然它不直接产出代码,但对测试人员的要求不但不低,而且还非常之高,很多业界的测试大牛都是先成为开发大牛以后再转成测试的,逻辑很简单,因为一个人的能力达到很高的水平以后,如何把自己的能力复制给别人就成了一门学问,最简单直接的办法是,去评估别人的代码,指出别人代码、架构的问题。测试是一个入门简单,越做越难,甚至最后对人的要求高到极为苛刻的地步。测试的管理也是非常难做工作,现实中大家负责的都是不同的需求,你很难去评判两个测试工程师之间的优劣,因为测试的深度体现在思想上,也许你可以从测试用例上面去找到一点蛛丝马迹,又或从沟通中去寻找,又或从发现的 Bug 上做参考,又或从线上产生的故障上面去找。

九、说一说测试的现状

测试是个很容易被人误解的一份工作,测试工作本身的复杂性和综合性,决定了测试人员的成长不如单维度作战的开发、PD 快,以至于让很多人对测试岗位产生误解,也就不能责怪时不时兴起的 “我们需不需要专职 QA” 的口水战,以至于很多测试人自己都会开始怀疑。这是由于对测试本质认识不清造成的,测试有点像练内家拳,很难修炼,甚至有人修炼三年都不得其门而入,这就不能责怪中途退场者甚众,坚定信念者寥寥。一句话来说,懂测试的人太少了。现在也有很多部门把测试人员强制转成开发人员,试问真的行吗?我从来不怀疑测试存在的价值,也坚定地认为测试不可能被砍掉。试问那些强制把测试转成开发的,转换后产品质量如何?有多少是顶着开发 title 干着测试的活?当然我没有详细调查过,知道的人可以说说。
 
测试工作的开展需要规范的合作流程,对于管理不严谨的开发流程,测试工作的开展就显得处处掣肘。阿里是个以结果为导向的公司,很多团队对过程都疏于管理:项目延期对绩效无影响;只要线上不出大故障,即使小故障不断对绩效也无影响;发布出故障又怎么样,大不了回滚嘛。在这样的环境里,开发的质量意识也达到了低谷,各种评审省掉,各种评审不叫测试,各种开发完了来找测试验证一下,各种压缩测试时间,甚至我遇到过项目经理的项目计划中竟然没有测试计划,开发完成还死活不肯提测(因为过不了冒烟),再加上鼓吹开发自测,开发完全可以绕过测试,自己随便测测,发布代码上线,出现问题了,再来找测试回归。通过历史经验来看,出现过几次严重的大故障,大部分都是绕过测试,或者开发自测造成的。
 

十、测试与生活

生活又何尝不是如此,试想生活中我们对什么东西是了解的很透彻呢?很多事物对于我们来说都是个 “黑盒”,你无法了解其中的缘由,但是你知道该怎么使用它。你清楚中医的原理吗?我们的老祖宗还不是用它治病治了数千年;人也是一个 “黑盒”,你如何得知你身边都是什么样的人?还不是通过日常中很多事情来测试,了解他,让你交到知心朋友,让你能够知人善用,带好团队;CEO 选接班人,一定会让候选人经历不同的部门,通过顺境、逆境来多方面测试,考察其在不同的环境中的表现,最后确定是否让其上位;年终绩效打好以后提交上去让大老板审批,大老板如何审批?还不是通过设定的各个指标的内在关联,整体比例等维度来对这份绩效考评表进行测试的。这样的例子举不胜举,生活处处皆测试,我们都是测试人。      

我爱测试,测试教会了我很多,教会了我业务,教会了我技术,更重要的是教会了我全局的结构化思维能力,和对事物本因的思考方式,教会了我如何做好管理,教会了我如何做人。

看我辛辛苦苦写了这么多,最后的最后,容我打个小广告吧,欢迎跟我志同道合的,或有相同感触的,或喜欢练太极的,或喜欢悟道的找我,我们来(转)往(岗)吧!

ps:本文转自阿里巴巴技术专家雷藏博客。 如有兴趣加入他的团队,可直接发简历至 leizang.cs@taobao.com 勾搭!或者底部留言,小编可内推哦。

阿里云测移动质量中心(以下简称 MQC)是为广大企业客户和移动开发者提供真机测试服务的云平台,拥有大量热门机型,提供 7x24 全天候服务。
我们致力于提供专业、稳定、全面、高价值的自动化测试能力,以及简单易用的使用流程、贴心的技术服务,并且帮助客户以最低的成本、最高的效率发现 APP 中的各类隐患(APP 崩溃、各类兼容性问题、功能性问题、性能问题等),减少用户流失,提高 APP 质量和市场竞争力。

联系我们:
 网站地址:https://mqc.aliyun.com
 开发者交流旺旺群:335334143
 开发者交流 QQ 群:492028798
 客服邮箱:mqc_group@service.alibaba.com;
更多精彩技术分享 欢迎关注 MQC 公众号
17


↙↙↙阅读原文可查看相关链接,并与作者交流