让Quality Center走下神坛--测试管理工具大PK（转）

让Quality Center走下神坛--测试管理工具QC/ALM 和 RQM、Jira、TP、SCTM大PK

　　在写完了《让QTP走下神坛》以后，如今来谈谈测试管理工具，献给全部正在或打算作测试管理工做的同行。

　　固然，话题离不了Quality Center——但又不仅是谈QC，我会结合对比各类主流的企业级测试管理工具，包括标题提到的：HP QC/ALM、IBM RQM、51Testing TP、Micro Focus SCTM、Atlassian Jira。可是不会说起Bugzilla、Bugfree、Mantis这些，由于它们只能属于缺陷管理工具，和以上几款工具不在一个级别上。

　　固然，得先从QC提及。

　　既然说起Quality Center，就得先谈Mercury，而既然说起Mercury，就得先谈HP。毕竟是大环境的衰败造就了QC的没落，难道不是吗？

　　（一）所以，先说HP。

　　HP原来有三大业务：PSG、IPG、EB，分别是我的电脑，打印和影像设备，企业级业务（软件服务）。PC业务利润微薄，压力大，HP早已江河日下；打印机扫描仪随着iPad等设备出现，早已经疲态尽显；HP倒一直想模仿IBM转型服务，号称要打造“Service Anywhere（一切皆服务）”，但从QTP、LoadRunner和Quality Center多年以来除了更换了华丽的界面，新增了零星半点的小特性，愈来愈耗资源，愈来愈不稳定，甚至继续保留着一堆N年之前的Bug，……，管中窥豹，可知其所谓的服务愈来愈流于表面了。

　　听说今年HP对外宣称本身作组织架构调整，变为PPS（打印）、EG（企业集团）、ES（企业服务）和HP Software（软件），我对HP内部不太熟，不过在我看来换汤不换药。它们在历史上架构不知道调整了多少次，用业内人的说法是“老是在用一个错误纠正另外一个错误”。

　　（二）再说Mercury和Quality Center。

　　HP在2006年7月以45亿美圆收购了Mercury公司。而在此以前，Mercury是专一与软件测试工具研发的专业厂商，曾几什么时候在测试工具这块与Rational、Segue号称“测试三巨头”。它们推出的每一款产品都堪称划时代：测试管理工具TestDirector、性能测试工具LoadRunner、功能测试自动化工具WinRunner/QuickTest，分别迅速占领了全球70%左右的市场，时至今日，仍然威震江湖。

　　QC为何能有很强大的用户基础，其实不是由于QC的强大，归根结底，是TD当年打下大片江山，占尽了用户基础。我是从TD(TestDirector 7.2)开始用的，十年前当我第一次看到TestDirector真的是“亮瞎了眼”！世界上竟然有这么Cool的测试管理工具！亮点在哪里？

　　TD的安装至关简单，几乎是傻瓜式操做，“下一步”、“下一步”、……、“完成”。连数据库都删繁就简的采用Access，安装的便捷，怎一个爽字了得！

　　并且基本不太消耗内存资源，使用起来一点都不卡。

　　二、强大的易用性。

　　TD的设计思路简单清晰，整个过程就是：写测试需求–》写测试用例–》执行测试用例–》提交缺陷、跟踪缺陷。总共只有四件事，并且彻底符合Testers的平常工做流程。在当时同类竞争对手几乎只有缺陷管理工具Mantis、Bugfree、Bugzilla、ClearQuest，论强大论易用性都明显被拉开了一大截——绝对领先优点！

　　三、放号策略。

　　你们应该都还记得著名的TD License吧？有人称之为“Sale Policy”。什么意思呢？就是当初Mercury推出TD 7.6的时候，网上马上有人出来发布TD 7.2的License；当Mercury推出8.0的时候，网上马上有人出来发布TD 7.6的License；当HP Mercury推出Quality Center 8.2的时候，网上马上有人出来发布TD 8.0的License……

　　呵呵，就这么巧合，至于为何会这样，明眼人一看就知。如今明白什么叫“Sale Policy”了吗？我先让你用旧版的，等你用上了之后，数据都在上面了，而后我推新版的，诱惑你用，……，一步步让你深陷其中，当你有一天发现你已经离不开个人时候，我对你实行收费……WOW！pfpf，果真厉害！因此，一代又一代的Test Manager前赴后继，大力推行TD。51Testing软件测试网%t Vm%}'p！i+_

