基于规范的测试检查相关文档中的关于程序的每一个声明，例如设计规范、需求列表、用户接口描述，发布原型、或者用户手册。
在企业中，严格按他们的规范进行测试是非常重要的（有激发性的）。比如，如果规范是合同的一部分，遵照规范是非常重要的。同样，产品必须遵照他们的声明，关乎生命的产品必须遵照所有与安全相关的规范。
规范驱动的测试一般是比较弱的，对特定规范条目进行测试的这类测试是明显不具有代表性的。
某些基于规范测试的团队仅仅局限于文档中的描述。对他们来说，一个好的测试集合包含了规范中为每一个声明制定的明确的、有关的测试。
其他团队对规范中的问题有长远见解。他们发现，对说明详尽的产品进行的大多数信息测试经常会出现规范中的不明确点，或者检查说明不详尽的产品。
基于风险的测试设想程序失败的一个情形，然后设计一个或多个测试来检查这个程序是否真的会在那种情形下失败。
一个完美的基于风险测试的集合应该基于一个详尽的风险列表，一个每种情形都能使程序失败的列表。
一个好的基于风险的测试是一个致力于解决特定风险测试的一个典型代表。
测试中出现重大失误或者对手产品有明显失误，在这种程度上，基于风险的失败会是非常可靠、非常有激发性的。但是，很多基于风险的测试在理论上（实际应用中不可能发生）是被忽略的。（潜在失误）从实际存在的失误中测出来的风险是很有价值的，会使测试更可靠。
基于风险的测试在于传递高度的信息价值，因为你有理由相信产品中确实存在你要测的问题。我们能从程序能否通过测试中学到很多东西。
压力测试下面是压力测试的几种不同定义：
一个普通的定义，用一个峰值脉冲活动来冲击程序，看他是否会失败。
IEEE标准610.12-1990是这样定义的：“测试把致使系统故障做为目标来评价一个系统或组件是否超出其指定的需求。” l为监视程序如何失败而用第三种方法使程序陷入故障。
比如，如果测试使用了过多的输入，那么你不只是测试规定的限额。你不断增加输入的尺度或速度，直到程序最终失败或者你确信进一步的增加不会导致失败。事实上程序最终失败不会明显的令人惊讶或者激动。当你看到失败，询问暴露了什么弱点以及在低于极限环境下时其中哪些弱点会被触发是令人感兴趣的。Jorgensen（2003）提供了一个这种类型的有诱惑力的例子。
我是以第三种定义工作的。
这些测试是很有力度的。
有些人忽视了压力测试使得对顾客的使用不具代表性，因此不可靠、不具目的性。压力测试的另一个问题是失败是没用的，除非测试提供了一个解决问题的信息，或者领导测试的人员对其应用非常熟悉。
一个好的压力测试推动了你想增加的极限，包括足够的诊断支持使你在看到失败时，非常容易地发现。
有些测试人员，比如Alberto Savoia（2000），用类似压力测试来暴露失败，这很难察看系统是否同时运行了若干个任务。这些失败通常在系统的理论限制内暴露出来，因此它们是更可靠、更有目的性，但它们不便于解决问题。
回归测试设计、开发和保存测试的目的是有规律地重复利用它们，发生变更之后对程序做重复测试。
有必要注意的一点（考虑回归测试）是这不是测试类型的一个直交列表。你可以给你的回归测试集合输入域测试或者基于规范的测试或者其他任何测试类型。
所以这些与其他测试之间有什么不同之处？我将用例子来回答这个问题：
假设一个测试人员创建了一组域测试并保存之以便于复用。这是域测试还是回归测试？
在创建测试时如果测试人员主要考虑区分变量，并找到最具代表性的一个时，我认为它是主要是域测试。
如果测试人员主要考虑创建一个复用测试集合的话，我认为它主要是回归测试。
如果是第一次设计的回归测试，那他们应该是有力的、可靠的等等。但是，在一个测试多次运行并通过之后，程序不可能在下一次测试时失败，除非发生了较大的变更或者部分代码变更直接参与了这个测试。因此，多数情况下，回归测试会产生很小的信息价值。
一个好的回归测试是为复用设计的。它是完全文档化的和可维护的。（建议：提高GUI级测试的可维护性，参见Graham & Fewster,1999;Kaner,1998; Pettichord,2002,以及www.perrichord.com上的论文）。
如果变更减少了程序进行回归测试在功能或范围上的错误，那么一个设计的好的回归测试可能会失败。
用户测试用户测试是由用户进行的，不是由伪装成用户的测试人员进行的，不是由秘书或者执行者伪装成测试人员、用户进行的。用户是使用最终产品的人。
用户测试是由用户或测试人员或其他人（有时甚至是顾客软件合同中接受测试的律师）设计的。用户测试的集合可能包括边界值测试、压力测试或任何其他类型的测试。
设计的有的用户测试是只由用户执行他们并报告程序是否通过这些测试的细节。如果你的目的是提供一个周密的、没有任何显示错误事件机会的系统脚本示例，那么这是设计测试的一个好方法。
如果你的目的是发现用户在系统实际使用中会遇到的问题，那么你的工作就比较难了。
Beta测试通常是简单的、有效的用户测试，但是实际上它们是非常难管理的，并且不会产生大量的信息。关于beta测试的一些建议，请参见Kaner,Falk & Nguyen（1993）.
一个好的用户测试，在给用户提供足够的结构来报告结果的有效性时，必须给用户的认知活动有足够的余地（在某种程度上有助于读者理解和解决问题）。
用户测试中发现的故障一般是可靠的和有目的的。少数用户会执行特别有力度的测试。但有些用户会把程序放到复杂的情形下运行。
场景测试一个场景就是描述了一个假设情况的故事。在测试上，检查程序如何在这种假设环境下复现。
理想的场景测试是可靠的、有目的的、易于评估的、复杂的。
实际上，许多场景在这些特性中的至少一个上是微弱无力的，但人们依然称之为场景。这种模式的关键信息是当你设计一个场景测试并试图完成它时，你需要紧记这4个特性。
场景测试的一个重要变异是粗糙测试。故事中经常会有一个仅由普通用户使用的序列或数据值。然而，他们会出现在用户错误之外，或异常但似是而非的情形下，或敌对的用户行为下。Hans Buwalda（2000a,2000b）称之为“肥皂杀手”以区别于称之为“肥皂剧”的正常情形。类似的情形在安全测试或其他形式的压力测试下是普遍存在的。
在RUP（Rational Unified Process）中，场景出自使用用例。（Jacobson,Booch, & Rumbaugh,1999）。场景制定了参与者、角色、事务处理、参与者的目标、以及在试图达到目的的过程中发生的事件。场景是使用用例的一个实例化。一个简单的场景追溯了一个独立使用用例的全过程，指定了数据值以及用例中的路径。一个比较复杂的使用用例会首尾串联若干个使用用例，来追踪给定的任务。（参见Bittner & Spence,2003; Cockburn,2000; Collard,1999; Constantine & Lockwood,1999; Wiegers,1999.）警告性注意，请参见Berger（2001）.
无论如何他们是继承来的，好的场景测试在第一次运行时具有很大的力度。
不同团队多久执行一个给定的场景测试。
有些团队创建一个类似回归测试的场景测试池。
其他团队（像我）一次或在很短时间内执行一个场景测试，然后设计另外一个场景而不是坚持使用一个以前用过的。
通常，测试人员生成的场景能洞察到产品内部。这在测试初期以及稍后的再一次测试中是非常真实的（当产品已经稳定，测试人员试图了解产品进一步的用途时。）
