1.项目型软件（Project Type）
项 目型软件是指本软件是针对专门的客户进行定制开发，软件需求由客户（甲方）指定和确认，软件版权和源代码，文档等归甲方所有，只针对甲方收费，软件的研发 和验收只为甲方负责。比如蜗牛创想为成都乐圈科技，雅安无线电管理中心等企业客户定制开发的软件均称为项目型软件。项目型软件有明确的研发周期，客户验收 通过并付费后即表明本项目结束，所以项目的研发风险相对较低，当然，另外一方面其利润空间也相对不高。
2.产品型软件（Product Type）
产 品型软件是指本软件是针对大众需求进行研发，软件需求通常最开始由研发团队或运营团队根据市场可能的需求进行构思和设计，客户群体也是由市场团队或研发团 队进行市场定位后确定。产品在没有正式上市运营之前无法收费，产品上市后继续根据用户的反馈进行产品改进和优化。产品可以选择收费或免费策略。目前我们看 到的手机APP，游戏，QQ，微信，杀毒软件，办公软件，操作系统等等各类可下载的软件产品均属于产品型软件。产品型软件没有明确的周期可言，只要市场有 需求，可以无限制地一直改进下去。比如我们看到的Windows操作系统，QQ或微信，美图秀秀之类的软件产品，并没有固定的周期，一直在更新和完善功 能，以保持产品的用户数和市场竞争力。
3.单元测试 (Unit-Testing)
软件测试的早期阶段，主要专注于代码逻辑的实现，测试对象为单独的API（方法），其测试目标为保证每一个代码单元被正确实现，测试用例设计的目标是覆盖尽可能多的代码路径，通常采用路径覆盖法来判断测试代码的执行效果。
4.集成测试 (Integration-Testing)
软 件测试的中期阶段，主要专注于API与API之间（比如A调用B，B调用C），或者模块与模块之间(比如登录模块与操作模块，操作模块与权限模块)，甚至 子系统与子系统之间的接口（比如淘宝网与支付宝，淘宝网与物流跟踪系统）。测试目的是确保代码单元进行集成后相互之间可以协同工作，典型的应用场景还包括 Web前端页面与服务器后台页面之间的集成等。
5.系统测试 (System-Testing)
软件测试的晚期阶段，主要专注于整个系统进行集成后的整体功能，从一个软件系统层面进行整体测试分析，设计与执行。系统测试阶段结束后并且对发现的Bug已经修复完成，则软件产品基本可以准备交付或发布。
6.验收测试 (Acceptance-Testing)
软件测试的交付阶段，当项目型软件完成系统测试后，便可以交付给客户进行软件的验收。通常验收测试由客户方完成，客户根据明确的需求文档对软件的功能，性能，安全，兼容，可靠，可用待方面进行一一确认。有问题则继续改进问题，再进行验收，如果验收通过，则本项目宣告结束。
7.Alpha测试（Alpha Testing）
Alpha测试也简写为α测试，也被称之为“内测”，是专门针对产品型软件的一种测试手段，通常研发团队或邀请部分优质客户来到研发现场对软件进行测试，发现问题及时讨论解决。所以它是一种可控的测试手段，而且有固定的测试方法和套路。
8.Beta测试（Beta Testing）
Beta 测试也简写为β测试，也被称之为“公测”，是专门针对产品型软件的一种测试手段，通常我们会将已经开发完成的软件交付给用户使用，用户不必在研发现场，而 是正常使用该软件，发现问题后向研发团队反馈，对产品进行改进。所以它是一种不可控的测试手段，我们无法明确知道用户会怎么使用软件产品，所以有些软件会 跟踪记录用户行为，用以改进产品。β测试的产品不能向用户收费。
9.Gamma测试（Gamma Testing）
Gamma 测试也叫γ测试，通常是产品型软件正式上市发布前的最后一轮测试，之所以叫γ测试，是取Release Candidate的R作为标记，即候选发布版本。这个时候的测试通常由整个软件产品研发团队包括项目经理，需求分析师，测试人员，开发人员等所有人在内 进行探索性测试，不依赖于测试用例和文档，也不太多关注需求，而是把全体成员扮演成用户的角色来进行测试。
10.白盒测试（White-Box Testing）
是一种测试方法，主要关注代码逻辑，直接对代码部分进行测试，可以测试代码块，或某一个独立的API，或者是某个模块均可。通常我们在单元测试阶段会更多地使用白盒测试方法。
11.灰盒测试（Gray-Box Testing）
是 一种测试方法，主要关注接口之间的调用，通常在集成测试阶段会更多地使用灰盒测试方法。灰盒测试方法不关心代码的具体实现和代码逻辑，所以它不是纯粹的白 盒测试，同时它也不关注界面的实现，所以它也不是纯粹的黑盒测试。它关注的是接口，我们利用代码来调用接口而不是利用界面操作来调用。从测试的角度来看可 以这样理解：灰盒测试是利用白盒测试的方法进行的黑盒测试，也可以说成是利用黑盒测试方法进行的白盒测试，可以偏白一些，也可以偏黑一些。我们只关注接口 传入的参数类型和返回值，所有黑盒测试的用例设计方法均适用。同时我们是绕开了界面的操作，而直接写代码来调用接口。这就是灰盒测试。
12.黑盒测试（Black-Box Testing）
理解了白盒测试和灰盒测试，黑盒测试的理解相对容易。不关注代码，也不关注接口，而是关注界面。像一个普通用户一样来使用和测试软件。只关注功能的实现，关注用户使用场景，关注需求，关注使用体验。
13.基于协议的测试（Protocol-Based Testing）
基 于代码的测试通常称之为白盒测试，基于接口的测试通常称之为灰盒测试，基于界面的测试通常称之为黑盒测试，而基于协议的测试其实也是一种偏黑的接口测试。 对于网络应用系统来说，前端和后端之间的通信一定需要通过协议完成，所以我们可以绕开前端的界面而直接向后端发送协议数据包来完成相应的操作和接口调用， 从而达到测试的目的。后续项目中我们将花费大量时间来完成基于协议的测试，比如功能性测试，安全性测试和性能测试等，都将基于协议来完成。
14.静态测试（Static Testing）
不启动被测对象的测试，比如代码走读，代码评审，文档评审，需求评审等测试工作被称为静态测试。
15.动态测试（Dynamic Testing）
启动被测试对象的测试，比如白盒测试，灰盒测试，黑盒测试等，都需要将被测对象启动和调用才能达到测试的目的。
16.手工测试（Manual-Testing）
指不依赖于代码，而是完全依赖于人的操作来进行的测试。我们知道测试的重点和难点在于测试的分析和设计，而通常所说的手工测试是指测试的执行。通常用于黑盒测试方法或系统测试阶段。
17.自动化测试（Automation-Testing）
指利用测试脚本来驱动被测对象完成的测试，我们的工作重点在于开发测试脚本，需要具备较强的程序设计能力。
注：基于代码或基于接口的测试天然的就是自动化测试。而基于黑盒测试的方法可以手工完成，也可以自动化完成，后面的项目中使用Selenium来完成的基于界面的测试便是黑盒测试自动化。
18.冒烟测试（Smoke-Testing）
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
19.随机测试（Ad-hoc-Testing）
随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。
20.回归测试(Regression-Testing)
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试的策略有两种，一种是完全回归，一种是部分回归。
21.功能测试（Functionality Testing）
根据产品的SRS和测试需求列表，验证产品的功能实现是否符合产品的需求规格。常见关注点：
(1)是否有不正确或遗漏了的功能
(2)功能实现是否满足用户需求和系统设计的隐藏需求
(3)输入能否正确接受？能否正确输出结果？
22.性能测试（Performance Testing）
用来测试软件在系统中的运行性能。负载、压力、容量测试等都属于这一范畴。常见关注点：
(1)系统资源，cpu、内存、io读写
(2)并发用户数
(3)最大数据量
(4)响应时间
(5)处理成功率
23.兼容性测试（Compatibility Testing）
主要是为了检查软件在不同的软\硬件平台上是否可以正常的运行的一种测试。常见关注点：
(1)兼容不同的OS
(2)Web项目兼容不同的浏览器
(3)兼容不同的数据库
(4)兼容不同的分辨率
(5)兼容不同的厂家的硬件设备，耳机、音响等
24.可靠性测试（Reliability Testing）
为了达到或验证用户对软件的可靠性要求而对软件进行的测试。通过测试发现并纠正软件中的缺陷，提高其可靠性水平，并验证它是否达到了用户的可靠性要求。可靠性测试包含了软件的健壮、稳定、容错、自恢复等方面。常见关注点：
(1)输入异常的数据
(2)操作异常的文件
(3)长时间工作后保持正常
(4)多次打开应用程序
(5)系统失效后是否可以正常恢复
25.安全性测试（Security Testing）
为验证应用程序的安全等级和识别潜在安全性缺陷的过程。常见关注点：
(1)SQL注入
(2)口令认证
(3)加解密技术
(4)权限管理
(5)安全日志
(6)通信模拟
26.可用性测试（Usability Testing）
根 据ISO 9241-11的定义，可用性是指在特定环境下，产品为特定用户用于特定目的时所具有的有效性、效率和主观满意度。常见的可用性测试大多都是基于界面的测 试，体现在易用、易懂、简捷、美观等方面。当然，目前我们谈得更多的是用户体验（User Experience）测试，用于代替可用性测试，它可以涵盖更多的内容。比如无论是功能、性能、可靠性、兼容性或者安全的问题，都可以归结为用户体验上 的问题。常见关注点：
(1)过分复杂的功能或指令
(2)困难的安装过程
(3)错误信息过于简单
(4)用户被迫去记住太多的信息
(5)语法、格式和定义不一致
27.探索性测试（Exploratory Testing）
测试过程中，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息以及以往的经验，从不同的角度出发，最终目的就是发现潜藏的缺陷。探索性测试比较自由，执行者不限于测试人员和开发人员，可以是整个团队的所有成员。
探索性测试请注意以下几点：
(1)探索性测试需要有一个明确的能达成的终点，否则测试无法停止，陷入到泥泞中。
(2)测试方向不能偏离，由于探索性测试比较自由，所以存在偏航的风险，不要将时间和资源浪费在不重要或根本不需要的地方。
(3)有组织有方法有策略的进行测试，并不是瞎测。
探索性测试常见方法有：
(1)指南针测试法
(2)卖点测试法
(3)逆向测试法
(4)取消测试法
(5)随机测试法
(6)极限测试法
(7)懒汉测试法
28.容量测试（Volumn Testing）
容量测试是面向数据的，它的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数、允许的最大文件数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。
29.安装及配置测试（Installation & Configuration Testing）
对安装升级卸载以及配置过程进行的测试。这项测试看起来很单一，但实际包含的内容也很多。
30.文档测试（Documentation Testing）
对项目中产生的需求文档，概要设计文档，详细设计文档，用户使用说明书等进行测试。
31.全球化测试（Globalization Testing）
严格的说，全球化=国际化+本地化。
国 际化Internationalization，也称为I18N测试。是使产品或软件具有不同国际市场的普遍适应性，从而无需重新设计就可适应多种语言和 文化习俗的过程。真正的国际化要在软件设计和文档开发过程中，使产品或软件的功能和代码设计能处理多种语言和文化习俗，具有良好的本地化能力。
Localization， 也称为L10N测试。是将产品或软件针对特定国际语言和文化进行加工，使之符合特定区域市场的过程。真正的本地化要考虑目标区域市场的语言、文化、习俗、 特征和标准。通常包括改变软件的书写系统（输入法）、键盘使用、字体、日期、时间和货币格式等。