　　可是大家看，如今HP ALM还有吗？我绝不怀疑，没有继续延续以前的战略方针，ALM确实正在不断失守城池。《2012年测试从业人员调查报告》能够清晰看到，下面会有详细描述。

　（三）嫁对男人是女人一辈子的事业。

　　悲剧就在这里，自从HP收购了Mercury，内部发生了大动乱，HP素以抠门闻名，收购了Mercury研发团队后，不少人的薪资被砍掉了三分之二！因而整个团队分崩离析……

　　这也是为何你们总感受当初使用Mercury工具的时候那样心潮澎湃，如今往往看到HP的升级版却诸多失望多于指望。由于最核心的高层、架构师和专家早已离开了HP Mercury团队。

　　因此，大家都看到了，……，就像QTP的新版本UFT同样，加了什么PDF验证、类加强、支持移动设备……，都有啥用啊？！你内核没有改变啊，大侠。。。一一大帮子人作了一全年就加了这么一点东西，还好意思拿出来讲啊？！

　　QC也莫过于此。

　　（四）关于“更名”的乐趣。

　　从频繁更名就能够知道HP的无能——没有本事升级内核，只能改改花哨的界面，加一点噱头，再换个名字，看看都有啥名字吧。

　　测试管理工具：TestDirectoràQuality CenteràALM

　　自动化测试：Astra QuickTestàQuickTest ProfessionalàUFT

　　HP确定会说：你不了解名字背后的意义，好吧，我替大家来讲：TD升级为QC的本意是从测试整合为质量中心，把QTP捆绑进来，QC更名为ALM就是但愿它再也不只是针对测试或质量的管理平台，而是一个完整的软件生命周期管理平台。

　　我想问一句：累不累啊？真觉得改了名字之后用户就收获了什么好处吗？我倒以为反而增长了用户的认知成本、使用成本，最终反而伤害了本身的品牌。

　　（五）没落是一个不争的事实。

　　好吧，废话不说，下图是咱们针对国内测试从业人员作的问卷调查。你能够看到QC正在市场上节节败退，按正常估计，明年必定跌破四成——极有可能被Atlassian Jira取代霸主地位。

　　看到了吗？QC从昔日的一股独大，变成了今天群雄并争。最明显的就是Jira，从2009年的14%上升为24%！！猛增10个百分点哦！这风头在自动化那边也是一样，Selenium从2009年的4%上升为12%。

　　为何？不少缘由。且听我细细道来。为了更好的说明，我以和它体量至关的大型测试管理平台好比Micro Focus SCTM(Silk Central Test Manager)、51Testing TestPlatform、IBM RQM来跟它作个简单对比——为何不拿Atlassian Jira对比？由于Jira如今虽然也在朝着“全生命周期管理”的方向靠，也有需求管理、错误跟踪这些模块，可是走的路数和QC不太同样（设计思路不太同样，Jira走的是敏捷&项目管理模式），并且对测试需求和测试用例没有提供直接的方式进行管理（能够和别的工具集成），很差对比。固然后面仍是会说起。

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

原创做品，转载时请务必以超连接形式标明本文原始出处、做者信息和本声明，不然将追究法律责任。

相关文章：

让Quality Center走下神坛--测试管理工具大PK（中）

　一、莫名其妙的架构设计。

　　前面提到过TestDirector的架构设计，彻底走轻快的路子，B/S架构，基于Windows 2000平台，安装IIS4.0便可，数据库能够是Access/Sybase/SQL Server6.5,7.0,2000/Oracle7,8,9这些，内存只须要128M，CPU只要PentiumⅡ足矣。

　　可是到了QC的时候，莫名其妙的变成了Java EE架构，号称能够安装在Windows、Linux、Solaris等系统上，Web服务器能够是Apache、IIS，应用服务器能够是JBOSS、WebLogic、WebSphere，一个比一个复杂，一个比一个强大，……，架构师对外宣称QC能够更好的支持企业级用户，支持高并发……

　　到了QC 11.5(ALM 11.5)的时候，官方的建议配置变成了Windows 2008 sp2 64bit + JBOSS 5.1 + SQLServer 2008 sp1，最低配置也得是Windows 2003 sp2 + (IIS 6) + JBoss 5.1 + SQL Server 2005 sp3，而硬件方面的最低配置更让人咂舌——最低内存8 GB！硬盘最少8GB！并且连客户端的内存最低配置都必须是2GB！

