功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

Functional testing（功能测试），也称为behavioral testing（行为测试），根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。

功能测试也叫黑盒测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。

应用电子技术方面的测试：

印刷电路板，又称印制电路板，印刷线路板，常使用英文缩写PCB（Printed circuit board），是重要的电子部件，是电子元件的支撑体，是电子元器件线路连接的提供者。由于它是采用电子印刷技术制作的，故被称为“印刷”电路板。

在印制电路板出现之前，电子元件之间的互连都是依靠电线直接连接而组成完整的线路。电路面包板只是作为有效的实验工具而存在，而印刷电路板在电子工业中已经成了占据了绝对统治的地位。

20世纪初，人们为了简化电子机器的制作，减少电子零件间的配线，降低制作成本等优点，于是开始钻研以印刷的方式取代配线的方法。三十年间，不断有工程师提出在绝缘的基板上加以金属导体作配线。而最成功的是1925年，美国的Charles Ducas 在绝缘的基板上印刷出线路图案，再以电镀的方式，成功建立导体作配线。[1]

直至1936年，奥地利人保罗·爱斯勒（Paul Eisler）在英国发表了箔膜技术，他在一个收音机装置内采用了印刷电路板；而在日本，宫本喜之助以喷附配线法“メタリコン法吹着配线方法（特许119384号）”成功申请专利。而两者中Paul Eisler 的方法与现今的印刷电路板最为相似，这类做法称为减去法，是把不需要的金属除去；而Charles Ducas、宫本喜之助的做法是只加上所需的配线，称为加成法。虽然如此，但因为当时的电子零件发热量大，两者的基板也难以配合使用[1]，以致未有正式的实用作，不过也使印刷电路技术更进一步。

1941年，美国在滑石上漆上铜膏作配线，以制作近接信管。

1943年，美国人将该技术大量使用于军用收音机内。

1947年，环氧树脂开始用作制造基板。同时NBS开始研究以印刷电路技术形成线圈、电容器、电阻器等制造技术。

1948年，美国正式认可这个发明用于商业用途。

自20世纪50年代起，发热量较低的晶体管大量取代了真空管的地位，印刷电路版技术才开始被广泛采用。而当时以蚀刻箔膜技术为主流[1]。

1950年，日本使用玻璃基板上以银漆作配线；和以酚醛树脂制的纸质酚醛基板（CCL）上以铜箔作配线。[1]

1951年，聚酰亚胺的出现，便树脂的耐热性再进一步，也制造了聚亚酰胺基板。[1]

1953年，Motorola开发出电镀贯穿孔法的双面板。这方法也应用到后期的多层电路板上。[1]

印刷电路板广泛被使用10年后的60年代，其技术也日益成熟。而自从Motorola的双面板面世，多层印刷电路板开始出现，使配线与基板面积之比更为提高。

1960年，V. Dahlgreen以印有电路的金属箔膜贴在热可塑性的塑胶中，造出软性印刷电路板。[1]

1961年，美国的Hazeltine Corporation参考了电镀贯穿孔法，制作出多层板。[1]

1967年，发表了增层法之一的“Plated-up technology”。[1][3]

1969年，FD-R以聚酰亚胺制造了软性印刷电路板。[1]

1979年，Pactel发表了增层法之一的“Pactel法”。[1]

1984年，NTT开发了薄膜回路的“Copper Polyimide法”。[1]

1988年，西门子公司开发了Microwiring Substrate的增层印刷电路板。[1]

1990年，IBM开发了“表面增层线路”（Surface Laminar Circuit，SLC）的增层印刷电路板。[1]

1995年，松下电器开发了ALⅣH的增层印刷电路板。[1]

1996年，东芝开发了B2it的增层印刷电路板。[1]

就在众多的增层印刷电路板方案被提出的1990年代末期，增层印刷电路板也正式大量地被实用化。

