2024年想测出更多bug?这种新的测试方法教给你

2024软件测试面试刷题，这个小程序（永久刷题），靠它快速找到工作了！（刷题APP的天花板）-CSDN博客文章浏览阅读2k次，点赞85次，收藏11次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题，web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题，还有互动交流板块……https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5501与剧本测试相比，探索性测试具有发现更多缺陷和更高质量缺陷的优点。然而，近十几年来，关于探索性测试的专有测试方法的研究很少。

本文以全局探索性测试中的快递测试法和快递行业模式为灵感，提出了一种新的快递测试方法。快递测试方法的测试类型从数据扩展到数据、交互对象和活动、内部和外部状态以及活动序列。

通过实践验证，与快递测试法方法相比，该方法能够挖掘出容易被遗漏的隐藏测试点，设计出更多的测试用例，发现更多的故障，具有更高的测试效率。

关键词：探索性测试，快递测试法，新型快递测试方法，更多，效率

一.背景

随着软件技术的发展，软件开发过程中对软件测试的需求越来越庞大，从原来单纯的寻找软件缺陷，到后来的评估软件可用性、性能等等方面，软件测试都发挥着重要作用。

软件测试如此高的重要性，难免会有不少的测试人员试图完成“完全测试”——通俗地说即是想将软件的方方面面、每一行代码都测试覆盖到。

但是，“完全测试”是不可能完成的[1]。究其原因，软件测试的投入（时间、人力等）是一个巨大的限制因素。

我们不可能围绕一个软件投入无穷的时间和人力进行测试，并且软件是一个不断发展和迭代的产品，已经完成的功能可能在产品迭代时发生变化，相应的测试要点也会发生变化。

剧本式测试方法作为一个传统测试方法已经深入人心，几乎所有软件公司在发展过程中都会或多或少得使用该测试方法。

但剧本式测试方法在面临产品的快速迭代时也暴露出了许多缺点，例如：

• 在工业实践和真实的生产环境中，测试用例往往很难设计，测试人员也很少会严格按照设计的测试用例进行测试[2][3][4][5][6]；

• 需要耗费大量人力和时间成本维护测试用例或测试脚本[7]；不同的测试人员使用相同的测试策略、按照相同的测试脚本执行测试，测试结果（挖掘出的缺陷数量和缺陷质量）也会存在较大差异，测试结果不具有统一性[8]；

• 剧本式测试的机械性特点导致测试人员的功能性被削弱，测试人员的可替代性被增强，从而引发测试人员的职业危机[9][10][11]。

经验告诉我们，好的测试设计不仅仅依赖的测试技术，测试人员的经验和智力性创造也发挥着重要作用[12][13][14]。

为了提高测试工作的效率，充分发挥测试人员在测试工作中的智力性，“探索性测试”在剧本式测试的包围圈中异军突起。

探索性测试最早是由测试专家 Cem Kaner 博士在 1983 年提出，并发展成为一门学科[15]。

它指的不是某种具体的测试技术，而是一种自由的测试风格或者说测试思维技术，强调测试设计和测试执行同时进行，其本质是边学习、边设计、边测试、边思考[16][17]。

经过不少学者的研究和总结，探索性测试相较于剧本测试的优势已经十分明显。例如：

• 探索性测试能够发现更多数量、更多类型、更严重的缺陷[4][6][21][22][23][24][25][26][27][28]；

• 探索性测试能够降低缺陷误报率、提高检测缺陷的效率[4][16][20][24][27]；

• 探索性测试可以让测试人员不受各种先入为主的条条框框约束，能够更好地利用人的创造性、经验能力和技巧[8][10][18][19][20]，还可以帮助测试人员提高对测试的兴趣，激发测试人员积极地学习被测试的系统，并积累关于系统行为和失败的知识以作后用[29][30][31]。

虽然探索性测试有着诸多的优势，但其自身的不足也比较明显。例如：

• 探索性测试在测试结果的评估和测试报告等方面的劣势，使得它并不能完全取代剧本式测试，更多需要的是需要与剧本式测试结合[23][32][33][34][35][36][37]；

• 探索性测试高度依赖于测试人员的技能、经验和领域知识。当被测产品很复杂时，测试人员的技能和领域知识往往就会显得缺乏[23][24]；

• 此外，虽然探索性测试允许测试人员在完成测试工作时自由地使用任何测试方法，并且允许联合多种测试方法（如风险测试、配对测试、需求测试、交叉功能测试等等）完成测试工作[16][38]，但作为一门学科，对探索性测试的专有测试方法研究还是较少。被提及和使用最多的仍然是James A.Whittaker在2009年提出的全局探索性测试方法和局部探索性测试方法[39]。