　　各位都明白了吗？这也是为何愈来愈多的用户抛弃了HP Quality Center的缘由，内存要求短短几年之间翻了62.5倍！！惊人吧！！！

　　看到这里我狂汗啊！要知道，微软Windows 2000这么庞大的系统，不过动用了1700个开发，3200个测试，世界上有几个微软这种巨量级的软件研发公司？难道他们的架构师没有读过《长尾理论》？事实上，大部分的公司测试开发比原本就很低，真正考虑到实时并发的话，能作到一两百并发读写已经很好了，并且就像Infosys、Tata这样的航空母舰级的外包服务公司，也没有必要整个公司只用一个QC啊——再者说了，就算出于企业级管理的须要，这样的公司能有几家，为这些大公司定制化一个不就好了吗？真正要考虑的是广大的受众群体所在的企业规模和研发团队规模啊！兄弟，这只是一个内部研发管理系统！对内的系统决定了对性能的要求不可能像对外开放的大型系统那么高，既不是12306，也不是天猫，更不是谷歌/百度首页，设计这样的架构，我想问一句：有那必要吗？图啥呢？

　　假如还以为不够的话，那么咱们对比看看如今也很是流行的TestLink——一款能够和Jira、Bugzill、Mantis集成的测试过程管理工具。它的架构很是的简单：WAMP/LAMP，也就是Windows/Linux + Apache + PHP + MySQL。由于如今有大量的一键集成安装包（如WAMP Server、XAMPP），因此安装过程极其简单方便。正是由于TestLink的便捷性，这几年使用的用户比例也在攀升，并且别忘了，它能够集成不少主流的缺陷管理工具哦！

　　二、复杂繁琐的安装和登陆、惊人的资源消耗。

　　QC的服务器端姑且不提，看看其复杂而坑爹的客户端——其实仍是架构设计的问题。

　　相信不少朋友都见过下图的这个页面吧？

　　假如你真的常用Quality Center的话，必定对这个页面再熟悉不过，相信你们都有同感，这个页面每每须要下载很是的久，运气很差的话得下载5-10分钟，并且还常常下载到最后了打不开！！这时还得检查有没有关闭UAC(User Account Control)、DEP(Data Extension Prevention)等等，这种BT的架构设计真的让人难以想象了：这明明是B/S架构的系统，为啥须要下载安装这么多ActiveX？这不是挂羊头卖狗肉，打着B/S的旗帜，行C/S之事吗？与其这么麻烦，还不如你就作成C/S算了！

　　固然，它还真有客户端，并且官方推荐你使用，叫：QC Explorer。说白了，就是专门为打开QC开发的一款基于IE内核的浏览器。唉，真的无语了，放着那么多流行的JavaScript. Framework Libraries不用，偏要用ActiveX这种落伍又笨拙的东西。这还没关系，关键是这样一来，对你的浏览器就会很是的挑剔！请看这段官方描述（针对QC客户端的浏览器要求）：Microsoft Internet Explorer 7 or 8。就是说你的客户端只能用微软的IE浏览器，并且必须是IE 7或者IE 8这个版本，不能用微软的IE 6或IE 9（必定要用高版本的IE还获得jboss\server\default\deploy目录下修改20qcbin.war里的内容），不能用Chrome、Firefox，更别提什么Opera、Safari之流了。还有更让人崩溃的，就是除了浏览器以外，你的系统上还必需要安装：Microsoft .NET Framework 3.5 (SP1)、Visual C++ 2005 SP1 ATL Security Update Redistributable、Microsoft Office 2007 (SP2)等一系列东西，你说有多烦有多烦！！！

　　相比之下，真的建议他们（HP QC的架构师）去学习一下Jira和Micro Focus SCTM，所有是用JavaScript类库实现，真正意义上的纯B/S架构，因此全部的浏览器均可以轻松访问，无需额外安装其余ActiveX！

　　纯B/S架构带来的好处还有不少，包括友好的用户体验，以及无缝切入移动互联网（手机访问），这些后面会单独列出来说起。

　这里还没说它的服务器端的安装呢！假如你曾装过Quality Center的服务器端，十有八九遇到过“数据库链接属性不正确”的问题，通常缘由是数据库那边还得再作正确的配置，具体得看是SQL Server仍是Oracle，各有各的招，这里就很少说了。

