一、前言

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

二、 测试的万能模型

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

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

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

对于测试人员来说 SUT（System Under Test，被测系统）是个黑盒，测试人员一般不太会关注 f(x) 的具体实现逻辑，只会关注 f(x) 的功能。比如，假设 f(x)= 2^{x，程序可以用 “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” 来精确地阐述测试工作的目的。

四、测试的步骤

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

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

• “确定 x1 至 xn 的组合数据”
• “将每组数据传入 SUT”
• “根据需求确定每组输入数据输入后产生的预期输出结果 y1’ 至 yn’”
• “将预期结果和实际结果 y1,y2,…,yn 进行比对，从而得出结论”

五、测试的难点

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

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

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

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

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

• 不仅需要，你对业务、业务数据非常非常的熟悉。注意，这里我把 “业务” 和 “业务数据” 分开，指的是两个不同的东西。“业务” 指的是产品提供的功能，比如：登录可以用账密登录，也可以用手机扫码登录。“业务数据” 指的是产品在线上日以继夜的运行后产生的数据，如，注册功能，有通过淘宝注册的淘宝用户，也有通过支付宝注册的支付宝用户，甚至还有数据打通从其它地方同步过来的其它用户数据，你要对这些个业务数据非常熟悉。

• 还需要，你要对系统间依赖的接口非常熟悉。这个主要是为了弄清楚你的 SUT 对依赖系统的调用，哪些调用请求的传参是合法的？哪些是不合法的？依赖方会传回给你哪些可能的数据或者响应，最好有规范的接口文档（可惜现在奇缺）。

• 还需要，你对其它的输入方式的数据类型有比较深刻的认识。针对我负责的系统，主要是前面两个方面，当然根据不同的系统情况也有所不同，这个得具体问题具体分析。

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

3. x1 至 xn 如何传入 SUT？

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

• 部署被测系统，模拟客户端发送请求驱动；
• 直接依赖被测系统代码，用本地代码调用的方式驱动。 总体来说，“驱动” 的方式就是两种，跟语言无关，各种语言通用：
• 代码驱动。这个没什么好说的，就是把你 SUT 的代码直接依赖过来，通过代码直接调用的方式进行驱动。
• 协议驱动。这个也包含广义上的一些 RPC 调用，主要有 http，https，ftp，telnet，hsf，dubbo 等。   ### 六、测试系统理念的提出
  

如前面所述，测试工作的步骤就是：

• 确定 x1 至 xn 的组合数据
• 将每组数据传入 SUT
• 根据需求确定每组输入数据输入后产生的预期输出结果 y1’ 至 yn’
• 将预期结果和实际结果 y1,y2,…,yn 进行比对，从而得出结论
  

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

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

七、测试人员的核心价值

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

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

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

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

2. 要素二：全面

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

3. 要素三：高效

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

• 目前做的最多的也是最成熟的就是数据准备服务，基本上每个产品线都有自己的数据准备工具，如，数据工厂，TAP 等。

• 自动化测试也是提升测试效率的主要手段，但是手工测试是不可完全被取代的。自动化测试有其适用场景：手工无法测试；功能稳定不容易变动；频繁回归。即使不可全部自动化，也要想办法进行半自动化，半自动不行就 1/4 自动化。总之，条件允许我们要自动化，条件不允许我们创造条件也要自动化，将一切可以让电脑干的事情坚决不能让人来干，所以，自动化的程度也体现了一个测试工程师的能力水平。

• 测试的维护和传承，这个是最容易造成劳动力浪费的地方。“宁可全部重写也不愿改别人代码” 是工程师的通病，对于开发工程师来说这个问题还好一点，毕竟你不能单独开一个应用，还得在原来的应用中去改，但是对于测试工程师来说，这个问题暴露的尤为严重。测试脚本的独立性决定了每个人写出的自动化脚本风格都不一样，一旦换人，后来的人是能自己写的就坚决不维护别人写的脚本。对于自己写的代码还能做到一些复用和扩展，但也很难让别人来复用你的代码，再换人了继续恶性循环。究根结底，测试脚本没有统一的规划，不仅没有统一风格，也没有统一架构，确实需要也很必要制定一些脚本编码规范，规划一下测试脚本的架构，让测试脚本做到可维护，可复用，可扩展，并沉淀一些测试的服务供测试使用。另一方面，刚毕业的人在写脚本，工作干了五六年的也在写脚本，不信你去看，这两者写出来的脚本还是有很大差距的。刚写脚本的人会把所有的逻辑放在一个 testcase 里，而一个老手就有了一定的架构意识，该抽象的抽象，该封装的封装。所以，对测试脚本的统一规划，也为测试新人提供了成长的方向，有利于测试新人的迅速成长。另一个思路就是用上面说的 “测试系统” 来解决这个问题，大家只要按照固定的规范编写用例，测试执行的事情交给系统去做，这个应该是最完美地解决传承问题的解决方案，但前提是 “测试系统” 需要足够的稳定、强大。

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 公众号