这里还没说它的服务器端的安装呢！假如你曾装过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
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关文章：
