前天刚被Oracle电话ＢＳ一顿，今天又迅速的被ＢＳ了，可能是手机的问题，一直听不清对方的话，很多问题我都让她重复了几遍，估计她也要抓狂了。

先说下今天电话面试的大体内容吧：

１）先了解下我大概去实习的具体时间；

２）对我的实习经历很感兴趣，让我说下实习所做的具体工作，这也是我悲剧的地方，因为没听清她所问的问题，也就自己揣磨了她的意思，然后自己一个人balalbala的说起来了，说到中途时，她打断我了，然后直接换了个方式问我，又是一串的balabala。。。在这里要说下，如果没懂对方的意思，一定要果断再问，直到问清！不要怕问！（我就是觉得问得太多了，不好意思。。。）

3）研发和测试的看法。。（这个感觉自己答的还过得去）；

4）问我有没有什么问题问她，想了片刻，觉得现在如果直接问待遇的话不是很好，所以就问了下公司现在的项目，用什么语言，然后进一步探讨了下python和perl哪个更有前景。（木有营养的问题）最后，要我等最后的通知。（如果要挂，我觉得就是自己没听清问题，自己就开始balabala的说，有点抢风头的感觉！！！）

在此，顺便把前天的面试的情况也大致说下：

１）面试之初，先下我做个英文的自我介绍，准备了一个下午啊，英语虽渣，但一个下午的准备还是没什么问题的；

２）就我个人项目问题进行了深入的了解；

３）Linux的常用命令；

４）ＴＣＰ／ＩＰ最经典的问题：三次握手；

５）实习的经历；

在此越发觉得实习经历一定要完全熟悉记得，所以把实习相关的重要知识点在此做个总结：

一、墨盒测试：

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

编辑本段作用

黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

功能不正确或遗漏；

界面错误；

输入和输出错误；

数据库访问错误；

性能错误；

初始化和终止错误等。

编辑本段测试方法

概述

从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。

等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。

划分等价类

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

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

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

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

划分等价类准则

2）划分等价类的方法：下面给出六条确定等价类的原则.

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

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

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

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

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

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

3）设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

输入条件

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

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

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

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

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

边界值分析

边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充.

（1）边界值分析方法的考虑：

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

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

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

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

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

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

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

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

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

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

错误推测法

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

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

因果图法

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

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

因果图生成测试用例

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

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

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

(4) 把因果图转换为判定表.

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

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

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

判定表组成

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

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

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

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

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

判定表的建立步骤

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

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

③填入条件项.

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

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

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

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

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

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

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

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

参考资料：http://baike.baidu.com/view/51274.htm

二、白盒测试；

白盒测试（white-box testing）又称透明盒测试（glass box testing）、结构测试（structural testing）等，软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑盒测试）。在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。测试者了解待测试程序的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。

白盒测试可以应用于单元测试（unit testing）、集成测试（integration testing）和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。

参考资料：http://zh.wikipedia.org/wiki/%E7%99%BD%E7%9B%92%E6%B5%8B%E8%AF%95

三、单元测试；

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

简介

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

编辑本段详解

cppunit进行单元测试

  cppunit进行单元测试

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。

其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。我认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈我的看法。

一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以我的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。

有一种看法是，只测试类的接口（公有函数），不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写（inline函数），所有在源文件编写实现的函数都要进行测试（构造函数和析构函数除外）。

编辑本段使用效果

我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

幸运的是，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。

关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

一些流行的误解

在明确了什么是单元测试以后，我们可以进行"反调论证"了。在下面的章节里，我们列出了一些反对单元测试的普遍的论点。然后用充分的理由来证明这些论点是不足取的。

它浪费了太多的时间

一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。

在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。

在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。

它仅仅是证明这些代码做了什么

这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住（希望能够）罕见的编译器Bug，但是他们能够做的仅仅是这些。

如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。

在实践中会出现这样的情况：一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是发现编译器的Bug？第一步是理解这个单元原本要做什么， --- 不是它实际上做了什么。比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释， 主要针对这个单元， 及调用它和被它调用的相关代码。画出流程图是非常有帮助的，你可以用手工或使用某种工具。可以组织对这个概要规格说明的走读（Review)，以确保对这个单元的说明没有基本的错误， 有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。

我是个很棒的程序员， 我是不是可以不进行单元测试？

在每个开发组织中都至少有一个这样的开发人员，他非常擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进行测试。你是否经常听到这样的借口？

在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。

编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应， 并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？ 这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。

不管怎样， 集成测试将会抓住所有的Bug

我们已经在前面的讨论中从一个侧面对这个问题进行了部分的阐述。这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。如果软件的单元没有事先进行测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。

一旦软件可以运行了，开发人员又要面对这样的问题：在考虑软件全局复杂性的前提下对每个单元进行全面的测试。这是一件非常困难的事情，甚至在创造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。在软件集成阶段，对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。

最后的结果是测试将无法达到它所应该有的全面性。一些缺陷将被遗漏，并且很多Bug将被忽略过去。

让我们类比一下，假设我们要清洗一台已经完全装配好的食物加工机器！无论你喷了多少水和清洁剂，一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想办法。但我们换个角度想想，如果这台机器是拆开的， 这些死角也许就不存在或者更容易接触到了，并且每一部分都可以毫不费力的进行清洗。

成本效率不高

一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。这种后果可能常常会被软件的开发人员所忽视（但是用户可不会这样），这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉，并且会导致对未来的市场产生负面的影响。相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。

很多研究成果表明，无论什么时候作出修改都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。在修改费用变的过高之前，单元测试是一个在早期抓住Bug的机会。

相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。从全程的费用来考虑， 相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。

参考资料：http://baike.baidu.com/view/106237.htm

四、功能测试：

定义

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

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

应用

以上是属于程序软件类的测试，下面介绍应用电子技术方面的测试

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

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

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

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