　　总而言之一堆的问题要注意要设置好，还记得当年我写的那篇《关于"The RPC server is unavailable"的探讨及解决方案》吗？这个也是其中之一。

　　再来讲资源消耗。其实从上面的“最低配置要求8GB内存”你们就能够大体看出QC有多吃内存了。这么说吧，咱们51Testing的讲师都最怕上QC这门课，不是由于这门课很难，而是很痛苦，每次从虚拟机里启动出来至少15分钟，中间还有不少操做也很是的卡。PS：我用的笔记本是HP ProBook 4230s，CPU是i3-2310M 2.10GHz，内存8GB，也是如此。

　　三、过于简化的需求管理模块。

　　QC的需求管理严格意义上不属于真正意义上“开发需求的管理”，而是指针对测试需求的管理，而且能够结合Release模块设定简单的基线，不过若是你用过CaliberRM这种专业级的需求管理工具，就会发现QC的Requirements实在是弱爆了！

　　Micro Focus SCTM就不同了，它支持项目级的需求基线，并且能够直接切进CaliberRM（这是亮点），这才是真正意义的需求全生命周期管理。

　　固然假如你的SRS是word文档，QC倒也能够把开发需求导入进去，可是问题是QC的word插件很是很是难用，导入的工做量一点都不比你本身手工输入来的快（由于须要针对每个需求项去打begin和end标记）！！因此一般咱们在企业实战中只能采用折中的方式，先把SRS转为Excel文档，再经过Excel Addin导入进去，固然导入的过程也不那么轻松，具体能够参考个人《ALM(Quality Center) Excel Addin深刻剖析》，连接是：

　　http：//wenku.baidu.com/view/04a20cee998fcc22bcd10d81.html

　　四、不三不四的test plan——关于“测试计划”和“测试用例”的混淆。

　　从TD以来一直到后来的QC、ALM，Quality Center一直把test plan认为是test cases——从这里很容易看出来，设计这款工具的人是作开发出身的，不懂测试，呵呵。

　　测试计划是什么？首先测试过程会分为计划、设计、实现、执行几个活动（按ISTQB的说法是测试过程分为计划和控制阶段、分析和设计阶段、实现和执行阶段、评估出口准则和报告阶段以及结束收尾阶段），分别解决“作什么”、“如何作”、“具体步骤是什么”、“发现缺陷并跟踪缺陷”、“评估测试报告”这几个问题。

　　《测试计划》，是有国际性的模板的，即IEEE 829。请各位参考维基百科：http：//zh.wikipedia.org/wiki/IEEE_829内容包括明确组织形式（强矩阵、平衡矩阵、弱矩阵），明确测试对象，明确测试的需求跟踪和覆盖，明确测试的“经过/失败”标准，明确测试的挂起标准和恢复条件，明确工做的任务分配，明确项目可交付物。

　　然而，QC里所谓的测试计划（test plan）对于以上这些通通没有涉及，实质上倒是编写测试用例的模块，你能够看到用例的目录规划、用例的名称、用例的步骤，还能够看到用例的类型（是手工测试仍是自动化测试），……，总而言之，这就是Test Cases。

　　而它的Release模块倒能够理解为粗略的测试计划模块，只是太粗糙了点儿。

　　真正作到了能够沿着IEEE 829的样板编写测试计划的工具目前尚未，不过IBM RQM算是比较接近的，它们可定义作到的是定义测试目标，定义过程，定义每次迭代的进度并对重要的milestone跟踪，能够估计工做量，能够列出测试环境，定义开始和结束的标准，……，整体来讲还算不错。

　　还有就是咱们51Testing的TP(Test Platform)，也有独立的测试计划管理模块，能够创建多级测试计划，也包含了任务分配、工做量估计、风险管理、测试环境管理和分配等，也能经过度量监控测试的执行进度，质量情况。

　　五、华而不实的Business Components。

　　QC中有个HP本身鼓吹的“业务驱动测试”的概念，叫：Business Components。核心理念是：BPT(Business Process Testing)，业务流程测试。

　　干吗用呢？简单的说，就是让SME（主题事件专家，也就是“业务专家”）能够借助自身对业务的熟悉经过对系统的熟练操做，让这个Business Components把全部操做记录下来，生成一个自动化脚本，而后经过QTP进行回归测试（只能经过QTP）。实际上若是你们对QTP的Keyword View比较熟悉的话，就能明白是怎么回事了。HP认定作测试的人主要分为两类：一类熟悉测试技术（包括精通编程、数据库，但对业务不甚精熟），一类则熟悉业务（但多是编程白痴），这两类人都有测试的盲点，经过这个业务设计让两类大相径庭的人得以协做。很美好吧？其实也有一点儿TDD的味道（沾边）。

