让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（中）