1.测试的种类（按阶段划分）：单元测试、集成测试、冒烟测试、系统测试、随机测试、验收测试。
2.测试的类型（按测试的内容划分）：功能测试、界面测试（UI测试）、接口测试（灰盒测试）、性能测试、兼容性测试、安全测试、安装测试。
1.测试的种类（按阶段划分）
测试的阶段也根据项目开发的进度来进行，从先到后划分为下面几种测试阶段：（根据项目的实际要求进行相应测试）
1.1单元测试
单元测试是指对软件中的最小可测试单元进行检查和验证。
准入条件
1、源码已实现完成或50%；
2、源码编译能通过；
3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；
4、单元测试用例通过评审并归档；
主要测试点和方法
l 代码静态检查
无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。
l 独立路径和错误检查
独立路径测试：在模块中应对每一条独立执行路径进行测试，每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。
错误检查：首先检查程序是否有错误处理；其次对于程序中的防错处理的完整性和正确性进行检查。错误处理包括：不同数据类型的对象之间进行比较；错误地使用逻辑运算符或优先级；因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；比较运算或变量出错；循环终止条件或不可能出现；迭代发散时不能退出；错误地修改了循环变量。
单元测试人员一般是开发自测。
1.2集成测试
集成测试，也叫[组装测试]或联合测试。在[单元测试]的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的[接口]
准入条件
1、单元测试用例编写完成；
2、核心功能开发完成；
3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；
4、子系统间接口说明文档通过评审并归档；
5、项目集成测试用例文档通过评审并归档；
主要测试点和方法（详见3.3接口测试）
1.3冒烟测试（必须）
冒烟测试是开发完成后，正式移交测试前做的一个中间测试工作，即在刚刚编译出来后，开发人员需要进行基本确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以移交测试，开始正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
该工作可由开发人员先行自测，保证移交测试版本的质量，防止出现阻碍测试的情况出现，也可由测试人员来进行，只有冒烟测试通过后，才进入正式的测试流程，否则会把版本打回，重新编译。
1.4系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。也是整个测试工作最重要，最关键的测试部分。
准入条件
1、单元、集成测试完成；
2、前阶段中缺陷修复率100%；
3、功能用例编写完成，覆盖率达100%；
4、项目需求文档、设计文档均通过评审并归档；
5、测试用例通过评审并归档；
主要测试点和方法（详见3.1功能测试章节）
1.5随机测试（非必须）
随机测试没有书面[测试用例]、记录期望结果、检查列表、[脚本]或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试
1.6验收测试（非必须）
1.6.1 β测试 （beta测试）
β测试是[软件]的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。
1.6.2 α测试（Alpha测试）
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。
在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。
α测试和β测试的不同之处在于测试的环境，前者是在开发环境，后者是在实际使用环境（生产环境），故后者模拟真实使用场景程度更高，发现的问题也更有意义，一般运用在项目的试运行阶段。
2.测试的类型（按测试内容划分）
2.1功能测试
功能测试也叫黑盒测试，是在不看代码的前提下，通过运行软件来进行测试，重点是关注系统的功能实现是否正常、设计是否合理、用户的需求是否全部覆盖，这也是测试工作最主要、最重要的内容。在版本稳定以后，或者进行回归测试的时候，可根据项目的具体情况，对主要功能通过编写自动化测试脚本，进行自动化测试。
根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。
边界类
1.验证边界值，对16-bit 的整数而言 32767 和 -32768 是边界；
2.屏幕上光标在最左上、最右下位置；
3.报表的第一行和最后一行；
4.数组元素的第一个和最后一个；
5.最小值-1/最大值+1/空值；
6.分析规格说明，找出其它可能的边界值条件。
等价类
1.有效等价类，指符合系统设计有意义的输入输出合集；
2.无效等价类，指不符合系统设计错误的输入输入合集；
APP特有功能
1.应用的前后台切换；
2.数据更新；
3.离线浏览；
4.定位、照相机服务，扫描二维码功能；
5.时间测试；
6.push测试；
7.运行测试。
8.弱网测试，
9.安装卸载工作，
10、交叉事件测试（就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。 操作类型测试：如横屏测试，手势测试 ）
App****的功能测试具体为：
l 运行
1）App安装完成后的试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提示。
3）App打开速度测试，速度是否可观。
4）App页面间的切换是否流畅，逻辑是否正确
5）注册
--同表单编辑页面 --用户名密码长度 --注册后的提示页面 --前台注册页面和后台的管理页面数据是否一致 --注册后，在后台管理中页面提示
6）登录
--使用合法的用户登录系统。 --系统是否允许多次非法的登陆，是否有次数限制。 --使用已经登陆的账号登陆系统是否正确处理。 --使用禁用的账号登陆系统是否正确处理。 --用户名、口令（密码）错误或漏填时能否登陆。 --删除或修改后的用户，原用户登陆。 --不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。 --登陆后，页面中登陆信息。 --页面中有注销按钮。 --登陆超时的处理。
7）注销
--注销原模块，新的模块系统能否正确处理。 --终止注销能否返回原模块，原用户。 --注销原用户，新用户系统能否正确处理。 --使用错误的账号、口令、无权限的被禁用的账号进行注销
l 应用的前后台切换
APP切换到后台，再回到app，检查是否停留在上一次操作界面。
APP切换到后台，再回到app，检查功能及应用状态是否正常，IOS 4和IOS 5的版本的处理机制有的不一样。ISO和Android版本也不一样。
app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
当App使用过程中有电话进来中断后再切换到app，功能状态是否正常
当杀掉app进程后，再开启app，app能否正常启动。
出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
l 免登录
很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app.
app有免登录功能时，需要考虑IOS版本差异。
考虑无网络情况时能否正常进入免登录状态。
切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
app切换到后台，再切回前台的校验
切换到后台，再切换回前台的测试
密码更换后，检查有数据交换时是否进行了有效身份的校验
支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
检查用户主动退出登录后，下次启动app，应停留在登录界面
l 数据更新
根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。
需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
确定哪些地方从后台切换回前台时需要进行数据更新。
根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
检查有数据交换的地方，均有相应的异常处理。
l 离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
在无网络情况可以浏览本地数据
退出app再开启app时能正常浏览
切换到后台再切回前台可以正常浏览
锁屏后再解屏回到应用前台可以正常浏览
在对服务端的数据有更新时会给予离线的相应提示
l App更新
当客户端有新版本时，有更新提示。
当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。
当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
l 定位、照相机服务
App有用到相机，定位服务时，需要注意系统版本差异
有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
测试定位、照相机服务时，需要采用真机进行测试。
l 时间测试
客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。
--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。
l PUSH测试
检查push消息是否按照指定的业务规则发送
检查不接受推送消息时，检查用户不会再接收到push.
如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。在非免打扰时间段，用户能正常收到push。
当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
测试push时，需要采用真机进行测试。
2.2界面测试（UI测试）
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯。
测试内容
1、导航、链接、Cookie、页面结构包括菜单、背景、颜色、字 体、按钮名称、title、提示信息的一致性等；
2、界面内容完整性检查，通过浏览器测试，确认对象可以正确的反应业务的功能和需求，包括窗口与窗口之间的跳转，字段与字段之间的浏览，各种快捷键的使用。
3、窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标准。
2.3接口测试（灰盒测试）
当模块之间、子系统之间有接口交互时，需要根据接口文档进行测试，接口测试也叫集成测试或灰盒测试，主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
测试内容
1、输入的实际参数与形式参数的个数是否相同；
2、输入的实际参数与形式参数的属性是否匹配；
3、输入的实际参数与形式参数的量纲是否一致；
4、调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
5、调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
6、调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
7、调用预定义函数时所用参数的个数、属性和次序是否正确；
8、是否存在与当前入口点无关的参数引用；
9、是否修改了只读型参数；
10、对全局变量的定义各模块是否一致；
11、是否把某些约束作为参数传递。
12、如果模块功能包括外部输入输出，还应该考虑下列因素：-文件属性是否正确；-OPEN/CLOSE语句是否正确；
13、格式说明与输入输出语句是否匹配；
14、缓冲区大小与记录长度是否匹配；
15、文件使用前是否已经打开；
16、是否处理了文件尾；
17、是否处理了输入/输出错误；
18、输出信息中是否有文字性错误。
2.4性能测试
性能测试是通过性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
性能测试包括的测试内容主要概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
性能测试的目的是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。一个系统需要达到的性能指标也是来源于需求，和用户对该软件的性能要求。
常见的性能指标如下：
l 响应时间（按照不同的处理细分）
1）事务处理类
快速响应类
普通响应类
2）查询类
3）统计类
l 吞吐量与关键量
l 事务成功率
l 服务器资源
CPU使用率
内存使用率
I/O吞吐量
测试内容
性能测试类型包括负载测试，强度测试，容量测试等。
l 负载测试：是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。
l 压力测试：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。
l 容量测试：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。
另外，并发测试是应用在客户端，以客户端做为入口进行的一项重要性能测试，它是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。
2.5兼容性测试
web兼容性测试范围主要从操作系统、浏览器、分辨率这三方面考虑， 而系统（如不同的Windows版本）和浏览器（如IE9、谷歌、火狐）是重点考虑方向，系统应该支持什么系统和浏览器，也是应以需求为依据。
APP兼容性主要考虑内部和外部兼容性
1）与本地及主流App是否兼容；
2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS等)，App的数据和运用是否正确；
3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致：
--不同操作系统的兼容性，是否适配
--不同手机屏幕分辨率的兼容性
--不同手机品牌的兼容性
--不同手机版本、不同分辨率
2.6安全测试
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。
如需求上对软件产品有具体的安全等级要求，那么我们需要从下面几个方面进行安全测试：
可测试性和通用性上划分为：权限管理测试、认证测试、会话管理测试、服务器测试、数据注入测试，其余方面（如环境安全、媒体安全）可在部署和运维中保证。
测试内容
l 权限管理测试
验证用户是否可以进行横向越权和纵向越权操作
Ø 页面是否进行权限判断
Ø 页面资源标志是否和用户信息匹配
Ø 用户登录后，应以会话中的用户session的用户身份信息为准。
Ø 每个URL必须坚定权限，不能通过菜单屏蔽或按钮disable作为限制条件。
l 认证测试
认证测试是为了避免用户账号和密码遭到暴力破解而进行的测试
Ø 系统存在验证码机制。
Ø 不允许简单面的存在。如纯英文、纯数字等。
Ø 认证失败的错误提示不应该提示详细信息，避免攻击者根据提示信息改良破解方式。
Ø 系统存在锁定策略。
Ø 系统不存在认证绕过的漏洞。
Ø 找回密码和修改密码不存在漏洞。
Ø 使用安全的数据传输。
Ø 强口令策略。
l 会话管理测试
会话管理用于保持用户的整个会话活动与计算机系统跟踪过程，根据项目需求，关注WEB服务器的会话管理。
Ø 用户登录后，身份信息由服务器端会话的Session中的用户信息为准。
Ø cookie中不会带有session ID信息。
Ø 用户操作停止后会话保持时间不会超过10分钟，超过10分钟会跳转回登录界面。
Ø 用户登录后，每次请求服务器数据后session ID都会改变。
Ø 注销后用户信息被清除。
l 服务器测试
Ø 服务器运行账号不应该是特权账号或高级别权限账号，如“root”“administrator”等。
Ø 未使用的端口应为关闭状态。
Ø 不能通过任何方式获得服务器的详细版本信息。
l 数据注入测试
当系统接受数据注入时，可能会造成数据泄露、数据被修改等严重影响，导致业务中断。
Ø 不存在注入点。
Ø 页面中不包含类似系统命令的返回信息。
2.7安装测试
安装测试只针对C/S架构的系统（即App），需要验证App是否能正确安装、运行、卸载以及操作过程和操作前后对系统资源的使用情况。
测试内容
l 安装
1）软件在不同操作系统（Android、iOS）下安装是否正常（手机端）。
2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3）软件安装各个选项的组合是否符合概要设计说明
4)）软件安装向导的UI测试
5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7）安装空间不足时是否有相应提示
8）安装后没有生成多余的目录结构和文件
9）对于需要通过网络验证之类的安装，在断网情况下尝试一下
10）还需要对安装手册进行测试，依照安装手册是否能顺利安装
l 卸载
1）直接删除安装文件夹卸载是否有提示信息。
2）测试系统直接卸载程序是否有提示信息。
3）测试卸载后文件是否全部删除所有的安装文件夹。
4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。
5）卸载是否支持取消功能，单击取消后软件卸载的情况 。
6）系统直接卸载UI测试，是否有卸载状态进度条提示 。