　　SCTM也有个相似的东西叫workbench，基于StoryBoard技术，也不须要编程（Visual Test）。

　　但事实上，不多有公司能够作到清晰的划分这些，每每作测试的必须懂业务，即便你是自动化测试工程师，也得了解业务。因此，……，就黄了，这个组件根本没有办法大面积推广开，在内部被证实失败以后，HP开始转型作 Sprinter——这个东西后面会提，是个神器！不过国内尚未汉化，也几乎没人深刻研究，大部分testers还没能体会到它的强大。

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

原创做品，转载时请务必以超连接形式标明本文原始出处、做者信息和本声明，不然将追究法律责任。

相关文章：

让Quality Center走下神坛--测试管理工具大PK（上）

让Quality Center走下神坛--测试管理工具大PK（下）

　六、测试设计分析的薄弱。

　　QC把本身的架构作的很复杂很“强大”，可遗憾的是，在测试的分析设计上却很是的薄弱，能够说几乎没有——很难想象一个被假设为如此强大的公司竟然会没有测试分析？这种感受就像给一个拖拉机安上了波音747的引擎。

　　关于测试分析：其实业内的大部分测试管理工具每每都是跳过度析这一环直接从测试需求跳到了测试用例设计，而实际上对测试需求分解出来的东西直接进行用例设计的话会形成分解粒度过于粗糙，致使大量测试分析细化的过程没法以可视化的方式体现出来，从而形成漏测。假如你的系统比较复杂，这个过程应该是：从测试需求分解出测试项，测试项分解出测试子项，而后在测试子项中设计测试用例。

　　TP在这块上作的很不错，能够进行继承性分析、质量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用户场景分析等专业性的分析，经过这些系统性的分析咱们能够获得高质量的测试项。并且TP把咱们测试人员对分析思考的过程记录和管理起来，这样就实现了对分析过程的评审了。

　　全部作测试的人都知道V&V，即Test = Verification + Validation。“测试”本质上就是验证和确认，验证过程的正确性，确认结果的正确性。而TP真正意义上实现了既确认结果，又验证过程。但很遗憾，QC不具有这个功能。

　　而测试设计这块，也就是咱们一般提到的等价类划分、边界值分析、断定表、因果图、状态迁移法、场景法（流程分析法）、正交实验法、输出域分析、错误猜想法等各类测试用例设计方法。它们一样在QC中也没法体现，这就意味着咱们没有办法评审咱们测试设计的过程！而漏了这个过程的评审，那么漏测也是在所不免了！好比咱们只考虑了边界值，忽略了两两组合的分析（经过断定表或正交实验），虽然针对需求的覆盖能够达到100%了，可是仍然忽略了一些状况的考虑，那么QC这时是根本“察觉”不出来的。

　　目前市面上的全部测试管理工具中，广泛缺乏这块的功能实现，究其缘由，我仍是认为这些软件的设计者不是一个经验丰富的测试专家（应该只是作开发出身的），因此忽略了这些核心模块的功能实现。

　　目前作到这一点的，只有51Testing的Test Platform这款工具——这里我得自卖自诩一下，周峰（90年代就已经经过国家系统分析员认证），对测试的理解确实是高瞻远瞩，要比不少人都深刻、全面。而他全部的考虑都融入到了TP里面，我也衷心但愿同行能够借鉴，把这些功能添加到各自的工具模块中，毕竟百花齐放、百家争鸣才是最应该看到的景象。

　　七、忽略白盒测试，缺乏代码覆盖率分析。

　　全部熟知测试过程V模型的人都知道，测试活动分为：单元测试、集成测试、系统测试，验收测试，分别验证软件的内部质量、外部质量、使用质量。

　　然而QC彷佛并不关心这些。由于QC只实现了测试用例对需求的覆盖关联，却没有办法进行代码级别的覆盖率分析。给人感受QC更多关注的实际上是黑盒层面的测试。

　　而SCTM则进行全面的关注，它也能够关联需求，还能够收集Java/.Net的代码覆盖率，并且能够提供比较报告，让SQA随时掌握代码覆盖率的趋势变化，了解测试用例的充分程度。

