测试之道--阿里巴巴八年测试专家倾情奉献.docxVIP

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