测试类型和测试质量
在黑盒测试的领域中，Kanner&Bach(参考Bach 2003b和Kanner,2002发布在www.testingeducation.org上的课程笔记，以及Kanner,Bach & Pettichord, 2002)描述了11种有优势的黑盒测试：
●功能测试
●域测试
●基于规范的测试
●基于风险的测试
●压力测试
●回归测试
●用户测试
●场景测试
●基于状态模型的测试
●大批量的自动测试
●探索性测试
我和Bach收集了一些测试“范例”进行反复领会，其中的一两个统治了测试组团队或天才测试者的思想。经过分析，我们发现有趣的是：
如果我是一个“场景测试者”(主要根据场景测试的应用定义测试的人)，我该如何实际地测这个程序?什么能使场景测试一个比一个好?我会遗漏哪类问题，对我来说难于发现或解释什么，什么又特别简单?
在这里，用一些怎样的测试用例才算是“好的”的思想，来简单的说明一下这些类型。 软件测试
功能测试
独立测试每个功能、性能、变量。
很多测试团队都从非常简单的功能测试开始，再转换到另外一个，通常有若干功能之间的互相交叉，直到程序通过主要功能的测试。
依照这种方法，好的测试应聚焦于单一的功能，并用中庸的值来测它。我们不希望程序败于这样的测试，但还是会败于有根本性错误的算法、失败构建、或对程序其他部分有牵制力的变更。
这些测试具有很高的可靠性，并易于评价，但明显没有力度。
有些测试团队会把大多数时间花费在功能测试上。对他们来说，当每一项都独立彻底地测试过时，测试就完成了。依我的经验，有力度的功能测试类似于域测试，有他们的实力。
域测试
这种测试的本质是取样。我们把集合划分(区分)成子集合(子域)，把一个大的可能进行测试的集合分解成一个小组，并从子集合中选出有代表性的一两个的方法。
在域测试中，我们关注变量、偶尔是变量的初始值。
为了测一个给定的变量，测试集把所有你能想象到的值(包括无效值)都赋给这个变量。把这个集合划分成子域，在每个子域中至少进行一个典型测试。一般地，你进行了一个最具代表性的测试，也就是说，你用了一个至少像同类其他元素一样可能暴露错误的值。如果这个变量能达到数据边界，那么最具代表性的就是典型的边界值。
大多数域测试的讨论都是关于输入变量值能否达到数据边界线的讨论。这些用例区间中最具代表性的是典型的边界用例。
对于数字变量，一个好的域测试用例集合会检测每个边界值，包括最小值、最大值、一个小于最小值的值、以及一个大于最大值的值。
Whittaker(2003)提出了一个在软件分析时关于许多不同类型变量的深入讨论，包括输入变量、输出变量、中间计算结果、文件系统中存储的值、以及发送到设备或其他程序的数据。
Kaner,Falk & Nguyen(1993)提出了关于变量(配置测试打印机类型)不能达到数据边界的测试的详细分析。
这些测试比不具代表性的或忽略某些子域(比如，人们经常忽视期望产生错误信息的测试用例)的测试更有力。
第一次运行这些测试用例，或重大相关变更之后，这些测试会产生很多有价值的信息，因为边界/极限值错误是普遍发生的。
有时，会忽视这些测试发现的BUG，尤其是当你同时测试若干变量的极限值时。(这些测试叫做拐角用例。)他们不需要是可靠的，不需要代表用户期望的，因此，他们也没必要是为解决问题而设的。
文章来源于领测软件测试网 https://www.ltesting.net/
