让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（中）
各位都明白了吗？这也是为什么越来越多的用户抛弃了HP Quality Center的原因，内存要求短短几年之间翻了62.5倍！！惊人吧！！！
QC的服务器端姑且不提，看看其复杂而坑爹的客户端——其实还是架构设计的问题。
纯B/S架构带来的好处还有很多，包括友好的用户体验，以及无缝切入移动互联网（手机访问），这些后面会单独列出来提及。
总而言之一堆的问题要注意要设置好，还记得当年我写的那篇《关于"The RPC server is unavailable"的探讨及解决方案》吗？这个也是其中之一。
Micro Focus SCTM就不一样了，它支持项目级的需求基线，而且可以直接切进CaliberRM（这是亮点），这才是真正意义的需求全生命周期管理。
http：//wenku.baidu.com/view/04a20cee998fcc22bcd10d81.html
4、不伦不类的test plan——关于“测试计划”和“测试用例”的混淆。
从TD以来一直到后来的QC、ALM，Quality Center一直把test plan认为是test cases——从这里很容易看出来，设计这款工具的人是做开发出身的，不懂测试，呵呵。
而它的Release模块倒可以理解为粗略的测试计划模块，只是太粗糙了点儿。
QC中有个HP自己鼓吹的“业务驱动测试”的概念，叫：Business Components。核心理念是：BPT(Business Process Testing)，业务流程测试。
SCTM也有个类似的东西叫workbench，基于StoryBoard技术，也不需要编程（Visual Test）。
版权声明：本文出自 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里面，我也衷心希望同行可以借鉴，把这些功能添加到各自的工具模块中，毕竟百花齐放、百家争鸣才是最应该看到的景象。
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
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关文章：
