什么是好的测试用例(三)[1] 测试用例设计
基于规范的测试
检查相关文档中的关于程序的每一个声明，例如设计规范、需求列表、用户接口描述，发布原型、或者用户手册。
在企业中，严格按他们的规范进行测试是非常重要的(有激发性的)。比如，如果规范是合同的一部分，遵照规范是非常重要的。同样，产品必须遵照他们的声明，关乎生命的产品必须遵照所有与安全相关的规范。
规范驱动的测试一般是比较弱的，对特定规范条目进行测试的这类测试是明显不具有代表性的。
某些基于规范测试的团队仅仅局限于文档中的描述。对他们来说，一个好的测试集合包含了规范中为每一个声明制定的明确的、有关的测试。
其他团队对规范中的问题有长远见解。他们发现，对说明详尽的产品进行的大多数信息测试经常会出现规范中的不明确点，或者检查说明不详尽的产品。
基于风险的测试
设想程序失败的一个情形，然后设计一个或多个测试来检查这个程序是否真的会在那种情形下失败。 软件测试
一个完美的基于风险测试的集合应该基于一个详尽的风险列表，一个每种情形都能使程序失败的列表。
一个好的基于风险的测试是一个致力于解决特定风险测试的一个典型代表。
测试中出现重大失误或者对手产品有明显失误，在这种程度上，基于风险的失败会是非常可靠、非常有激发性的。但是，很多基于风险的测试在理论上(实际应用中不可能发生)是被忽略的。(潜在失误)从实际存在的失误中测出来的风险是很有价值的，会使测试更可靠。
基于风险的测试在于传递高度的信息价值，因为你有理由相信产品中确实存在你要测的问题。我们能从程序能否通过测试中学到很多东西。
压力测试
下面是压力测试的几种不同定义：
一个普通的定义，用一个峰值脉冲活动来冲击程序，看他是否会失败。
IEEE标准610.12-1990是这样定义的：“测试把致使系统故障做为目标来评价一个系统或组件是否超出其指定的需求。”
为监视程序如何失败而用第三种方法使程序陷入故障。
比如，如果测试使用了过多的输入，那么你不只是测试规定的限额。你不断增加输入的尺度或速度，直到程序最终失败或者你确信进一步的增加不会导致失败。事实上程序最终失败不会明显的令人惊讶或者激动。当你看到失败，询问暴露了什么弱点以及在低于极限环境下时其中哪些弱点会被触发是令人感兴趣的。Jorgensen(2003)提供了一个这种类型的有诱惑力的例子。
我是以第三种定义工作的。
这些测试是很有力度的。
有些人忽视了压力测试使得对顾客的使用不具代表性，因此不可靠、不具目的性。压力测试的另一个问题是失败是没用的，除非测试提供了一个解决问题的信息，或者领导测试的人员对其应用非常熟悉。
一个好的压力测试推动了你想增加的极限，包括足够的诊断支持使你在看到失败时，非常容易地发现。
有些测试人员，比如Alberto Savoia(2000)，用类似压力测试来暴露失败，这很难察看系统是否同时运行了若干个任务。这些失败通常在系统的理论限制内暴露出来，因此它们是更可靠、更有目的性，但它们不便于解决问题。
回归测试
设计、开发和保存测试的目的是有规律地重复利用它们，发生变更之后对程序做重复测试。
有必要注意的一点(考虑回归测试)是这不是测试类型的一个直交列表。你可以给你的回归测试集合输入域测试或者基于规范的测试或者其他任何测试类型。
所以这些与其他测试之间有什么不同之处?我将用例子来回答这个问题：
假设一个测试人员创建了一组域测试并保存之以便于复用。这是域测试还是回归测试?
在创建测试时如果测试人员主要考虑区分变量，并找到最具代表性的一个时，我认为它是主要是域测试。
如果测试人员主要考虑创建一个复用测试集合的话，我认为它主要是回归测试。
如果是第一次设计的回归测试，那他们应该是有力的、可靠的等等。但是，在一个测试多次运行并通过之后，程序不可能在下一次测试时失败，除非发生了较大的变更或者部分代码变更直接参与了这个测试。因此，多数情况下，回归测试会产生很小的信息价值。
一个好的回归测试是为复用设计的。它是完全文档化的和可维护的。(建议：提高GUI级测试的可维护性，参见Graham & Fewster,1999;Kaner,1998; Pettichord,2002,以及www.perrichord.com上的论文)。
如果变更减少了程序进行回归测试在功能或范围上的错误，那么一个设计的好的回归测试可能会失败。
文章来源于领测软件测试网 https://www.ltesting.net/