　　这样能够更好的帮助项目成员一块儿来使用这个测试管理平台。

　　顺便说一下，SCTM在单元测试这块应该是全部测试管理工具中作的最好的，能够支持Fitness、JUnit、NUnit、.Net Explorer、Process Executor、Windows Scripting等主流的单元测试/集成测试框架，而QC根本不支持，除非你作二次开发。差的远了！

　　八、最关键的缺陷分析和Report功能。

　　常常有朋友问我QC导出报告的问题，好比怎么把测试用例或缺陷以Excel的方式导出。其实QC的报告导出功能也很弱，特别是在Excel上，并且word的导出一直有Bug，基本上不可定制的，特别是你若是针对前面的Test Plan等模块作过定制化或二次开发，在导出的时候会有各类问题。

　　后来QC整合了Dashboard（其实就是展示各类数据指标的仪表盘），可是这意味着你必须是Enterprise Edition（收费更高昂），并且即便整合了Dashboard，只是在展现上更华丽了，导出的问题仍是没解决！而其实“测试报告”才是关键，只要作过项目的兄弟都知道，甲方须要的是漂亮的word报告！

　　而SCTM的报告功能却很是的丰富，它提供了一个专门的报告引擎BIRT，能够定制各类报告，也能够支持项目群报告、Dashboard，并且最重要的是：它们都是免费的！

　　再说度量和缺陷分析，这更是QC的一大软肋！严格意义上来讲，QC的那些数据分析离真正的缺陷分析还很是的远！能够说几乎就没有。而51Testing TP在这块上作的很是出众，提供了专业的ODC分析、Gompertz分析、Rayleigh分析、四象限分析、DRE/DRM等工程分析方法，能够对缺陷进行单、多维度分析、进行缺陷趋势分析、对缺陷进行预测等，为测试工做质量评估、测试退出判断、遗留缺陷预测提供支撑。51Testing软件测试网9oz;R+nG(t2w:V]5LL"m

　　一句话：QC弱爆了，TP“碉堡了”！！

　　九、敏捷哪儿去了？

　　敏捷时代，不能不提敏捷。

　　“个体与交互赛过过程与工具”——这是著名的《敏捷宣言》的第一条价值观。不过，有意思的是，工具却成了今天大多数敏捷团队的重要组成部分。

　　作过敏捷的人应该据说过Rally，这家公司是作敏捷项目生命周期管理工具的。其实还有不少，好比VersionOne、Mingle、DotProject、Redmine等。。。

　　很遗憾，QC不提供这些工具的集成工具，也没有技术支持！

　　这块作的最好的应该是Micro Focus SCTM，它提供了配套的集成工具，并且还提供技术支持，由于Micro Focus和这些软件厂商自己就是战略伙伴。

　　固然，Atlassian Jira也是具备敏捷基因的工具，它有个GreenHopper插件，能够经过快速建立User Story来创建一个产品Backlog，能够在整个发布过程当中管理Backlog、Sprint，而且监控项目的进度。此外，Jira还有一个名为Bonfire的插件，作敏捷测试管理的，不过我尚未使用过，不敢作太多评论。

 

　十、移动端的访问。

　　十年前，我就在想这件事情。做为团队的项目经理、测试经理，或公司的老板，日理万机，天天就为了了解项目情况，得扛着笔记本电脑“飞来飞去”，看上去实在大煞风景。更况且，在讲究“碎片化时间利用”的今天，咱们在公交上、地铁里，掏出手机访问一下咱们的测试管理系统，了解下“张三用例写到哪里了，李四缺陷修复了没有”岂不更加方便、高效？

　　要说敏捷，我以为这也算一种“敏捷”。

　　QC有移动端APP吗？或是能经过手机浏览器访问吗？道听途说过，却从不曾见。我的以为很不靠谱，为何？别忘了前面第2点提到的QC客户端对Windows平台和IE浏览器的依赖，假如咱们用的是iPhone、iPad，或者Android设备，那怎么可能访问呢？

　　相比之下，Jira和SCTM就具备这样的先天优点了。为何呢？别忘了它们都是用JavaScript类库实现的，不须要安装ActiveX，是真正的纯B/S——天然能够经过手机浏览器访问了！

　　事实上，Jira确实有移动端的APP，我刚特意去App Store上搜索了一下，呵呵，见下：

