多数的测试用例管理工具到底缺什么

[read]

•  add: http://www.blogjava.net/qileilove/archive/2013/07/25/401936.html
  [原文]
  QC把自己的架构做的很复杂很“强大”，可遗憾的是，在测试的分析设计上却非常的薄弱，可以说几乎没有——很难想象一个被假设为如此强大的公司居然会没有测试分析？这种感觉就像给一个拖拉机安上了波音747的引擎。
  　　 关于测试分析：其实业内的大部分测试管理工具往往都是跳过分析这一环直接从测试需求跳到了测试用例设计，而实际上对测试需求分解出来的东西直接进行用例设计的话会造成分解粒度过于粗糙，导致大量测试分析细化的过程无法以可视化的方式体现出来，从而造成漏测。假如你的系统比较复杂，这个过程应该是：从测试需求分解出测试项，测试项分解出测试子项，然后在测试子项中设计测试用例。
  　 　TP在这块上做的很不错，可以进行继承性分析、质量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用户场景分析等专业性的分析，通过这些系统性的分析我们可以得到高质量的测试项。而且TP把我们测试人员 对分析思考的过程记录和管理起来，这样就实现了对分析过程的评审了。
  　　所有做测试的人都知道V&V，即Test = Verification + Validation。“测试”本质上就是验证和确认，验证过程的正确性，确认结果的正确性。而TP真正意义上实现了既确认结果，又验证过程。但很遗憾，QC不具备这个功能。
  　 　 而测试设计这块，也就是我们通常提到的等价类划分、边界值分析、判定表、因果图、状态迁移法、场景法（流程分析法）、正交实验法、输出域分析、错误猜测 法等各种测试用例设计方法。它们同样在QC中也无法体现，这就意味着我们没有办法评审我们测试设计的过程！而漏了这个过程的评审，那么漏测也是在所难免 了！比如我们只考虑了边界值，忽略了两两组合的分析（通过判定表或正交实验），虽然针对需求的覆盖可以达到100%了，但是仍然忽略了一些情况的考虑，那 么QC这时是根本“察觉”不出来的。
  　　 目前市面上的所有测试管理工具中，普遍缺少这块的功能实现，究其原因，我还是认为这些软件的设计者不是一个经验丰富的测试专家（应该只是做开发出身的），所以忽略了这些核心模块的功能实现。
  　 　目前做到这一点的，只有51Testing的Test Platform这款工具——这里我得自卖自夸一下，周峰（90年代就已经通过国家系统分析员认证），对测试的理解确实是高瞻远瞩，要比很多人都深入、全 面。而他所有的考虑都融入到了TP里面，我也衷心希望同行可以借鉴，把这些功能添加到各自的工具模块中，毕竟百花齐放、百家争鸣才是最应该看到的景象。
  
  [popexizhi]
  此文分析犀利，“测试设计分析”是啊，pope每次用thinking map 列出的test point 也正是担心这个:），一语道破，看来是同道先辈。
  [next]
  找这里推荐的Test Platform try 一下