以前实习做过1年测试，天天写Makefile pythan 脚本， 自动化测试工具配置， 最近几年都没有做测试，最近看到单位的测试文档，都有生疏之意，才有此文，加深记忆，很多内容从他处转载，不在标注。
根据项目流程阶段划分测试
上图是一个典型瀑布式软件开发流程，那么各项软件测试工作是在项目开发流程中循序渐进的进行的。下面将介绍个测试含义。
单元测试：单元测试是对软件中的基本组成单位进行的测试。目的是检验软件基本组成单位的正确性。
集成测试：集成测试是在软件系统集成过程中所进行的测试。目的是检查软件单位之间的接口是否正确。
系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。
验收测试：验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，向软件购买都展示该软件系统满足其用户的需求。
单元测试阶段：
模块接口测试
通过所测模块的数据流进行测试。调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配。
局部数据结构测试
局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确、模块的局部数据结构往往是错误的根源。
路径测试
对模块中重要的执行路径进行测试。
错误处理测试
比较完善的模块设计要求能遇见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。
边界条件测试
软件经常在便捷上失效，边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点。
集成测试阶段：
在集成测试中，我们主要关注以下内容：
1. 把各个模块连接起来时，穿越模块接口的数据据是否会丢失。
2. 各个了模块组合起来，能否达到预期要求的功能。
3. 一个模块的功能是否会对另一个模块的功能产生不利影响。
4. 全局数据据结构是否有问题。
5. 单个模块的误差积累起来是否会被放大，从而达到不可接受的程序。
系统测试阶段：
一般系统的主要测试工作都集中系统测试阶段。根据不同的系统，所进行的测试种类也很多。
功能测试：
功能测试是对产品的各功能进行验证，以检查是否满足需求的要求。
性能测试：
性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
安全测试：
安全测试检查系统对非法入侵的防范能力。
兼容测试：
兼容性测试主要是测试系统在不同的软硬件环境下是否能够正常的运行。
验收测试阶段：
功能确认测试
安全可靠性测试
易用性测试
可扩充性测试
兼容性测试
资源占用率测试
用户文档资料验收
白盒测试、黑盒测试、灰盒测试
上面是根据项目流程按照测试的各个阶段对测试工具的划分。白盒测试与黑盒测试，主要是测试工作对软件代码的的可见程度的划分。这也是我软件测试中领域中最基本的两个概念。
黑盒测试：
黑盒测试，指的是把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
白盒测试：
白盒测试，指的是把盒子盖子打开，去研究里面的源代码和程序结果。
它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作
灰盒测试：
灰盒测试介于黑盒测试与白盒测试之间。
可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
功能测试、性能测试
功能测试
功能测试检查实际的功能是否符合用户的需求。测试的大部分工作也是围绕软件的功能进行，设计软件的目的也就是满足客户对其功能的需求。如果偏离的这个目的任何测试工作都是没有意义的。
功能测试又可可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。
性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
软件的性能包括很多方面，主要有时间性能和空间性能两种。
时间性能：主要是指软件的一个具体的响应时间。比如一个登录所需要的时间，一个交易所需要的时间等。当然，抛开具体的测试环境，来分析一次事务的响应时间是没有任何意义的。需要搭建一个具体且独立的测试环境。
空间性能：主要指软件运行时所消耗的系统资源，比如硬件资源，CPU、内存，网络带宽消耗等。
手工测试与自动化测试
手工测试：
手工测试就是由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。
（其实，不太喜欢别人把一般的功能测试工作叫手工测试，就像一个雕塑家不喜欢别人叫他刻石头的一样。手工测试同样需要业务熟悉、基本测试方法的理解。看似简单的工作却能够发现别人不能发现的软件问题。在目前的测试领域，手工测试仍然是无法替代的一种测试方法）
自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
自动化测试：又可分为功能自动化测试与性能自动化测试。
我们一般所说的自动化测试就是指功能自动化测试，通过相关的测试技术，通过编码的方式用一段程序来测试一个软件的功能，这样就可以重复执行程序来进行重复的测试。如果一个软件一小部分发生改变，我们只要修改一部分代码，就可以重复的对整个软件进行功能测试。这样就大大的提高了测试效率。
性能自动化测试，当然，除了早期阶段，现在的性能测试工作都是通过性能测试工具辅助完成的。能过工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。
冒烟测试、回归测试、随机测试
这三种测试在软件功能测试过程中，既不算具体明确的测试阶段也不算是具体的测试方法。
冒烟测试：
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
引入到软件测试中，就是指测试小组在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件 的主要功能，如果主要功能都没有实现，则打回开发组重新开发。这样做的好处是可以节省大量的时间成本和人力成本。
回归测试：
回归测试是指修改了旧代码后，重新时行测试以确认修改后没有引入新的错误或导致其他代码产生错误。
回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到通过为止。
随机测试：
是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
随机测试可以发现一些隐蔽的错误，但是也有很多缺点，比如测试不系统，无法统计代码覆盖率和需求覆盖率，发现的问题难以重现。一般是放在测试的最后执行。其实随机测试更专业的升级版叫 探索性测试
探索性测试
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
探索性测试应该是未来测试领域的一个方向。
安全测试
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
安全测试也在越来越受到企业的关注和重视，因为由于安全性问题造成的后果是不可估量的。尤其对于互联网产品最容易遭受各种安全攻击。
展开性能测试说说：
性能测试常见分类
常会别人说到性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者一会叫压力测试，一会叫并发测试。这些概念除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。关于这个分类我翻阅了几个本比较好的书籍，他们讲的也比较模糊，没有给出本质上的区别。只是从不同角度和关 注点来解释。好吧我们先来看他们之间比较普遍的解释。
性能测试（狭义）
性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
特点：
1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。
也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。
负载测试
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。
特点：
1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。
也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。
压力测试（强度测试）
压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：
1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。
也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
特点：
1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
配置测试
配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。
也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
3、测试过程中需要关注系统的运行状况。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
上面的分类绝非全面，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。这个在极少数情况下进行，这里就不介绍了。
性能测试分类之我见
上面的类分完了，似乎得到不少专家的认同，并无不妥。但我们在性能测试过程中真的能把它们区别分的很清楚么?你能严格区分出你这次的测试到底并发测试还是压力测试。
笔者第一点不太赞同的是对“性能测试”的定义。笔者认为性能测式测试包含了上面的所有分类。而这种性能测试的定义只是一种狭义上的“性能测试”，属于性能测试的一种。
性能测试是相对功能测试来说的。他们之间最本质的区别就是对系统有处理能力是否够成压力。如果一个用户的一个操作（比如超大数据量的查询）对系统够成了压力，我也可以视其为性能测试。
其实，可以这样来划分性能测试
上面定交了那么多分类，是不是有点晕了。其实，以笔者认为我们进行性能测试时关注的就两点。耐力和爆发力。
初高中时练过几年体育，最好时代表学校参加县体育比赛，不过是去垫底的。哈哈！哈一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面。一是爆发力。二是耐力。
爆发力：拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。关键是看你能举起一个什么样的重量。
耐力：拿一个马拉松运动员来说，你百米速度跑得再快没用。关键是这40公里路程中，最先跑到终点的人才是赢家。
整体协调性：当然，身为一个教练员，我在选拔选手的时候，除了看这个运动员的耐力和爆发力，身体的整体协调性也是我考核的一个很重要的指标。比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。他的跑步成绩虽然不错。但他在跑的过程中，身体有各个部分都在分担右臂的不足。右臂影响了整个体能的发挥。
再到系统的性能上说，爆发力就是这个系统能承受的最大压力，没准这个系统承受的压力很大。但过半个小时之间就挂掉了。耐力就是这个每系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。那么整体协调性就是看系统有没系统瓶颈，需不需要进行系统调优。
在做性能测试时请忘掉分类
这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢？是并发性测呢？还是压力测试？
我们还拿上面的教练员选拔选手做例子。
记得我进校体队的时候，教练说让我跑两圈。然后，我就开始围绕着操场跑起来。你说教练让我跑两圈是想看我的什么能力？
1、双腿的考核，一个是步幅，就是步与步之间的距离。一个是频率，两腿交替的频率。如果你一步拉得很大的话，那么频率一定会下降。如果想提高频率的话，那么一定会影响到步幅的大小。
2、双臂的考核，肩膀是否放松，摆臂是否有力，双臂的摆动与双腿的摆动是否协调。
3、呼吸是否匀称，目前的速度可以跑几圈。
我只做了一项体育运行，就考核了我这么多内容。我们在做一个性能测试时也不局限在某一分类上，也可能我们的一个测试包含多个分类。
《web性能测试实战》：
那么类型的性能测试看起来很吓人，实际上它他们大多是密切相关的。例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。
另外工具随便说说吧，我知道的本单位性能测试工具用LR，单元测试工具junit ，代码管理工具用cc ， 安全用ctrix，自动化测试还不是特别普及（小小的鄙视一下，嘿嘿），记得4年以前工作的互联网企业自动化工具都很完善了， 工具只是工具而已，就不多说了，用什么都无所谓。。。
无意中还看过几篇关于本单位新一代基于SOA架构核心系统的测试文档，由于SOA架构的特殊性，对于测试提出了更高的要求，很有意思，有机会会写一下。
2014.1.25 晚 WuHan