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软件测试网9oz;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的插件，做敏捷测试管理的，不过我还没有使用过，不敢做太多评论。