我们在测试项目管理中，初期预研阶段，就要通过仔细分析和研究，确定以后工作中所要采用的测试类型。不同的测试项目，所选取的测试类型也必定不同。具体选用哪些，需视项目实际情况而定！
简单来说，这些不同的测试类型，是按照不同的测试对象和测试范围划分的。
我们以手机终端软件的测试项目为例，具体分类及包含关系如下图示：
版本测试（Build Check/ Release Test）是开发完成代码设计和Code review、集成并发布后，测试人员拿到该测试版本，首先要做的一类测试。
它的测试范围极窄，大概包括20~30条用例，都是最基本的功能用例，需保证1人在半小时内测完。
对软件项目来说，根据子模块的大小、需求粒度等，每个子模块只选取3-5条基本用例。
Build Check的目的是为了第一时间验证版本的正确性/稳定性，保证之后的测试中，各子模块不会出现严重的、阻塞基本功能的Block Issues。
如果在版本测试中发现阻塞正常测试的严重问题，需第一时间提交给开发解决。测试工作暂时Block，转而关注问题的分析、解决与跟进。
如版本测试顺利通过，才能开展后续的所有测试，所以它是测试工作的一个前提条件。
目前很多持续集成工具如Hudson等均可加入实现了自动化测试执行的版本测试套件，当自动生成Daily Build后，马上开始后续的Unit Test、Coverage Test、Lint Test、Build Check等。
在项目开始的需求开发阶段，敏捷开发模式下，我们执行的是迭代测试，包括功能测试和健全测试。
因在开发阶段，PD/UI都不够稳定，开发也在频繁进行代码修订，这个时期不适合采用大规模的产品测试。
而迭代测试是适合于敏捷开发模式下的一类测试，它可以紧跟开发/需求/UI的变更步伐，做一些小规模、针对性的测试工作。
其中，功能测试（Function Test）是测的最基本功能点和需求，也就是UI上的功能模块设计、业务流程设计、需求点设计实现等。它模拟是正常用户的正常行为，一般均为单任务，不牵扯交互、压力、异常操作等。而健全测试（Sanity Test）是系统测试的一个子集，它包含的是系统测试用例中的基本部分，相当于在系统测试之前所做的一次预测试。
健全测试达到标准，表示已达系统测试开始的准入条件之一，决定是否可进行全面的系统测试！
一般健全测试用例数量占系统测试数的1/3左右，包括了所有K（Key）、M（Mandatory）型的测试用例，不包含O（Optional）型。
系统测试是在产品测试阶段进行，它的覆盖范围极广，是对于软件产品的最重要测试内容之一。
当前期敏捷开发阶段的需求测试（REQ Test）和基本功能测试、健全测试执行通过后，可认为产品质量已基本稳定，将前期测试结果作为准入条件，就可以开展后续的全面系统测试了。
应注意的是：系统测试（System Test）是针对整个产品、整个软件系统所做的全面测试，而不是只针对单个功能、REQ或单一业务流程。
它一般是在通过了Alpha release，迭代测试结束后，已经确保80%的功能集成且均REQ被分别测试，此时再开展系统测试，才有作用和意义。
我们在系统测试中，定义了如上图示所列的各种测试类型。
当然在不同的项目中，有时还需要定义一些Special Test Category如安全性测试、完整性测试、一致性测试、集成测试等。
举例如手机上的客户端项目中，比较特殊的用例类型就是三层结构测试，因客户端设计原因，它是处于底层数据连接和上层App应用之间的夹层。
所以可以设计基于“数据连接——客户端——上层应用”的三层结构测试，考核数据连接/设置/数据传输、上层App的启动、退出和异常场景等使用情况对于客户端的影响。
交互测试（Interaction Test）是指的在同一测试机型上，被测模块（如手机客户端）与本机其它模块之间的交互测试，
尤其是涉及接口调用和功能交叉的一些模块，类似客户端代码中调用的其它模块、客户端状态与数据连接设置的交叉、客户端计时与本地计时的功能交叉等。
互操作测试（Inter-Operability Test）是指的被测产品与其它机型之间的交互，主要涉及信息、协议、信号解析的匹配与兼容性问题。
例如不同机型对于短信的解析方式不同，可能导致互发后字符显示乱码，所以测信息时必须考虑互操作测试。
但这主要针对不同解析方式和协议兼容性的，如果客户端有统一定义的业务/测试协议规范，不涉及这个问题，系统测试中就可以不考虑这个类型！
性能测试（Performance Test）是针对产品/软件性能所做的度量测试，同时包括软件产品与竞品的性能对比测试。
首先要在各种业务规范、测试规范、SW设计文档、需求规格文档等各规范文档及UI/PD设计中，采集了所有的性能指标。
然后可使用本机自带工具、自己开发测试工具、自动化测试脚本、网上搜寻的工具等，对这些性能指标进行精准度量，得到性能指标的测试结果。
压力测试（Stress Test）是指在各种压力情况和异常场景下，产品/软件功能使用的测试工作。
如客户端的连续登录、下线100次，连续查询100次，各种异常下线，多用户同时登录，网络信号变弱等，尤其应关注各种异常场景下的功能使用状况。
这部分测试，如果能用自动化测试工具完成的，可测试100次。
一些涉及网络覆盖、信息接收、验证码输入等无法通过自动工具完成的，可手动执行20次。
边界测试（Boundary Test）是指各种功能使用在极限情况下的测试，不仅是界面上的边界，也包括功能中的极大/极小边界、极多/极少值等。
例如客户端的安装包，所能正常安装的最长路径长度（chars），最深存储文件夹层数（层），登陆用户名的最小字符数（个）等，都应当作为测试点。
如果边界测试的用例数较少，可以直接并入系统测试用例中，不必单独列为一类，以免增加统计难度。
兼容性测试（Compatibility test）是指产品或软件对于各种环境、设备、网络、解析规范等的适配能力测试。
比如普通的软件产品，要测试基于各种OS（例Windows XP/ Win 2000/ Linux/ Mac OS/ Ubantu）、不同支持软件（例Outlook2003/ Outlook2007）的兼容能力。
而手机客户端，主要通过四类测试来考核其兼容适配能力：终端适配测试、SIM卡兼容性测试、设备兼容性测试、网络兼容性测试。
终端适配测试就是上图中所说的适配测试，因手机客户端是一个嵌入式系统，软硬件不可分割，故并入兼容性测试中。
它测试的是不同分辨率、不同OS平台、不同硬件配置的机型对于客户端的适配兼容能力，我们在测试过程中，主要基于以下考虑：
市场主流机型Top 20，主流分辨率，市场占据较多的OS前三位及其版本、主流设计商的芯片、对大字体设置的支持能力等等。
SIM卡兼容性测试，是针对不同运营商、不同业务类型的SIM卡所做的兼容能力测试。
如客户端是基于移动SIM卡开发的业务功能，则其中的短线接收，必须用移动卡才能正常接收，而在项目初期研发阶段，可能开发未考虑处理SIM卡兼容问题，就会导致使用联通/电信SIM卡会死在短线发送界面。此类测试解决的就是这些漏洞和问题！
设备兼容性测试，这类测试需要借助一些专业的模拟网络环境和实验室，它可以模拟不同厂商的设备，保证客户端产品在所需的各种设备下都可以正常工作！
网络兼容性测试，对于客户端来说，主要就是外场测试，包括企业内部外场区域和外部区域、移动区域等。
它的测试目的是为了验证客户端在各种网络环境下的功能适配能力，执行的是全部功能+系统测试用例，在发现问题后还应做针对性测试。
系统测试中，还包括内存泄漏测试（Memory-Leak Test）、数据库测试（Database Test）。
内存测试主要针对应用软件的内存管理和释放机制，测试当大数据量传输、数据阻塞、频繁操作等异常情况下，内存使用和释放的正常性。
一般使用自动化工具来进行此类测试，少量的内存测试用例可并入性能测试用例中。
数据库测试是一类重要测试类型，主要测客户端与后台Server之间的数据传输、并发、准确同步等。
一般手机客户端和后台的各类服务器等都有数据交互，应当针对这些Server进行专门的服务器测试，其中数据库测试和文件系统测试自然是重要组成部分！
项目开发前期，即自Kick off至Alpha release阶段，跟随软件的快速变化，我们所做的是迭代测试（REQ Test/ Function Test/ Sanity Test）。此间每天采用CIS自动生成的Daily build，在更新版本上进行迭代式测试。在Scrum Team内随时与开发、产品进行沟通，快速反应解决问题。
项目中期，自Alpha release ~ Beta release阶段，功能模块已基本集成，需要开始执行大规模的系统测试，并穿插周期性的功能测试。测试频度和范围视项目的测试周期、人力而定，但一般开始要先执行一轮全面系统测试（Full ST），以正确、完整地评估软件产品质量。
之后再根据各模块成熟度和缺陷状况，决定如何对FT和ST进行针对性裁剪，选择新增模块、薄弱模块和重点模块的关键项用例来对软件产品做局部测试。
此期间延长软件版本的迭代周期，每周更换2~3个测试版本，而不是每天更新版本。但需随时监察Release note和与开发及时沟通，知道有较大的功能性改动或重要的bug-fix时，就及时更换新版本进行测试！
最后一个阶段——项目后期，也就是Beta release ~ Final/Product release之间的阶段，是产品发布测试期。此时已进入产品稳定和待发布期，在此期间，就不能像以前一样频繁更换测试版本了。一般产品质量较好时，我们采用每周更换一次新版本的更新频度。
在这个阶段内，需要做的就是针对发布版本（Release candidate）的产品级测试，包括所有系统测试类型、验收测试、缺陷跟进及处理等。
在产品发布之前1~2周，一定要最后做一次全面覆盖测试（Full Test），包含功能测试、系统测试的全部用例执行，以在最大程度上保证发布产品的总体质量！
如上所述，当功能测试、系统测试、缺陷数量等均已达QA所订的质量目标后，在正式发布之前，当PD/UI已完全确定、稳定时，我们要做一轮验证测试。
验证测试（Verification Test）是针对PD/UI/GUI的核查和验证，主要包括需求测试和UI验证。
需求测试是核查所有需求点，看其所标示的功能是否已在软件发布版本上正确、完整实现。
UI/GUI验证是核查软件产品的功能，是否与UI上标示的业务流程、界面显示完全一致，GUI中的每个Text/Graphic/Icon大小、颜色、色阶色深是否与定义一致。
最后一类测试，就是稳定性测试，主测两个指标——MTBF和MTTF，均使用自动化测试工具实现。
MTBF也就是平均无故障运行时间，应使用自动化Tool，在4台测试机上进行连续的、模拟用户行为的功能测试，取其均值作为考核指标。
另外MTTF测试是在Android系统下直接运行adb命令，模拟在测试机上乱点乱划的行为，考察无故障运行时间。这是另一类稳定性测试！
注意：为通过Alpha/Beta/Final release，我们有时会在里程碑截止日期（Milestone Deadline）到达之前，针对未达质量目标的功能测试/系统测试，再做一轮回归测试，以验证通过Release standard。
而各阶段测试期间，我们也会针对局部的重点问题、严重缺陷和关键功能，做一些针对性测试，如焦点测试、集中测试、探索测试、自由测试等。其实从真正意义上来说，这些已经不属于测试类型的范畴，而是一些不同的测试方法！
回归测试（Regression Test），是针对之前的一轮测试进行的再次测试验证，以达到QA定义的质量指标。FT/ST等都可以做回归，但以ST Regression较为重要。
回归测试的范围主要包括以下三部分：上轮测试中的Fail case，需重新验证看是否已Pass；目前遗留的所有缺陷，进行修复验证；针对缺陷集中的薄弱模块、重点模块，进行引申测试。
焦点测试（Focus Test）也就是专题测试。当测试过程中发现严重且普遍、涉及模块较多、影响较大的缺陷或问题时，应马上安排人手进行专门性测试。Test Leader围绕此问题设计专题测试用例，测试人员在执行过程中，也要自己进行思维发散和延伸，多做一些周边的操作测试，以在最大程度上发现可能的隐藏缺陷！
集中测试（Test Workshop），亦称圆桌测试，也是在产品测试过程中经常采用的一种测试方式。顾名思义，它就是把一群用户级测试人员集中起来，在一个封闭会议室中，大家围着圆桌共同进行产品使用和测试。这些人可以是真正不了解产品的最终用户（End User），也可以是相互交换测试模块后的专职测试人员。测试的目的就是为了集中发现问题，尤其是那些因测试习惯性思维和行为盲区导致的潜在缺陷和风险点。
探索测试（Exploratory Test），简称ET，其实是一种有导向、有目的的自由测试方法。它采用了一些科学统计和分析方法，针对性地对一些重要、关键测试点和模块、范围进行测试。主要由一名ET Leader做主导，负责定义Test point、安排测试内容/人力/时间、一对一开会讨论、总结编写ET Report等。
自由测试（Free Test）就很简单了，大家都知道，就不多做赘述了。FreeTest可以随便找人来使用软件产品，寻找潜在的风险和隐藏的问题。也可以设定特定的目标用户群，从其中各抽出一部分人来集中进行自由测试。这样对样本点采集的全面性和可靠性更有意义，有时我们也会这样做！
总之，测试类型千变万化，但万变不离其宗。我们在真正的测试项目管理中，一定要认真考虑、分析清楚当前处于哪个阶段、面临哪些重要问题、针对这些情况应采取何种测试类型来应对。
天底下所有的技术、知识都是死的，运用存乎一心，只有它们变成了你身体的一部分，真正能够掌握、运用和创新改进的时候，你才能说“我真的会了！”
版权声明：本文出自 cmriqa 的51Testing软件测试博客：http://www.51testing.com/?489136
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
