让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，安装的便捷，怎一个爽字了得！
而且基本不太消耗内存资源，使用起来一点都不卡。
2、强大的易用性。
TD的设计思路简单清晰，整个过程就是：写测试需求–》写测试用例–》执行测试用例–》提交缺陷、跟踪缺陷。总共只有四件事，而且完全符合Testers的日常工作流程。在当时同类竞争对手几乎只有缺陷管理工具Mantis、Bugfree、Bugzilla、ClearQuest，论强大论易用性都明显被拉开了一大截——绝对领先优势！
3、放号策略。
大家应该都还记得著名的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（中）
1、莫名其妙的架构设计。
前面提到过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的便捷性，这几年使用的用户比例也在攀升，而且别忘了，它可以集成很多主流的缺陷管理工具哦！
2、复杂繁琐的安装和登录、惊人的资源消耗。
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，也是如此。
3、过于简化的需求管理模块。
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
4、不伦不类的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)，也有独立的测试计划管理模块，可以建立多级测试计划，也包含了任务分配、工作量估计、风险管理、测试环境管理和分配等，也能通过度量监控测试的执行进度，质量状况。
5、华而不实的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（下）
6、测试设计分析的薄弱。
QC把自己的架构做的很复杂很“强大”，可遗憾的是，在测试的分析设计上却非常的薄弱，可以说几乎没有——很难想象一个被假设为如此强大的公司居然会没有测试分析？这种感觉就像给一个拖拉机安上了波音747的引擎。
关于测试分析：其实业内的大部分测试管理工具往往都是跳过分析这一环直接从测试需求跳到了测试用例设计，而实际上对测试需求分解出来的东西直接进行用例设计的话会造成分解粒度过于粗糙，导致大量测试分析细化的过程无法以可视化的方式体现出来，从而造成漏测。假如你的系统比较复杂，这个过程应该是：从测试需求分解出测试项，测试项分解出测试子项，然后在测试子项中设计测试用例。
TP在这块上做的很不错，可以进行继承性分析、质量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用户场景分析等专业性的分析，通过这些系统性的分析我们可以得到高质量的测试项。而且TP把我们测试人员对分析思考的过程记录和管理起来，这样就实现了对分析过程的评审了。
所有做测试的人都知道V&V，即Test = Verification + Validation。“测试”本质上就是验证和确认，验证过程的正确性，确认结果的正确性。而TP真正意义上实现了既确认结果，又验证过程。但很遗憾，QC不具备这个功能。
而测试设计这块，也就是我们通常提到的等价类划分、边界值分析、判定表、因果图、状态迁移法、场景法（流程分析法）、正交实验法、输出域分析、错误猜测法等各种测试用例设计方法。它们同样在QC中也无法体现，这就意味着我们没有办法评审我们测试设计的过程！而漏了这个过程的评审，那么漏测也是在所难免了！比如我们只考虑了边界值，忽略了两两组合的分析（通过判定表或正交实验），虽然针对需求的覆盖可以达到100%了，但是仍然忽略了一些情况的考虑，那么QC这时是根本“察觉”不出来的。
目前市面上的所有测试管理工具中，普遍缺少这块的功能实现，究其原因，我还是认为这些软件的设计者不是一个经验丰富的测试专家（应该只是做开发出身的），所以忽略了这些核心模块的功能实现。
目前做到这一点的，只有51Testing的Test Platform这款工具——这里我得自卖自夸一下，周峰（90年代就已经通过国家系统分析员认证），对测试的理解确实是高瞻远瞩，要比很多人都深入、全面。而他所有的考虑都融入到了TP里面，我也衷心希望同行可以借鉴，把这些功能添加到各自的工具模块中，毕竟百花齐放、百家争鸣才是最应该看到的景象。
7、忽略白盒测试，缺少代码覆盖率分析。
所有熟知测试过程V模型的人都知道，测试活动分为：单元测试、集成测试、系统测试，验收测试，分别验证软件的内部质量、外部质量、使用质量。
然而QC似乎并不关心这些。因为QC只实现了测试用例对需求的覆盖关联，却没有办法进行代码级别的覆盖率分析。给人感觉QC更多关注的其实是黑盒层面的测试。
而SCTM则进行全面的关注，它也可以关联需求，还可以收集Java/.Net的代码覆盖率，而且可以提供比较报告，让SQA随时掌握代码覆盖率的趋势变化，了解测试用例的充分程度。
这样可以更好的帮助项目成员一起来使用这个测试管理平台。
顺便说一下，SCTM在单元测试这块应该是所有测试管理工具中做的最好的，可以支持Fitness、JUnit、NUnit、.Net Explorer、Process Executor、Windows Scripting等主流的单元测试/集成测试框架，而QC根本不支持，除非你做二次开发。差的远了！
8、最关键的缺陷分析和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软件测试网9o z;R+nG(t2w:V]5LL"m
一句话：QC弱爆了，TP“碉堡了”！！
9、敏捷哪儿去了？
敏捷时代，不能不提敏捷。
“个体与交互胜过过程与工具”——这是著名的《敏捷宣言》的第一条价值观。不过，有意思的是，工具却成了今天大多数敏捷团队的重要组成部分。
做过敏捷的人应该听说过Rally，这家公司是做敏捷项目生命周期管理工具的。其实还有很多，比如VersionOne、Mingle、DotProject、Redmine等。。。
很遗憾，QC不提供这些工具的集成工具，也没有技术支持！
这块做的最好的应该是Micro Focus SCTM，它提供了配套的集成工具，而且还提供技术支持，因为Micro Focus和这些软件厂商本身就是战略伙伴。
当然，Atlassian Jira也是具有敏捷基因的工具，它有个GreenHopper插件，可以通过快速创建User Story来建立一个产品Backlog，可以在整个发布过程中管理Backlog、Sprint，并且监控项目的进度。此外，Jira还有一个名为Bonfire的插件，做敏捷测试管理的，不过我还没有使用过，不敢做太多评论。
10、移动端的访问。
十年前，我就在想这件事情。作为团队的项目经理、测试经理，或公司的老板，日理万机，每天就为了了解项目状况，得扛着笔记本电脑“飞来飞去”，看上去实在大煞风景。更何况，在讲究“碎片化时间利用”的今天，我们在公交上、地铁里，掏出手机访问一下我们的测试管理系统，了解下“张三用例写到哪里了，李四缺陷修复了没有”岂不更加方便、高效？
要说敏捷，我觉得这也算一种“敏捷”。
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还能撑多久，我们拭目以待！
11、用户体验哪儿去了？
其实TD当初的用户体验还真的挺好的，但是QC的用户体验，唉，不提也罢。
庞大的身躯、臃肿的组件、极差的兼容性、缓慢的运行速度、滞后的设计理念、封闭性……其实前面都已经提到过了。
用户体验的精髓在于“Don’t make me think”，而QC却是“make me think hard”。
12、唯一的亮点：Sprinter，探索性测试（Exploratory Testing）和兼容性测试的头号利器！
QC唯一的亮点应该就是从QC 11.0开始推出了Sprinter——一个半自动化测试的集成工具。
它既不是QTP，也不是Selenium，而是可以把你手工测试的过程直接记录下来，进行“自动化回归”，比如屏幕捕捉（截图、截视频）、屏幕记录（截图以后可以在上面做标记）、自动数据注入（Data Injection），可以在执行用例的同时直接生成缺陷报告，非常适合做探索式测试。还可以做镜像测试，也就是同时进行多环境的配置测试，是兼容性测试的利器！我亲见过它的强大，确实“亮瞎了眼”！我推荐大家去体验一把，这种针对手工测试的自动化一点都不需要你有编程基础，用起来又快又方便，真的是“谁用谁知道”！
只是很可惜，HP没有足够的重视Sprinter，没有把这张王牌打好。因为准确的说，QC是用不了Sprinter的，ALM才能支持Sprinter，这意味这你必须先升级到它们的ALM(QC 11)。这成了它的第十二宗罪！
13、离线模式和版本管理。
随着GIT的兴起，离线开发和离线Repository将成为一种新兴的需求和开发模式。
我们51Testing出去和用户推TP的时候，就遇到有用户提出这样的需求（而我们的TP已经实现了离线模式）。但事实上，QC并没有离线模式，必须始终保持QC Connection，而且消耗你的License！
除了51Testing的TP，Micro Focus SCTM也支持离线模式（通过MTC来支持），也可以在你工作完成后提交测试结果。
好吧，即使我们不谈离线模式，就说版本管理，QC仍然在同类测试管理工具中处于下游。QC虽然提供了版本管理的功能，但是非常弱，易用性也极差。比如你编写了测试用例，经过评审之后修改了用例，过几天删除了，过几天又想恢复……那么这些通过QC实现是几乎不可能的。
在版本管理这块，SCTM(Silk Central Test Manager)就不一样了，它可以支持测试用例的版本化，还可以指定当前测试项目测试用例的活动版本！是不是很强大？！
14、相形见绌的扩展性。
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（中）