为大型、高密度的印刷电路板装配（PCBA,printed circuit board assembly）发展一个稳健的测试策略是重要的，以保证与设计的符合与功能。除了这些复杂装配的建立与测试之外，单单投入在电子零件中的金钱可能是很高的 - 当一个单元到最后测试时可能达到25,000美元。由于这样的高成本，查找与修理装配的问题是重要的步骤。今天更复杂的装配大约18平方英寸，18层；在顶面和底面有2900多个元件；含有6000个电路节点；有超过20000个焊接点需要测试。

在朗讯加速的制造工厂（N. Andover,MA），制造和测试艺术级的PCBA和完整的传送系统。超过5000节点数的装配对我们是一个关注，因为它们已经接近我们现有的在线测试（ICT,in circuit test）设备的资源极限（图一）。我们制造大约800种不同的PCBA或“节点”。在这800种节点中，大约20种在5000~6000个节点范围。可是，这个数迅速增长。

新的开发项目要求更加复杂、要有更大的PCBA和更紧密的包装。这些要求挑战我们建造和测试这些单元的能力。更进一步，具有更小元件和更高节点数的更大电路板可能将会继续。例如，正在画电路板图的一个设计，有大约116000个节点、超过5100个元件和超过37800个要求测试或确认的焊接点。这个单元还有BGA在顶面与底面，BGA是紧接着的。使用传统的针床测试这个尺寸和复杂性的板，ICT一种方法是不可能的。

在制造工艺，特别是在测试中，不断增加的PCBA复杂性和密度不是一个新的问题。意识到的增加ICT测试夹具内的测试针数量不是要走的方向，我们开始观察可代替的电路确认方法。看到每百万探针不接触的数量，我们发现在5000个节点时，许多发现的错误（少于31）可能是由于探针接触问题而不是实际制造的缺陷（表一）。因此，我们着手将测试针的数量减少，而不是上升。尽管如此，我们制造工艺的品质还是评估到整个PCBA。我们决定使用传统的ICT与X射线分层法相结合是一个可行的解决方案。

黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

比如黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

黑盒测试试图发现以下类型的错误：

（1）功能错误或遗漏

（2）界面错误

（3）数据结构或外部数据库访问错误

（4）性能错误

（5）初始化和终止错误

（1）等价类划分方法

（2）边界值分析方法

（3）错误推测方法

（4）因果图方法

（5）判定表驱动分析方法

（6）正交实验设计方法

（7）功能图分析方法

等价类划分

是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的，常用的黑盒测试用例设计方法。

划分等价类

等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。

有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效等价类的定义恰巧相反。

设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。

方法

下面给出六条确定等价类的原则。

①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

设计用例

在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

输入条件 有效等价类无效等价类

... ... ...

... ... ...

然后从划分出的等价类中按以下三个原则设计测试用例：

①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步.直到所有的有效等价类都被覆盖为止.

③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

边界值分析方法是对等价类划分方法的补充.

⑴边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.

使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.

⑵基于边界值分析方法选择测试用例的原则：

1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据.

2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据.

3）根据规格说明的每个输出条件，使用前面的原则1）.

4）根据规格说明的每个输出条件，应用前面的原则2）.

5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例.

6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例.

7）分析规格说明，找出其它可能的边界条件.

错误推测法

错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.

错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结. 还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等. 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤：

⑴ 分析软件规格说明描述中，那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符.

⑵ 分析软件规格说明描述中的语义.找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图.

⑶ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件.

⑷ 把因果图转换为判定表.

⑸ 把判定表的每一列拿出来作为依据，设计测试用例.

从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

判定表

通常由四个部分组成

条件桩（Condition Stub）：列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值.

动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作.

规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列.

建立步骤

（根据软件规格说明）

①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1），故有5种规则：

②列出所有的条件桩和动作桩。

③填入条件项。

④填入动作项.等到初始判定表。

⑤简化.合并相似规则（相同动作）。

B. Beizer 指出了适合使用判定表设计测试用例的条件：

①规格说明以判定表形式给出，或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响执行哪些操作。

④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

⒈ 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了

⒉ 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

⒈ 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

⒉ 没有状态转换的概念，一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

⒊ 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

WinRunner的特点在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试； 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差； 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用； 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。