而今已经10多年过去，时代的发展和技术的进步，对探索性测试方法提出了更多、更高、更新的要求。测试方法的与时俱进是我们不得不考虑的事。

基于探索性的优势和劣势分析，本文讨论的重点在于如何补充和完善探索性测试的测试方法。因此，本文提出一种新的快的测试法，其目的在于更新和补充James A.Whittaker提出的全局探索式测试方法中的快递测试法。

本文结构安排如下：

• 第一章研究背景；

• 第二章介绍James A.Whittaker的快递测试法和本文的新快递测试法思想；

• 第三章详解新快递测试法测试要点；

• 第四章结论。

二.介绍

全局探索性测试作为探索性测试的重要方法，从诞生之日起就被广大学者和研究人员关注。

其“漫游型”测试理念更是让人耳目一新,将探索性测试比拟为城市旅游，从旅游者的角度出发探索被测产品。将被测产品划分为“商业区”、“旅馆区”、“历史区”、“破旧区”等类型进行测试。

尤其是“商业区”，作为产品的核心功能区域，需要测试人员投入较多的时间和精力进行较深入的测试。在《探索式软件测试》一书中James A.Whittaker为“商业区”测试建议了几种测试方法：卖点测试法、地标测试法、极限测试法和快递测试法等等。

为了提高测试覆盖率和更好的测试效果，以及当今快递行业的蓬勃发展带来的启发，本文将目光聚焦到“商业区”测试的快递测试法，拓展出“新快递测试法”。

2.1快递测试法

《探索式软件测试》并没有花很大的篇幅介绍快递测试法如何使用和具体使用方法。只是将数据比拟为需要快递的包裹，告诉我们需要关注包裹在整个快递过程中的变化，也即测试人员使用该测试方法主要需要关注测试数据在整个生命周期的改变，以此判定每个功能节点实现功能的正确性。

例如：初始输入数据data_0，经过功能节点1变成data_1，陆续经过节点2、节点3…变成data_2、data_3…最终输出为data_n。

针对每个功能节点的功能，判断data_1、data_2、data_3……data_n是否正确（包括数据类型的转换是否正确、计算值的结果是否正确等等）。

但我们会发现，快递测试法思想来源于很多年前的联邦快递，如今多年过去快递行业和快递模式发生了很大的改变，需要我们以新的目光审视是否需要更新和改进快递测试法。

并且，从较短的快递测试法介绍来看，快递测试法只提到了“数据”这一需要重点关注的测试对象，而忽略了在“数据”传输过程中的交互对象和及其活动，以及交互活动发生时引发的一系列状态变化等等。

试想，没有仓库人员、没有快递人员，包裹能够正常传递吗？试想，包裹在传递过程中，难道只有转发这一个行为吗？显然不是。由此，引出了我们本文讨论的新快递测试法。

图1 快递测试法类比示意图

2.2新快递测试法

“新快递测试法”主要是受当今快递模式的启发。相比十多年前的快递模式，当今的快递模式，已经有很大的改变，比如：实时追踪，轨迹记录等等。

此外，时效性和快递量等方面也发生了巨大的变化。

“新快递测试法”相较于James A.whittaker的“快递测试法”区别在于，它不仅关注测试数据，还关注测试数据传递过程中的所交互的对象及其活动、交互活动发生后的状态变化，以及交互活动时序等等方面。

让我们以一个形象的例子来说明：将数据比拟为待快递出去的包裹，包裹（数据）在传递过程中会经由不同的运输人员（交互对象）运送（交互活动），包裹每到达一个站点，快递系统会更新包裹的位置信息（交互活动发生后的状态变化），并交由仓库人员分配、转发或投递（交互活动）……最终经过快递人员派送（交互活动）到达客户（交互对象）手中。

我们在测试分析和测试过程中使用“聚焦式观察法”，即：每次测试将注意力投注于某一个测试功能点，以此达到高效和深入地测试。

我们参考包裹的快递过程，以此拆解“新快递测试法”中需要关注的测试类型或测试要点。新快递测试法的测试对象主要有以下几类：

• 包裹，即数据；

• “运输人员”、“快递人员”、“仓库人员”、“驿站包裹收发人员”等，即交互对象；

• “快递接收、运输、转发、投放”等，即交互活动；

• “位置信息更新”等，即内外部状态；

• “快递人员先派送，客户才拿到包裹”等，即活动时序；

我们把交互活动和交互对象放在一起讨论，因为交互对象是根据交互活动的类型来划分的。因此，新的快递测试方法的测试类型如下图所示。

图2 新快递测试法测试类型示意图

