本特辑将会提及各种测试角度，在这里我们先从这些角度出发对测试进行整理和分类。
根据开发阶段分类
根据开发的阶段或测试对象的粒度，测试可以作如下分类。
• 单元测试
• 集成测试
• 验收测试
单元测试是指针对模块等最小单元进行的测试。
集成测试是指在存在多个模块或组件、应用程序或服务的情况下进行的测试。像模块集成测试与组件集成测试这样，要通过明确集成对象来显示系统的粒度E。集成测试一般由开发小组实施。
验收测试并不是由开发小组执行的测试，而是由接受产品的公司或组织来测试。测试对象的规模与系统级别的集成测试相当，但在整个开发过程中，验收测试和集成测试实施的阶段并不同。
在本特辑中，第2 章、第3 章、第5 章将专注于集成测试的介绍，而在第4 章中，单元测试和集成测试都会重点介绍。
－－－D https://build.phonegap.com/E 有时候根据测试对象的集成程度使用的名词也会不同，如果比较小的时候被称作集成测试、较大的集成度被称为系统测试。
根据测试的执行方式分类
按照其执行的方法，测试可以作如下分类。
• 手动测试
• 自动测试
• 半自动测试
自动测试是无需人工干预，通过程序自动运行的测试。与之相对，手动测试就是人通过自己的手和眼睛通一边操作应用程序，一边执行的测试。
在这里还有一个概念，那就是介于自动测试和手动测试之间的执行状态——半自动测试。具体来说，就是测试是通过程序自动执行的，而测试的结果则是手动检查的。反之，手动执行测试，自动确认结果的测试方法也归类为半自动测试。
在本特辑中，整体将以自动测试为主，当然也会接触一些半自动测试和手动测试的内容。在下文中，我们将介绍自动测试和手动测试的特征。关于半自动测试将在第2 章中介绍。
自动测试的特征
自动测试中，一次性编写测试代码后可以多次自动执行，因此在需要反复执行测试的时候就能够看到它的威力了。
然而，由于需要编写测试代码，会增加初期开发成本，在应对需求变更的时候也需要花费相应的成本。因此，如果只是执行一次的测试或是在需求变化频繁的阶段，自动化测试的效率很低，并不是最好的选择。尤其是在UI 自动化测试的时候，比起非UI 测试，编写代码的难度更大、付出的成本也更高。
如果要执行的测试依赖于和设备关联的物理条件，例如通过全球定位系统（GPS）获取的位置信息等，那么该测试的自动化可能会变得很困难甚至无法实现。有些时候也会出现很难验证测试结果有效性的情况。例如，为了自动确认页面显示和布局，需要进行屏幕截图等工作，但对于视频和动画等动态的输出结果，想要确认的话在技术上是非常困难的。
手动测试的特征
因为不需要开发测试代码，所以在手动测试中需要专注的是测试用例的设计、执行以及资源计划。如果需要重复执行测试，那么就需要耗费与执行次数成正比的时间和人力资源，因此测试执行的效率很低。
在测试执行速度和同质化方面，手动测试多依赖于测试执行者的专业知识和技能熟练程度，测试的结果容易出现偏差。
在确认测试结果的时候，页面输出的手动确认灵活性较高，可以应对所有测试用例。然而，用眼睛确认时，只能大概地确认页面的显示结果，如果要精确到每个像素的正确性就十分困难了。这个问题在确认视频和动画的测试结果时也同样存在。
根据测试的目的分类
从测试目的或质量的角度来看，测试可以作如下分类。
• 功能测试
• 性能测试
• 安全性测试
功能测试是验证应用程序是否满足功能需求的测试；性能测试是检查能否实现预期性能的测试；安全性测试是为了确认安全性需求和漏洞的测试。总之，测试可以按照执行测试是为了达成什么目的来进行分类。这样的话，测试可以分成很多类，前面列出来的三种只是众多分类中的一部分。
在本特辑中，我们将通过一个实例介绍功能测试。
根据测试技术分类
测试技术指的就是如何创建测试用例，从这个角度来看，测试可以作如下分类。
• 白盒测试
• 黑盒测试
• 灰盒测试
白盒测试着眼于测试对象的内部结构来创建测试用例。例如，验证程序处理的执行顺序是否正确，或是测试程序内部某个值的变化。黑盒测试着眼于测试对象的规格来创建测试用例。测试时并不在意测试对象内部执行了哪些处理，而是测试程序在输入了特定的内容后能否得到正确的结果。
顾名思义，灰盒测试介于上面两者之间，创建设计用例时既着眼于程序功能，也关注内部结构。例如，灰盒测试可以从黑盒测试的角度创建测试用例，也可以从白盒测试的角度编写测试代码。这种情况下，可以通过测试代码掌握程序的内部结构并加以利用，因此就能在黑盒测试中创建某些重现困难的特定条件来执行测试。
本特辑将重点关注黑盒测试和灰盒测试，不过在第4 章中也会接触到一些白盒测试的内容。
