根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。
功能测试又称为黑盒测试，是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
黑盒测试试图发现以下类型的错误：
（1）功能错误或遗漏
（2）界面错误
（3）数据结构或外部数据库访问错误
（4）性能错误
（5）初始化和终止错误
用例设计方法
（1）等价类划分方法
（2）边界值分析方法
（3）错误推测方法
（4）因果图方法
（5）判定表驱动分析方法
（6）正交实验设计方法
（7）功能图分析方法
2、性能测试：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的较大服务级别的测试。
性能测试目的：验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
包括以下几个方面
1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2．识别体系中的弱点：受控的负荷可以被增加到一个较端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的一方法。
性能测试类型包括：负载测试（指标变化），压力测试（性能点），强度测试，容量测试，基准测试，渗入测试，峰谷测试
性能测试概括为三个方面：
应用在客户端性能的测试：负载测试和压力测试应用在网络上性能的测试：应用在服务器端性能的测试： Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；Successful Rounds：成功的请求；Failed Rounds ：失败的请求；Successful Hits ：成功的点击次数；Failed Hits ：失败的点击次数；Hits Per Second ：每秒点击次数；Successful Hits Per Second ：每秒成功的点击次数；Failed Hits Per Second ：每秒失败的点击次数；Attempted Connections ：尝试链接数；我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：
c/s
client/Server 客户端/服务器架构
基于客户端/服务器的三层架构
基于客户端/服务器的分布式架构
b/s
基于浏览器/Web服务器的三层架构
基于中间件应用服务器的三层架构l
基于Web服务器和中间件的多层架构l
由于工程和项目的不同，所选用的度量，评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。
步骤如下：
1． 制定目标和分析系统
2． 选择测试度量的方法
3． 学习的相关技术和工具
4． 制定评估标准
5． 设计测试用例
6． 运行测试用例
7． 分析测试结果
具体：通过量、响应时间、CPU负载、内存使用
工具：QALoad、LoadRunner、Bench ** rk Factory、Webstress
过程：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置性能测试图像，性能测试图像与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。
原则：
1）情况许可时，应使用几种测试工具或手段分别独立进行测试，并将结果相互印证，避**一工具或测试手段自身缺陷影响结果的准确性；
2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；
3）查找瓶颈的过程应由易到难逐步排查：
服务器硬件瓶颈及网络瓶颈（局域网环境下可以不考虑网络因素）
应用服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置）
应用业务瓶颈（SQL语句、数据库设计、业务逻辑、算法、数据等）
4）性能调优过程中不宜对系统的各种参数进行随意的改动，应该以用户配置手册中相关参数设置为基础，逐步根据实际现场环境进行优化，一次只对某个领域进行性能调优（例如对CPU的使用情况进行分析），并且每次只改动一个设置，避免相关因素互相干扰；
5）调优过程中应仔细进行记录，保留每一步的操作内容及结果，以便比较分析；
6）性能调优是一个经验性的工作，需要多思考、分析、交流和积累；
7）了解“有限的资源，无限的需求”；
8）尽可能在开始前明确调优工作的终止标准。
自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
前提条件
实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
1) 需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
2) 项目周期足够长
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
3) 自动化测试脚本可重复使用
如果费尽心思开发了一套近乎**的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。
另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。
适用场合
通常适合于软件测试自动化的场合：
(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。
工具介绍：
QTP：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。（回归测试）
WinRunner：企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作。
QA Run：通过鼠标移动、键盘点击操作被测应用，继而得到相应的测试脚本，对该脚本可以进行编辑和调试。
AutoRunner：功能测试、回归测试。
手机自动化测试：Monkey，Monkeyrunner，Appium（常用）
过程
自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。
1) 自动化测试需求分析。
当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。
2)自动化测试框架的搭建。
所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。
而根据自动化测试用例，我们很*能够定位出自动化测试框架的典型要素：
a. 公用的对象。
不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而*修改所有相关的测试脚本。
b. 公用的环境。
各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
c. 公用的方法。
当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。
d. 测试数据。
也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。
在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。
性能和自动化的区别常常有刚接触自动化和性能测试的同学问我，感觉性能测试和自动化测试是差不多的，我自己刚接触的时候认为也是差不多的，区别就是：自动化一个用户再跑，性能测试需要并发，需要设计各种场景。慢慢的做的多了，发现两者区别还是挺大的。
共同点：
接口的自动化测试和性能测试在处理脚本的方式上差不多，特别是使用JMeter、LR 这些工具测试的时候，例如测http协议的请求，只需模拟发送get或post方式的请求，接口脚本很*转成性能测试脚本。但对于Web应用来说，自动化测试和接口测试就大相径庭了。
下面说下具体的差异吧。
差异：
1、测试角度不同
自动化测试和性能测试的出发点不一样，也就是较终的目的不一样。自动化测试是基于功能测试，案例也是来自功能测试，通常用做回归测试，其实测的是业务，是功能。
性能测试考虑单个接口的性能，有时候不会太考虑整体的业务通不通，只需考虑需要压测接口的性能表现，比如处理的tps、平均响应时间、支持的并发用户数。当然性能测试也会关注整个流程的测试。
比如有个做性能测试的小伙伴去做接口测试，就某一个产品的下单操作来说，做接口测试是为了查看下单这个功能是不是正常，他写的接口测试脚本跟性能测试脚本一样，只有一个下单的接口，下单之**些商品的查询，账户的查询都没有做，这在业务上是不连贯的。
2、使用框架不同
如果说接口的自动化测试和性能测试在脚本处理上有些相同，就Web测试来说，二者就大相径庭了。首先使用的框架就不一样，Web自动化测试使用的是Selenium Webdriver，模拟的是点击页面的元素，性能测试还是录脚本、发请求。一个主要是关注页面元素，后端做了些什么完全是黑盒；一个需要关注发的请求有哪些，是post还是get，传的参数是什么，后端的一些知识还是要了解下，有点像灰盒。
3、要掌握的技能不同
自动化测试偏重开发，对开发语言要求相对高些，如果只是配置现成的框架做自动化测试，那要求并不高。性能测试要了解的知识很多，脚本语言（C或者java等等）、操作系统（Linux，常用的监控命令，出问题时分析线程）、数据库（查询语句、表的关联、索引、Oracle的AWR 报表）；如果是高级的性能测试，那还要懂架构方面的知识。
总的来说，自动化测试偏向于开发，但要有测试的思维；性能测试要懂的知识点很多，真正高级的性能测试也跟开发架构师的水平差不多了。
中山立讯检测有限公司专注于汽车零部件检测,零部件可靠性测试,无损检测,汽车零部件可靠性测试,立讯检测等