任何的测试工作都可以从测试人员、覆盖范围、潜在问题（bug）、测试活动和测试评估五个维度进行描述。

　　测试人员：谁要做测试？

　　覆盖范围：什么东西需要测试？

　　潜在的问题：为什么进行测试(测试的风险是什么)？

　　测试活动：你如何测试？

　　测试评估：如何判断测试是通过还是失败？

　　测试任务通常分配在一个维度上，但你需要在所有五个维度上完成工作。

　　例如，有人可能会要求你做功能测试(彻底测试每个功能)，这是告诉你要测试什么。

　　但由谁来进行测试，寻找什么类型的bug，如何测试每个功能，以及如何决定程序是通过还是失败都需要在测试任务启动时考虑。

　　本文主要从这五个维度对测试这门活动/技术进行分类。

　　基于测试人员的测试技术分类方法

图1 基于测试人员的测试技术分类

　　用户测试

　　用户测试针对通常会使用你的产品的人群进行测试。分析用户的产品需求、使用习惯等等，以用户的立场探索产品。

　　α(alpha) 测试

　　也可叫做“内部测试”，通常由项目里的测试团队完成。

　　Β(beta)测试

　　也被称作“验收测试”，由产品的最终用户进行。

　　beta测试也有很多的类型，如：设计型beta测试、市场型beta测试、完整型beta测试。

　　设计型beta测试要求用户(特别是主题专家)对设计进行评估，以便有时间根据结果进行更改；

　　市场型beta测试是让市场人员评估产品的可用性和市场推广性，收集市场人员对产品的兴趣度和推广度；

　　兼容性beta测试，使用用户方平台测试，保证用户升级或更新产品时无兼容性问题。

　　专家测试

　　将产品交给某些领域的专家进行测试。

　　结对测试

　　两个测试人员一起进行测试。

　　基于覆盖范围的测试技术分类方法

图2 基于覆盖范围的测试技术分类

　　功能测试

　　据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求，如白盒测试和黑盒测试。

　　集成测试

　　将几个功能联合，测试他们之间如何交互和工作的。

　　UI界面测试

　　测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯等。

　　路径测试

　　路径指为了达到当前状态所采取的所有步骤或程序所经过的所有语句。路径测试包括测试程序中的许多路径。你不可能通过一个重要的程序测试所有的路径。

　　因此，有些测试人员做子路径测试，测试许多部分路径。例如，基路径测试涉及测试某种类型的大多数或所有子路径(基路径)，则很少有长路径的测试可能发现这些测试遗漏的bug。

　　状态流转测试

　　在给定的状态下，一些输入是有效的，而另一些输入则被忽略或拒绝在基于状态的测试中，你让程序遍历大量的状态转换(状态更改)，并每次仔细检查结果。

　　配置测试

　　在测试活动中，通常使用默认配置或习惯性配置。扩大配置测试范围，选择使用较少的配置进行测试，可能容易发现一些一楼的bug。

　　基于需求说明的测试

　　基于需求的测试集中于证明程序满足了需求文档中的每一个需求(或者集中于，逐个需求，证明一些需求没有被满足)。

　　其他的还有非常熟悉的集合域测试、等价类分析测试、边界测试、代表值测试等等。

　　基于潜在问题的测试技术分类方法

图3 基于潜在问题的测试技术分类

　　通常，程序测试只关注于程序方面的需求和问题，而对于基础硬件或底层系统方面的测试少之又少（或者容易忽略）。本节主要将在程序测试过程中，常见的容易被忽略的潜在问题。

　　输入约束测试

　　输入约束是对程序所能处理的内容的限制。如：底层系统只能处理32位数字(或更少)，输入超过32位的数字。

　　输出约束测试

　　如：输入是合法的，但是程序异常或文件权限等原因，导致输出失败。

　　计算约束测试

　　输入和输出都很好，但是在计算值的过程中，计算结果超出系统范围，程序会失败。例如，将两个巨大的数字相乘可能会产生程序无法处理的巨大结果。

　　存储约束测试

　　如：程序运行过程中内存耗尽，存储数据是物理磁盘空间不足等。

　　基于测试活动的测试技术分类方法

图4 基于测试活动的测试技术分类

　　回归测试

　　指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试可被分为两类：递进型回归测试和修正型回归测试。

　　递进型回归测试是指对原有测试用例进行修改，以适配测试修改后的程序（如新需求引入导致的模块或功能增删）。

　　修正型回归测试与递进型回归测试相反，主要特点在于原有测试用例不做任何修改。

　　脚本测试

　　也叫手动测试，通常由初级测试人员按照高级测试人员编写的循序渐进的过程完成。

　　冒烟测试

　　冒烟测试是对每一个新编译的需要正式测试的程序版本进行测试。通过冒烟测试，在程序代码正式编译并交付测试之前，先尽量消除其表面的错误，减少后期测试的负担。

　　探索性测试

　　测试人员以“旅游者”的角度，不断创造方法和途径探索程序功能。

　　游击测试

　　探索性测试方法的一种。快速、破坏性地对程序进行测试。

　　场景测试

　　场景测试通常包含：真实性、复杂性。

　　场景必须是真实的，它应该反映客户实际会做的事情；场景应该是复杂的，针对多个功能或系统激行测试。

　　安装测试

　　主要测试程序在不同操作系统和硬件上能够正常安装和兼容性运行。

　　负载测试

　　不限制程序的运行资源，测试程序的运行情况。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

　　稳定性测试

　　测试程序在长期（一天、一周、一个月……）运行情况下，功能是否正常。

　　性能测试

　　性能测试通常结合负载测试、压力测试等方法，在测试过程中监测性能指标（如cpu、内存等），以发现是否存在性能瓶颈和优化空间。

　　基于测试评估的测试技术分类方法

图5 基于测试评估的测试技术分类

　　评估技术描述了确定程序是否通过测试或未通过测试的方法。他们没有具体说明应该如何进行测试或应该如何收集数据。但是他们告诉你，如果你能收集某些数据，你就能评估它。

　　数据验证测试

　　验证程序运行时，数据在内部传递过程中是否失真或损坏。

　　保存结果对比测试

　　设立正确结果基线，将新测试结果与基线对比，判定是否通过。

　　需求/规范文档对比测试

　　将程序实现的功能与需求/规范文档比较，判定是否通过。

图6 测试技术分类方法总览

　　测试技术分类方法多种多样（如图6），但是所有测试活动都离不开测试人员、覆盖范围、潜在问题（bug）、测试活动和测试评估五个维度，本文从这五个维度归纳分类方法。当然，你也可以有你自己的分类方法。毕竟，开放性思维比什么都重要。

作者：刘晓佳Rachel   

来源：51Testing软件测试网原创