当前位置:首页 > IBM > 正文

IBM姚炳雄:IBM全面质量管理能力矩阵

2013-11-04 ZDNET至顶网 编辑:王聪彬

  IBM软件部Rational资深技术顾问姚炳雄在中国金融行业IT解决方案研讨峰会上指出,测试正在从单一的测试向全面质量测试方向变化,需要建立体系化。

  据悉,IBM的全面质量管理能力矩阵,矩阵从测试方法学与流程、测试资产管理、质量管理和自动化测试、协作式测试管理、质量的度量一层一层来构建全面的质量管理体系。

IBM姚炳雄:IBM的全面质量管理能力矩阵

IBM软件部Rational资深技术顾问 姚炳雄

  以下为演讲实录:

  我来自于IBM Rational,现在是北方这边的经营负责人。刚才听了两位大师演讲,给我的压力也很大。我这边主要是想从技术这个层面上,因为前面的主任也好,专家也好,看的都比较长远,从业务层面上,从金融管控,从非常宏观的层面上来谈了这个测试相关的问题。接下来我从软件工程这个角度,更细的来去聊一聊IBM Rational怎么来看待测试,怎么来看待我们整个在金融行业内的质量管理。

  首先我这个演讲因为时间比较短,我们要讲的内容非常多,我就非常简单的把我们这些想说的尽可能的用最简洁的挑重点的告诉大家,我首先谈谈软件工程一些新的发展趋势,以及我们因为软件工程它的一些变化导致了对于质量工程,对于测试一些新的挑战和变化。这个我们要谈一谈现在一些大的趋势,在这些变化底下,我们用什么方式去应对?因为测试越来越作为一个专业的领域,越做越专,在这种情况下,我们需要更体系化,更系统化的去看这个问题。

  我们说软件工程,从现在软件工程发展趋势来看,首先一个比较大的转型或者一个比较大的趋势,就是逐渐往敏捷方面去走。我们知道敏捷它有很宽泛的含义,首先我们说IT是来支持我们业务的,业务的敏捷性现在是越来越突出。我们说金融服务不断的推陈出新,也是因为面临着外包业务竞争性的一些压力,所以导致我们快速的在推出新的业务,更高效的提升我们服务能力。这种业务敏捷性直接导致了或者强迫我们IT必须要能去支撑它,导致了IT的敏捷性提到了空前的高度。IT敏捷,但是我们又要保证质量,要防范风险,这时候就会给我们带来更多的挑战。第二就是从软件工程角度来看,软件工程最初是从瀑布式的发展方式,逐步进入到一个迭代化的开发方式里面。现在的软件工程可能更多的口号喊的就是敏捷,敏捷这里面有更多的比如像测试驱动的开发、整个测试需求的关联,包括敏捷的项目管理等等各个领域,它都会有这样一些新的实践出来。

  另外一块,现在的业务系统越做越复杂,在这种大的复杂的IT环境下,快速的去交付一个软件服务的话,资产的重用也逐渐的被很多大的金融企业,大的软件开发商纳入到自己的视野里面来。资产之所以可以重用,是因为现在我们的软件更多的往组件化、服务化这个方向去发展,导致我们重用的成本以及重用带来的回报都非常的可观,所以这也是业界一个很大的趋势。

  在金融领域,我作为IBM Rational这边的工程师,五六年以来一直在服务于银行金融领域,我也看到在现在各个金融领域都开始做这种企业级的治理,尤其是像我们最近几年有些大的银行在做核心系统的改造。核心系统改造其实它的出发点都是从企业治理、企业架构开始树立起来的,从原来我需要一个什么样的能力,我迅速的开发一个应用,开发一个系统,到现在我要停下来,我要全面的去看一下我企业究竟需要什么,我要把我的业务架构、应用架构重新梳理一遍,这个其实是一个非常大的改变。是因为我们的系统,我们的应用已经足够多,足够复杂,我们已经走到今天,需要去做企业架构的梳理了,这也是一个比较大的趋势。

  另外我想说的就是DevOPs理念,是开发运营一体化,更加敏捷的去支持我们的业务,所以把开发运营形成一个完整的无缝衔接,更多的更快速的去把我们IT服务交付出去。这个其实是一个非常大的趋势和理念,而且我非常高兴的看到,现在有一些非常大的金融企业已经做到了这一点。

  我们说软件工程它是一个大的体系化的系统化的工程,测试是软件工程里面非常重要的一个环节。软件工程它的变化必然给测试,给我们的质量带来一些新的趋势和变化。我们现在看到的第一点就是我们原来的自动化的功能测试已经逐渐被全面的自动化所替代,因为这个快速的迭代,因为这个IT的敏捷性,已经导致了我们纯手工人工非自动化的方式已经没有办法适应这个节奏。之前我们通常做自动化测试的时候,自动化测试是在功能测试这一块,这一块逐渐的延伸出来所有的整个测试的生态,包括测试环境的转变,测试脚本的录制,整个测试的生态全是逐渐往自动化这个方向去走,这是一个比较大的转变。第二个就是传统的测试它有白盒测试,有黑盒测试,我们在开发阶段做的性能优化以及我们检测所有这些手段,都需要我们原代码来做白盒测试。后面我们做压力测试,做自动化功能测试的时候就是黑盒,现在逐渐的我们出现一个很重要的测试领域,就是灰盒的测试,灰盒测试是什么概念呢?我没有原代码,但是我有接口。这个时候的测试,我是一个半白盒半黑盒,所以我们叫灰盒测试,这块涨得非常快。另外一个大的趋势,我们说IT中心通常来说,说是成本中心或者是只花钱的部门等等,怎么去控制这个成本?随着IT的发展,IT有新的定位,IT要去引领,要去创新,但IT本身也是一个成本中心,怎么去控制成本?我们要把一个bar越早的发现,我们修复它的成本是指数级的降低,越到后面成本越大,所以尽早的去测试,测试前移,这个也是一个新的趋势。怎么样才能把测试前移?需要有一些相关的技术手段和一些规范,一些技术基础性的平台来支持,这也是一个趋势。

  我们回到第一条,我们说其实最大的一个变化是单一的测试往全面质量测试,全面质量管理这个方向去努力。刚才前面两位专家都讲到了,测试越来越专,它需要一个体系化的东西。我们说测试不等于质量,质量它是一个全流程的全工艺过程的,从你开始做需求的时候,就有质量相关的问题。分析设计开发所有这一系列过程中间都有质量保障,都有质量相关的工作需要去做。所以我们说质量管理现在提的更多,从单一的用测试来质量保障,走向了通过各种各样的手段做全面的质量保障。我今天确实深有感触,大家说的已经把我接下来要讲的都说了,我们一直认为全面的质量管理其实是三分靠技术,七分靠管理。它需要你的管理流程、管理平台结合着专业技术平台和技术手段,去共同来保障它。怎么样阐述这个理念?举例来说,我们测试和需求之间有没有关系?关系非常大,需求首先拿到了之后,第一要测试人员的参与,如果测试不了解需求的话,他找不到重点,他没办法测的很专业,很高效。测试所有的脚本,测试的计划以及测试项目整个管理,它都是整个测试中心的资产,这个资产需要重用。测试和整个过程来看的话,测试一定是有流程的,测试的管理流程、测试的任务分派以及测试整个运作,它都有一些最佳实践在里面。所有这些东西和开发和整个软件工程的每一个环节都有关系,所以我们说测试它不仅仅是测试了,我们更宽泛的看到,它应该是一个全面的质量管理。

  对于全面质量管理,刚才我非常欣慰的看到,刚才文思这位老专家给我们展示要体系化。但凡你做测试做质量方面的,它需要有一些能力,也是需要具备的。我们来看比如下面是测试的方法与流程,测试越来越成为一个很专业的领域,在每一个技术领域会有一些很专的理论和实践。整个测试需要有流程提前规划,上面有测试资产的积累,资产的积累是最大限度的去重用,去节省成本,去积累经验。专业技术必不可少,专业技术我简单把它分成几大块,白盒、黑盒、灰盒子,白盒测试,比如我们通常去做的检测,分析等等都是非常有效的,像一些灰盒测试,是后面我们专门来强调来讲的。像黑盒测试,基于界面的自动化功能回归、性能测试等等,在这些专业的技术平台上面,专业的技术测试手段上面,我们必须要有一个管理的平台和流程,帮助我们把整个测试连起来,帮助我们有规律,有组织的去实施这个测试工作。这个工作首先是要管测试自身,测试自身有什么管理?测试计划、测试脚本整个版本化,以及测试环境、测试数据等等这些,我们都需要做管理。还有一块我要和需求去关联,我的测试用力,我测哪个需求点,测哪个需求变更,要跟前面去关联,和后面去关联。我这批测试是针对于哪一个基线,直接关联到你的代码版本,这个必须要前后协作。我们要给他一个协作式的测试管理,我们说如果要做一件事情,我们要把它做的很专业,要做的像专家一样的,我们必须有像专家一样的手段,在上面就是我们做的测试度量,度量我团队的测试绩效、测试结果分析以及各种测试进度等等,这个是我们必须要具备的。这是IBM Rational整体全面的质量管理体系,在这里面它把需要具备的一些能力给它标识出来了。

  传统的测试技术、测试管理,我们听的也比较多了,我今天就想针对我们这种新的测试趋势,新的软件工程带来的一些变化,我专门想去讲讲我们的灰盒测试究竟怎么回事,我会讲一些最佳实践。我们首先来看现在的IT系统非常典型的,第一大家都在往SOA这个方向去转,对于一个IT系统整个体系结构、体系架构来讲的话,现在SOA已经变成了非常流行的但凡比较大规模的系统,基本上都是SOA这种框架,这是一个比较大的特征。第二个比较大的特征就是组件化和模块化,这个也非常流行,我们做一个东西出来,希望它低耦合,这样的话,可以更容易去规划,更容易去做整个企业架构的梳理,更容易去管控和度量。这是另外一个趋势,也是一个比较典型的特征。第三块就是复杂化,我们现在没有哪个系统是一个竖井一样的,独立自己在那儿跑的,现在已经进入一个互联互通的时代,任何一个系统,任何一个业务都需要跨系统,跨很多的企业去交互,协作,才能共同完成一个业务。这是当前非常典型的IT系统的一个特征,在这个特征下,我们来看一个实际例子,这是我们IBM所有员工都在用的一个系统,这个系统是干什么呢?作为技术人员来讲我出差非常频繁的,我拎包就走的,没有计划怎么怎么着。我们有一个系统是专门帮我们服务相应出差的这些东西的,就是订机票、订酒店等等这些,这个系统大家看起来非常简洁,非常简单,就是一个web页面,但是这个系统的背后,首先上去我直接查机票,所有航空公司的机票全部可以查到,并且是IBM特定的折扣价。我直接在上面提交一个要求,大概四五分钟,无论是周六周日也好还是工作时间也好,我的机票就可以出来。然后我就直接去机场直接就飞走了。第二个就是订酒店,酒店系统里有IBM所有的协议酒店,协议酒店你直接上去选哪个酒店,直接确认,提交。在酒店系统里我们可以看到一个简单的页面和机票系统去连接,和酒店系统去连接,和银行系统去连接,直接提交以后,一会儿我的手机上就收到一个短信,说你的信用卡划了多少钱。我们来看一下,这个简单的系统它的背后有这么复杂的关联关系,这个其实是一个非常典型的,我们现在做的金融系统,任何一个系统可能都比我这个还要复杂,牵扯到第三方的东西还要多。

  做这个系统的时候我们怎么测试?面临什么挑战?通常传统来讲,我把所有东西都做完了,然后测试,你发现很多bar,这个bar怎么减?首先8月11号我去成都,从成都飞北京,我订机票,上面一查不是IBM协议价,是公共价,可能我的查询结果跟银行那个系统去对接的时候,我没有订大客户值段,我在这个点上发生这个问题的话,我还要去跟他去协商,跟他重新连这个接口。底下还有,酒店和机票不能分开提交,比如我就想只定机票,酒店我的地址待定,这个是不是可以分离,不要捆绑在一块等等这些问题,我要在这个复杂的系统里面,我要做测试的时候,我要去验证它的时候,我能不能尽早的去测,然后更早的去做这个测试。我们说传统来讲,基于界面的这种测试方式来做这个界面回归,其实是有很大的一个困惑,界面通常改动的频率会比较大。但是我们换一个思路来讲,界面背后底层的接口其实它是变化很小的,我们有没有可能首先基于这个接口来做这个测试。Rational有一个解决方案,可以首先去测你的接口,然后把界面这部分内容先抛出来,这个接口可以通过录制的方式,可视化,也可以是直接你自己去根据接口来配。

  第二点也是我们通常在测试过程中间遇到的,我想早一点开始测,但是环境不具备。环境不具备有很多,我想做测试的人都知道,首先我要等机器,等完机器以后我要安装测试,所有外围的这些东西可能会给我们浪费五分之一、四分之一甚至更多的时间。我们的时间越来越被压缩,因为这些东西都需要你去协调。我们想更早的开始测试,环境不具备怎么办?在这里面IBM有一个DevOps解决方案,自动化的测试环境,测完了以后,我要把测试的结果收集回来,形成一个测试报告,最后分析整个测试结果。这里面DevOps可以帮助我们做哪方面事情呢?比如恢复数据,搭建环境,以及在多套不同的环境里面,自动化的把整个测试的数据,测试的环境恢复起来。我们的自动化已经逐渐从一个功能层面的自动化走向了全面的自动化,全面的自动化有一个前提,所有的工作都是通过脚本化,所有的脚本都要版本控制化,所有的这些版本化的脚本都被自动的调度,这样就有了一个非常高效的环境搭建以及这样一个准备工作。

  有的环境不受你控制,但是你还必须要测,这个是什么呢?就是我们通过服务虚拟化的技术来解决。这个我稍微多讲一点,比如我刚才讲到的,我要和航空公司去做这个接口对接,我是不是要航空公司把他那个东西开放了,我才能测试,我想尽早测试,我告诉他先把它的接口开放出来给我,基于这样的体系机构,我就可以去提前去做这样的接口测试,当你还没有把这个东西开发出来的时候,我来做仿真,我来做虚拟化。这个虚拟化很多人都问我这个虚拟化和我们通常讲的云上的硬件的虚拟化有什么区别?我们这个虚拟化是对服务层面的虚拟和,对你被测的对方应用系统直接虚拟化,就把底下中间件、硬件所有的全省掉了,直接虚拟化一个服务。我们看到这个示意图,我来操作的时候首先进到Web服务器,然后直接调用它的中间服务器,我需要去搭建从硬件系统到中间件所有这些工作全省下了。

  刚才讲到的就是针对整个软件工程的变化,引起的一些变化,以及我们有哪些方式来应对。总结,第一要自动化,全面自动化,第二通过一些服务的虚拟化这种技术,尽早的去测试,更高效的去测试。最后我要强调一下,还是回到了体系化这样一个能力矩阵上来,你要真正的做专业测试,必须要把三分技术,七分管理落实到真正可执行的平台上面去。这里面IBM Rational提供了一个协作式,全生命周期的解决方案,实现落地相关的测试管理工作,底下是我们整个专业的测试技术环节,比如白盒、灰盒以及黑盒,这是我们整体的一个质量保障的解决方案。我要讲的就是这么多,谢谢大家!

大家都爱看
查看更多热点新闻