株洲专业做网站设计的,可以在自己的电脑上做网站吗,深圳恒诚信企业管理有限公司,做程序任务发布的网站摘要#xff1a; 我从事测试工作将近八年了#xff0c;从起初的不懂测试#xff0c;怀疑测试#xff0c;到相信测试#xff0c;再到坚定测试#xff0c;其中经历的辛酸、煎熬无法言表。在从事测试工作的这八年里#xff0c;有人质疑#xff0c;也有人追捧#xff0c;唇…摘要 我从事测试工作将近八年了从起初的不懂测试怀疑测试到相信测试再到坚定测试其中经历的辛酸、煎熬无法言表。在从事测试工作的这八年里有人质疑也有人追捧唇枪舌剑没完没了貌似测试永远都是个站在舆论风口浪尖的角色。
一、 前言 我从事测试工作将近八年了从起初的不懂测试怀疑测试到相信测试再到坚定测试其中经历的辛酸、煎熬无法言表。在从事测试工作的这八年里有人质疑也有人追捧唇枪舌剑没完没了貌似测试永远都是个站在舆论风口浪尖的角色。本文乃在下之精血所作是我对测试的高度概括旨在帮助大家了解测试新人可以更好地从事测试工作老人可以进行测试探讨交流思想。为了尽量让更多的人理解测试本文重在述道少说测试之术相信看完之后各位自有论断功过是非留于各位看官说。
二、 测试的万能模型 为什么上来就谈这个测试的模型既是我对测试认知的高度建模也是帮助大家理解测试理解我观点的出发点正所谓“风生于地起于青萍之末”任何事情都是有本因的大道至简理解了核心思想再看观点就有了论据这正如修炼武功根基决定了以后武术达到的高度否则就如“无本之木无源之水”虽然我言之凿凿但大家却都不知吾之所云。 佛家修炼有三个境界看山是山看水是水看山不是山看水不是水看山还是山看水还是水。从我对测试的经历和认知来说非常吻合起初开始做测试的时候感觉测试工作是无聊的枯燥的而且并没有太大技术含量以为这就是测试。但是随着工作阅历的增加觉得测试越来越难面对各种被测系统我真的无法用一种通用的方法或者通用工具满足所有的测试需求。于是开始拼命学习各种系统的实现尝试去了解我的被测系统。我测试过的系统有java开发的也有C开发的也有其它语言开发的于是我对各种语言都有一定了了解开始研究如何测试他们。随着光阴流逝对测试认识的逐步加深我发现所有的测试理念都是相通的渐渐的我悟出了万能的测试模型y f(x)。对你没看错就是我们所学的函数表达式。x是我们的输入y是f(x)的输出f(x)表示的是被测系统的功能。测试的思路就是选择适当的x代入f(x)得到y跟我的预期结果y’进行对比从而得出被测流程是pass还是fail。用图表示
对于测试人员来说SUTSystem Under Test被测系统是个黑盒测试人员一般不太会关注f(x)的具体实现逻辑只会关注f(x)的功能。比如假设f(x) 2^x程序可以用“x个2相乘”实现也可以用“左移位”的方法实现作为测试人员关注点只在于“有没有正确实现需求”“功能满足后性能如何有没有安全问题”关注点不在“怎么实现”而在“实现的怎么样”上面这也是测试思维跟开发思维的本质区别。是故弄懂业务理解产品需求是测试的前提。
也许有人会问没那么简单吧系统那么复杂仅仅一个y f(x)怎么能全部归纳你这里只有一个请求一个响应系统那是多复杂啊数据库缓存异步消息日志等。这里得强调的是xy表示的绝不仅仅是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调用主要有httphttpsftptelnethsfdubbo等。
六、 测试系统理念的提出 如前面所述测试工作的步骤就是
确定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选接班人一定会让候选人经历不同的部门通过顺境、逆境来多方面测试考察其在不同的环境中的表现最后确定是否让其上位年终绩效打好以后提交上去让大老板审批大老板如何审批还不是通过设定的各个指标的内在关联整体比例等维度来对这份绩效考评表进行测试的。这样的例子举不胜举生活处处皆测试我们都是测试人。 点击查看原文
