一、什么是软件测试？
软甲测试就是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求，软件测试就是在软件投入运行前，对软件进行需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
软件测试是为了发现错误而执行程序的过程
二、软甲测试分类
三、按测试阶段划分
1）单元测试
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元
的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元
指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的
被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在
与程序的其他部分相隔离的情况下进行测试。
2）集成测试
集成测试的含义非常简单- 将单元测试模块逐个集成/组合，并将行为测试为组合单元。
该测试的主要功能或目标是测试单元/模块之间的接口。
我们通常在“单元测试”之后进行集成测试。一旦创建并测试了所有单个单元，我们就开始组合这些“单元测试”模块并开始进行集成测试。
该测试的主要功能或目标是测试单元/模块之间的接口。
首先单独测试各个模块。模块经过单元测试后，逐个集成，直到所有模块都集成在一起，检查组合行为，验证需求是否正确实现。
在这里我们应该理解，集成测试不会在周期结束时发生，而是与开发同时进行。因此，在大多数情
况下，所有模块实际上都无法测试，这就是测试不存在的东西的挑战！
3）系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时
间大部分在系统测试执行阶段，包括回归测试和冒烟测试。将经过测试的子系统装配成一个完整系
统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个
系统的运行以及与其他软件的兼容性。
4）验收测试
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件
购买者展示该软件系统满足原始需求。
四、按是否覆盖源代码
1）黑盒测试
黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试
方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放
在发现程序不按其规范正确运行的条件。
2）白盒测试
白盒测试（white-box Testing，又称逻辑驱动测试，结构测试），它是知道产品内部过程，可通过
测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检
验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻
辑驱动，基路测试等，主要用于软件验证。
3）灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
五、按是否运行
1）静态测试（static testing）
静态测试就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
包括对代码测试、界面测试和文档测试三个方面：
对于代码测试，主要测试代码是否符合相应的标准和规范。
对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试，主要测试用户手册和需求说明是否符合用户的实际需求。
2）动态测试（dynamic testing）
动态测试就是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。
黑盒测试有可能是动态测试（运行程序，看输入输出）, 也有可能是静态测试（不运行,只看界面）
白盒测试有可能是动态测试（运行程序并分析代码结构）, 也有可能是静态测试（不运行程序 , 只静态察看代码）
动态测试有可能是黑盒测试（运行 , 只看输入输出）, 也有可能是白盒测试 （运行并分析代码结构）
静态测试有可能是黑盒测试（不运行，只察看界面）, 也有可能是白盒测试（不运行 , 只察看代码）
六、按是否自动化
1）人工测试
人工测试能通过人为的逻辑判断效验当前的步骤是否正确，同时用例的执行具有一定步骤跳跃性，能够清楚知道逻辑，细致定位问题。
如果修改bug所需时间稍长，那么想将人工测试应用于回归测试将变得异常困难。这是因为需要测试的测试用例太多，所以需要引入自动化测试。
2）自动化测试
执行的对象是脚本，能通过人为的逻辑判断效验当前的步骤是否正确实现，用例步骤之间关联性强，不像手工测试用例那么跳跃。另外也是用来保证产品主体功能正确和完整，让测试人员从繁重的工作中解脱出来。
可以更好的利用资源。在夜间执行自动测试用例。测试具有移植性和可重复性。好的测试脚本往往具有较好的平台移植性。可以更快地将软件推向市场。因为自动测试节省了大量的时间。但是自动化测试要求的先期投入比较大，而且要求人员必须经过严格的培训。
七、更多
1）冒烟测试
冒烟测试，是对软件的基本功能进行测试，测试对象是每一个新编译的需要正式测试的软件版本，
目的是确认软件的基本功能正常，保证软件系统能正常跑起来，可以进行后续的正常测试工作的进
行，如果最基本的测试都有问题了，就直接打回开发部了，所以正式交付的测试版本，必须先通过
冒烟测试的考验
2）回归测试
回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，对软件的任何新
版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再现，并确认曾经通
过的功能不会出现问题。
3）随机测试
随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过
程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有
覆盖到的部分。在测试中，测试数据是随机产生的。
4）探索测试
探索式测试（Exploratory Testing）是一种自由的软件测试风格，强调测试人员同时展开测试学
习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。
测试专家Cem Kaner博士在1983年提出的。
测试需要探索，而探索需要大量的思考。积极思考的探索式测试是具有挑战性的智力过程，常常需
要在不确定的顺序反复实施钻研、尝试、迂回、调整、评估等活动。好的探索式测试不会使测试更
简单，但是它会使测试更有效，从而在测试速度和缺陷发现上获得更多的汇报。
工作流程