该文将从数据、交互对象、交互活动、内外状态、活动序列等方面阐述新型快递测试方法的关键点。

三.测试要点

3.1针对“数据”的测试

在每件物品在成为包裹的时候，都会对物品进行分类打包，根据物品的种类、大小、运输方式、运输路径等进行计价，并且填写收、发人等相关信息。我们可以把这个过程称为“包裹的初始化”。

在包裹的运输途中，需要定时检查包裹包装的完整性、物品的完整性，并记录包裹到达的位置和时效更新。我们可以把这个过程称为“包裹的运输过程查验”。

包裹到达客户手中，需要客户验收包裹（例如，信息核对、物品完好性检查等等），如果客户不满意还可以提起投诉等等。我们可以把这个过程称为“包裹的验收”。

由此，投射到测试活动中，针对数据的测试要点拆分结果如下表格所示。

表1 针对数据的测试要点和样例

包裹	测试要点	举例
包裹的初始化，即数据的初始化	包裹的大小，即数据的大小	比如，不同大小的数据测试，可采用等价值测试法，包括数据的边界值测试和定义的数据范围测试；
	包裹的类型，即数据的类型	比如，不同数据类型测试，包括符合定义的类型和不符合定义的类型；
	运输方式的选择，即数据计算方式或运算模型	比如，大数据的流式计算和批式计算等，不同的计算方式数据结果的实时性不同；
	运输路线的选择，即数据传输路径的选择	主要针对代码内部的分支测试，比如if…else，switch等；
	运费、失效的预估，即预估数据需要的资源	比如，硬件资源磁盘空间、内存空间等；
	收发人的信息，即输入输出方信息/告警通知人	数据的输入方和输出方信息记录。比如，日志中打印的接口调用信息（包含接口调用者和请求返回内容），可便于信息追踪或告警通知；
	多个包裹租户，即数据的组合	比如，接口需要多个参数；
	违禁物品检查，数据合格性检查和合规性检查	比如，常用变量的初始化定义或数据的类型等合规性检查；
包裹的运输，即数据的传输	包裹的完整性检查，即数据封装的完整性和友好性	比如，接口请求内容数据封装的完整性，检查是否遗漏数据；
	包裹内物品的完好性，即数据的完好性	比如，多次使用的某个公共变量是否在计算过程中产生数值越界或类型变化，或是否空值导致其他引用失效；
	包裹的位置跟踪，即数据传输到达的位置跟踪	比如，日志中打印某个接口调用跟踪（xx收到请求，xx处理请求，xx处理完毕返回响应）；
	包裹的时效，即数据传输的效率	比如，分段式计算某个接口的调用时间消耗；
包裹的投递，即数据的验收	包裹验收，即数据需求验收	比如，验证数据是否与接口定义输出一致，如异常输入数据产生异常数据null等；

3.2针对“交互对象及其活动”的测试

包裹在运输和分发过程中，会和“运输人员”、“快递人员”、“仓库人员”、“驿站包裹收发人员”等发生各种交互行为。

因此，在测试过程中，我们除了关注数据本身，还需要关注同数据发生交互行为的其他对象或功能模块。

表2 针对交互对象及其活动的测试要点和样例

包裹交互对象	测试要点	举例
“运输人员”，即数据传输/转发功能	包裹校验，即数据检验	比如，待传输数据合规性检验；
	“包裹运输/转发的正确性：不同的包裹地址运输/转发向不同的地方”，即数据传输/转发的正确性	比如，模块内部的正确传输/转发，不同输入数据的if…else跳转，switch跳转等； 比如，模块间的正确传输/转发，异常值或错误的告警而非流入正常流程；
	“包裹运输/转发的效率性：收到包裹及时转发，人力或非人力原因导致的延时或路线及时调整，数据传输/转发的效率性	比如，转发过程中是否有无效的等待； 比如，是否有无效锁影响效率； 比如，传输过程中的某个传输功能节点异常自动恢复；
	“包裹运输/转发的安全性：私密信息注意隐藏，运输/转发过程包裹消毒等”，数据传输/转发的安全性	比如，传输/转发过程中，敏感信息（密码等）注意加密隐藏；
	“包裹运输/转发的质量性：生鲜物品的保冻措施，天气异常的防护等，数据传输/转发的质量性	比如，传输/转发过程中环境干扰导致失败的重试性； 比如，模块内部数据的受保护性；
