一个好的测试用例的度量项应该有哪些

duola1119

一个好的测试用例就注定了这个项目的成败。
那么如何写一个好的测试用例呢？
根据我所掌握的知识，测试用例可以按照黑盒测试的方法来设计。
其中包括：边界值分析，等价类划分，场景分析，正交试验，因果图分析等。
根据这些方法，一个功能点就能够设计出很多个的用例，但随之而来的问题是"设计多少个用例，才算真正的把这个功能点测试完全呢”
对于这个问题就要有度量项确定一个标准，那么符合这个标准的用例，那就是成功的了。
那到底度量项应该包括哪些呢？就请大家积极发言了.

hicome

我认为测试用例的好坏不是以一个为单位来判定的，而是应该以所有测试的一个集合为单位。

至于 "设计多少个用例，才算真正的把这个功能点测试完全呢”，本人觉得每个功能点能完成它的基本作用和几个功能点连接起来的流程都能顺利地执行，就算OK了。

dailrui2002

测试用例是测试执行的基础，其质量的好坏直接关系到测试的质量，也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性，而且包含自动化程度的度量，即多少比例的测试用例已被自动化了。
      测试用例的深度（TCD, Test Case Depth）度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数，而测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量，不同的测试阶段是不一样，应该对同一阶段的不同版本进行比较，而不宜对同一版本的不同阶段进行比较。而测试用例的质量（TCQ, Test Case Quality）可以用由测试用例发现的缺陷数量来度量，即

TCQ = 测试用例发现的缺陷数量/总的缺陷数量

      因为还有一部分缺陷可以通过ad-hoc 测试（随机、自由的测试）、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷

eden_guo

你漏了一个需要 深厚经验的 错误猜测法.通常这个.比较能够写出致命bug的用例

liran

还有白盒测试呢，这个有点简单了.

liran

主要是看你覆盖问题的数量是多少,

duola1119

很赞同dailrui2002提到的度量项。这个测试用例质量提的很好。很受用

樱qq

1、能发现目前为止没有发现的错误
2、可维护性
3、覆盖性高