　　并且，连Bugzilla也有移动端的APP了！

　　我的以为，移动互联网时代，这些测试管理工具也都将面临着新一轮的洗牌，HTML5的支持、CSS3的支持、大量的JavaScript类库……QC还能撑多久，咱们拭目以待！

　　十一、用户体验哪儿去了？

　　其实TD当初的用户体验还真的挺好的，可是QC的用户体验，唉，不提也罢。

　　庞大的身躯、臃肿的组件、极差的兼容性、缓慢的运行速度、滞后的设计理念、封闭性……其实前面都已经提到过了。

　　用户体验的精髓在于“Don’t make me think”，而QC倒是“make me think hard”。

　　十二、惟一的亮点：Sprinter，探索性测试（Exploratory Testing）和兼容性测试的头号利器！

　　QC惟一的亮点应该就是从QC 11.0开始推出了Sprinter——一个半自动化测试的集成工具。

　　它既不是QTP，也不是Selenium，而是能够把你手工测试的过程直接记录下来，进行“自动化回归”，好比屏幕捕捉（截图、截视频）、屏幕记录（截图之后能够在上面作标记）、自动数据注入（Data Injection），能够在执行用例的同时直接生成缺陷报告，很是适合作探索式测试。还能够作镜像测试，也就是同时进行多环境的配置测试，是兼容性测试的利器！我亲见过它的强大，确实“亮瞎了眼”！我推荐你们去体验一把，这种针对手工测试的自动化一点都不须要你有编程基础，用起来又快又方便，真的是“谁用谁知道”！

　　只是很惋惜，HP没有足够的重视Sprinter，没有把这张王牌打好。由于准确的说，QC是用不了Sprinter的，ALM才能支持Sprinter，这意味这你必须先升级到它们的ALM(QC 11)。这成了它的第十二宗罪！

　　1三、离线模式和版本管理。

　　随着GIT的兴起，离线开发和离线Repository将成为一种新兴的需求和开发模式。

　　咱们51Testing出去和用户推TP的时候，就遇到有用户提出这样的需求（而咱们的TP已经实现了离线模式）。但事实上，QC并无离线模式，必须始终保持QC Connection，并且消耗你的License！

　　除了51Testing的TP，Micro Focus SCTM也支持离线模式（经过MTC来支持），也能够在你工做完成后提交测试结果。

　　好吧，即便咱们不谈离线模式，就说版本管理，QC仍然在同类测试管理工具中处于下游。QC虽然提供了版本管理的功能，可是很是弱，易用性也极差。好比你编写了测试用例，通过评审以后修改了用例，过几天删除了，过几天又想恢复……那么这些经过QC实现是几乎不可能的。

　　在版本管理这块，SCTM(Silk Central Test Manager)就不同了，它能够支持测试用例的版本化，还能够指定当前测试项目测试用例的活动版本！是否是很强大？！

　　1四、相形见绌的扩展性。

　　QC几乎没有任何扩展性！虽然它有一个Add-in Pages，可是基本都没有和业界主流工具集成，上面能够下载的都是诸如QTP Addin、Excel Addin这种东西，实在不值一提。

　　扩展性这块，Jira很不错，不过最强的仍是SCTM，还记得前面发过的文章吗？——《你见过的这么强大的开箱即用的测试管理工具吗？》

　　好吧，这里再次描述一次：SCTM号称业界最开放的测试管理平台，需求部分支持CaliberRM、DOORS、RequisitePro、Word，变动管理部分支持StarTeam、Subversion(SVN)、VSS、CVS、PVCS、VSTS，缺陷管理部分支持Atlassian Jira、Bugzilla、IBM ClearQuest、Microsoft VSTS、StarTeam，自动化测试这块支持JUnit、NUnit、Fitness、TestPartner、SilkTest、SilkPerformer、VMWare Lab Manager……听说如今还在增长扩展……不得不赞美一句，牛B！

　　OK，至此，《让Quality Center走下神坛》已经所有打完收工！

版权声明：本文出自 songfun 的51Testing软件测试博客：copy Bookmark http://www.51testing.com/?songfun

原创做品，转载时请务必以超连接形式标明本文原始出处、做者信息和本声明，不然将追究法律责任。

相关文章：

让Quality Center走下神坛--测试管理工具大PK（上）

让Quality Center走下神坛--测试管理工具大PK（中）