“仓库人员”，即数据存储功能模块	仓库人员权限划分，即数据存储功能权限划分	比如，涉及多个模块时，不同功能模块存储权限不同；
	包裹查验，即数据查验	比如，检查数据格式是否符合存储要求；
	包裹存储方式差异，即数据存储方式差异	比如，临时存储（缓存）和本地存储（磁盘存储）、远程存储等；
	包裹入库信息记录，即数据存储信息记录	比如，日志打印或数据库表格记录；
	包裹存储的完整性，即数据存储的完整性	比如，数据存储过程中的完整性，未发生数据丢失；
	包裹存储的安全性，即数据存储过程的安全性	比如，存储过程的安全性（如防干扰丢失等）；
	包裹保管的安全性，即数据存储后的安全性	比如，存储后的安全性（如数据断电保护等）；
	包裹出库方式差异，即数据消费方式差异	比如，数据库的pull和push消费模式；
	包裹出库信息记录，即数据消费信息记录	比如，日志打印或数据库表格记录；
	包裹出库的完整性，即数据消费的完整性	比如，指定消费某个时间段的数据；
	包裹出库的安全性，即数据消费的安全性	比如，消费时线程锁定防止同时消费；
“快递人员”或“驿站包裹收发人员”，即数据收入或输出功能模块	包裹检验，即数据检验	比如，数据完整性检验；
	包裹打包/投放，即数据封装/输出	比如，前端输入输出和后端输入输出封装（如功能接口和显示页面等）；
	包裹查找，即数据查找	比如，接口查询等；

3.3针对“内外部状态”的测试

交互活动发生时，会引起“包裹”自身和交互对象、以及所处环境的状态变化，针对状态的测试有：内部状态测试和外部状态测试。

内部状态主要是数据本身的状态变化，例如：数据量的增减、数据类型的改变、数据引用指针的变化等等；外部状态主要是抛开数据，其他对象和环境状态的变化。

例如：交互对象数据类型的变化、交互数据量的增减，环境状态的变化（如内存使用量的变化）等等。

表3 针对内外部状态的测试要点和样例

包裹活动状态	测试要点	备注或举例
“状态位置更新”，即数据外部状态	交互对象状态	如：数据指针的变化，数据交互活动引起的交互对象相关状态变化等；
	环境状态	比如，运行环境状态变化（如内存、磁盘状态等）；
“包裹内部物品状态扫描”，即数据内部状态	数据本身状态	如：组合数据的顺序、数据增删、类型变换；

3.4针对“活动时序”的测试

交互活动的发生是有时序的，因此从时序角度出发，又可以划分为：先后时序和并行时序。

先后时序主要是指活动发生的先后，例如：先接收数据再转发；并行时序指存在活动的并发进行，例如：多线程并发处理。

表4 针对活动时序的测试要点和样例

快递活动时序	测试要点	举例
“先收包裹再运输”，即先后时序	交互活动的先后时序	比如，单线程处理的活动先后顺序；
“多个快递人员同时分配多个包裹”，即并行时序	交互活动的并行时序	比如，多线程并发处理的活动；

如上所述，我们可以参照包裹运输过程，从数据、交互对象和活动，以及数据的内外部状态和活动的顺序等方面进行软件测试。此外，本文的上述内容还对测试类型进行了详细的测试点划分，并给出了几个测试示例。

新快递测试方法的要点可以总结如下：

图3 新快递测试法测试要点总结

四.结论

本文提出的新快递测试法在概念期就已经投入项目进行尝试，并在工作中不断完善。

进行了若干试点项目，测试人员使用新快递测试进行探索性测试，并结合测试结果不断调整和优化测试设计。最终取得了较好的测试效果。

为了比较传统的快递测试法和新快递测试法的测试效果，指派了一名有着一定探索性测试基础的测试人员在其负责测试的模块中使用快递测试法和新快递测试法进行测试。

其结果是，使用快递测试法设计出31条用例，发现缺陷6个，而使用新快递测试法则设计出73条用例，发现缺陷17个。

并且新快递测试法设计的用例中，不乏有许多该测试人员习惯性忽视的测试要点，比如：交互行为引起的环境状态、数据传输过程安全性等等。

表5 快递测试法和新快递测试法结果对比

	快递测试法	新快递测试法
设计用例	31	73
发现缺陷	6	17

从这些试验中得出以下结论:

• 使用新快递测试法可以提高测试覆盖率，帮助测试人员挖掘更多的测试要点；

• 使用新快递测试法可以发现更多的缺陷，尤其是潜在的缺陷。测试人员习惯性思维往往将测试重点放在功能测试、接口测试，或根据需求文档进行测试，容易忽略针对数据传输过程中的交互对象或交互行为，以及状态变化等进行测试；

• 由于新快递测试法是对James A.Whittaker全局探索式测试方法中快递测试法的更新和补充，结合其他探索式测试方法进行测试将取得更好的效果。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。