我从事测试工作将近八年了，从起初的不懂测试，怀疑测试，到相信测试，再到坚定测试，其中经历的辛酸、煎熬无法言表。在从事测试工作的这八年里，有人质疑，也有人追捧，唇枪舌剑，没完没了，貌似测试永远都是个站在舆论风口浪尖的角色。本文乃在下之精血所作，是我对测试的高度概括，旨在帮助大家了解测试，新人可以更好地从事测试工作，老人可以进行测试探讨，交流思想。为了尽量让更多的人理解测试，本文重在述道，少说测试之术，相信看完之后，各位自有论断，功过是非留于各位看官说。
为什么上来就谈这个？测试的模型既是我对测试认知的高度建模，也是帮助大家理解测试，理解我观点的出发点，正所谓 “风，生于地，起于青萍之末”，任何事情都是有本因的，大道至简，理解了核心思想再看观点，就有了论据，这正如修炼武功，根基决定了以后武术达到的高度，否则就如 “无本之木，无源之水”，虽然我言之凿凿，但大家却都不知吾之所云。
佛家修炼有三个境界：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。从我对测试的经历和认知来说非常吻合，起初开始做测试的时候感觉测试工作是无聊的，枯燥的，而且并没有太大技术含量，以为这就是测试。但是随着工作阅历的增加，觉得测试越来越难，面对各种被测系统，我真的无法用一种通用的方法，或者通用工具满足所有的测试需求。于是开始拼命学习各种系统的实现，尝试去了解我的被测系统。我测试过的系统有 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)= 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” 来精确地阐述测试工作的目的。
再来看一下测试的模型图：
如前面所述，测试工作其实就是确定每一个 x 的取值范围，然后选用合适的 x1 到 xn 的组合数据（一组数据其实就是一个测试用例），代入 f，然后将得到的 y1…yn 跟预期的 y1’…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 运行起来，然后预置各种数据，调用你的流程。如果你是自动化测试，这里其实是有两种方式：
如前面所述，测试工作的步骤就是：
我们对上述步骤的产出进行分析，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 公众号
