【测试理论】如何做好探索性测试（二）——增加维度回顾主要包括：常规测试计划和探索性测试相辅相成，在工作中，寻找探索性测试点的时机（需求回顾，用例回顾），寻找那些产品中的变量，比如：可数事物，地理位置，文件和存储，时间点等，收集用户反馈（操作的漫无目的性和随机性）等。今天我们将继续从不同维度引入探索性测试，深挖测试点。其中，还有更多的理论。希望大家耐心阅读。同时，我也推荐大家阅读探索性测试方面的书籍，比如：《探索吧，深入理解探索式软件测试》。因为我的文章也是参考了这本书。读完这本书，我深深感受到，探索性测试确实可以作为我们常规测试的补充，因为它确实可以为我们提供不同的思路，从而帮助我们更深入地挖掘问题。改变顺序和交互想象一下我们过去经历过的场景：你负责测试某个功能模块，它有一些表单页面。当你对功能模块非常熟悉时，你应该使用相同的数据并快速输入，比如：你的名字总是用周杰伦，你的地址总是用xxx街22号等，或者你总是用登录app后切换到首页某个功能列表等。主要有两个原因：心态和习惯，所以要有效地做探索性测试，就必须跳出这个套路。我们都知道名词和动词。一个正常的句子通常包含名词、动词和形容词。对于被测系统，我们可以随便找出名词和动词。以邮件客户端的测试为例（本书Examples中），名词或事物可能包括：邮件、附件、联系人、账户、文件夹；对应的动词有：create,send,edit,forward,copy,delete,move等，可以在表格中全部列出来，可以得到下图所示的表格（可以在Excel中列出）:当然上面只是列举了一部分组合场景，大家也可以根据情况进行组合。更多测试点可供探索。不过需要注意的是，有些组合结果看似不合逻辑，但我们不能就这么放过这样的组合，而是应该多找找看，有没有什么办法可以解释这些无意义的组??合，让我们找到点探索。比如上表中的“导出签名”似乎没有明确的意思，但是可以考虑直接在邮件客户端中导出保存签名，或者复制粘贴到其他地方是否可以理解用于存储。没有任何线索。随机导航回想一下，当我们测试一个应用程序时，我们总是点击桌面上的icon图标来打开被测试的应用程序。您是否尝试过从历史应用程序中打开被测试的应用程序？还是通过adb命令打开被测应用？所谓随机导航，其实就是需要你在被测系统中收集完成同一操作所需要的方法，然后记录在一个表中。比如把所有的情况都列出来之后，就可以开始探索不同的操作方法了。当然，你也可以将不同的操作方式与用例场景结合起来，也能找到一些让你惊喜的测试点。角色所谓角色，是指将测试系统的用户群体进行细分，进而抽象出不同的角色。针对不同的角色，可以在测试时想象他们的操作习惯、心理变化等，探究他们在操作软件时会进行哪些操作。以手机淘宝APP为例。淘宝的用户群体非常广泛，所以也给了我们足够的空间去设计角色。比如下面三个人物：小王，今年20岁，程序员，重度网民，能熟练使用APP，适应APP的交互体验，遇到各种问题，愿意尝试自己搜索解决。今年40岁的老张，以前在智能手机上用过微信聊天（只用于聊天）。他没有耐心，脾气暴躁。他在使用软件时会很不耐烦。今年50岁的老王，刚从老年机换成了智能机。他喜欢学习，所以他会点击手机应用程序上的每个功能。想象一个场景，比如：手机淘宝在使用某个功能的时候很卡，反应很慢，所以上面三个人物的反应也是不一样的：小王：因为对互联网产品已经很熟悉了，他可以理解慢的可能原因是什么，可能是网络的原因，也可能是app本身的原因，所以他会尝试等待一段时间，如果失败了，他会尝试重启app，clean调内存等等。老张：虽然用过微信聊天，但不太明白为什么微信响应慢，会因为缺乏耐心疯狂点屏。老王：他也不明白为什么app反应慢，但他有耐心，喜欢学习。会进行不同的尝试，比如：按home键切换前后。如果你的产品有非常详细的用户数据（年龄、职业、性别等），那么你可以更好地设计角色。在做探索性测试时，可以暂时让自己扮演相应的角色，发挥自己的想象力，注意角色试图做什么，然后观察软件如何反应。探索实体与实体之间的关系系统和软件实际上是由实体和实体组成的，所以在进行探索性测试时，如果能够根据它们之间的关系挖掘一些测试点，也可以帮助你发现很多问题。了解被测系统中的实体、属性和依赖实体：实体也可以称为事物，是一个系统或软件的基本组成部分。比如一个账号，一个头像，一条数据等等，都可以叫做实体。小心留意系统中隐藏的实体，例如网页登录后创建的会话。属性：实体有相应的属性，例如：邮件有收件人、主题和正文，商品有价格和数量等。依赖性：实体和实体之间一定有关系，可能存在依赖关系。如果看到这样的句子格式：“xxxhasxxx”，通常可以找到依赖关系，例如：一个订单有多个item项，一个产品有多个供应商等。有了上面的基本概念，我们就可以得出关系实体之间的图表（ERD）。如果现在有一个库存管理系统，系统中的每一项库存数据都对应着某个供应商，它们之间的关系图如下（其实类似于数据库中表之间的关系图）：CRUD方法对于熟悉数据库的人应该不陌生CRUD是指在软件中对数据进行增、删、改、查等操作。在探索性测试中，还可以发现实体在增删改查时引起的一些变化，主要有以下几个方面：数据变量的增删改查：在增删改查时，改变实体的属性值。例如：新建一条库存数据时，填写所有字段，然后尝试去掉一些值，更新库存数据。其他CRUD方法：这个和上面说的随机导航类似。有必要找到不同的方法来对实体执行CRUD操作。比如新建一个文件，可以直接通过新建菜单新建，也可以为“新建文件”选择现有文件的“另存为”。再比如，在某些场景下，系统会触发自动提醒消息的创建，和用户手动触发创建提醒消息，他们所经历的工作流程可能不同零依赖、单依赖、多依赖CRUD：主要考虑实体之间的依赖关系，例如：你创建一个独立的实体没有给它添加依赖，检查系统数据是否正常运行；另外，如果你删除了一个有很多依赖的实体，那么观察它的依赖是否也被移除了。在做上面的CRUD探索时，你应该总是关注服务器的日志，看是否有异常，从而发现隐藏的问题发现状态和转换我们经常会遇到一些bug极难发现的情况重现，无论是非常偶然的灾难性错误，还是无意中使用损坏的数据。这种情况往往恰逢短暂的脆弱期，因为它短暂而特殊，所以你可能会花很多时间去重现它们而白白返回。问题的关键在于，我们如何发现并利用出现问题时的脆弱期。幸运的是，在状态模型的帮助下，系统的分析方法可以用来阐明我们如何探索这些脆弱时期。事件触发的状态转换事件可以触发系统中实体状态的转换。比如你在软件界面点击某个删除按钮，就会触发系统中某条数据的删除。在查找事件时，需要注意以下几点：ExternalGeneratedevent：来自软件外部的任何事件，例如：对于监视文件系统目录结构的软件，更改文件系统的目录结构就是一个例子外部生成的事件。系统产生的事件：这个比较容易理解。是系统为完成软件功能而产生的相应事件，如：导入导出数据、登录验证用户等。时间事件：与时间相关的事件，如超时、特定时间点的事件等。当每个事件发生时，都会有相应的状态变化。状态模型图以某系统的登录模块为例，展示一个状态模型图：这样可以将系统或软件分成很多模块，每个模块都可以构建一个状态模型图。为了更有针对性，不分散，状态模型图的构建可以从以下几个方面来考虑。重点：可以控制状态模型的范围，只针对一个target，比如一个function或者workflow，比如上图中的login流程，涉及三种状态：loggedout，loggedin，loginin。总之，一定要让你选择的模型是可控的，不要过于分散。确定一个角度：参考模块中某个角度的状态模型图。比如你用微信聊天，别人跟你聊天是一个角度，你主动跟别人聊天是另一个角度。识别特定角度也有助于缩小状态模型的范围。确定系统抽象层次：简单来说，对于小的需求，状态转换可以描述的越详细越好；对于比较复杂的系统，可以进行高度的抽象，把中间的一些小细节抽象成一个大的状态。.例如：在上面的登录模块例子中，如果依赖了很多其他的服务或者应用，可以将这些依赖的服务统一起来做一个登录（中间）状态。探究状态模型有了上面绘制的状态模型图，你可以把它当成一张地图，找出两种状态之间的所有路径，也可以直观地看到导致状态发生变化的事件。接下来我们一起来看看吧。如何找到状态之间的所有路径。以开启和关闭这两种常见状态为例，你可以考虑：关闭变成开启的方式有哪些？由用户手动启动。操作系统启动时自动启动。许多软件都有守护进程，由它们启动。其他软件调用被测软件。打开和关闭的方法有哪些？由用户手动关闭。强行杀死进程。关闭操作系统的屏幕。操作系统直接关闭。所以有了状态图，并且知道了如何探索状态之后，我们就可以结合难以重现的bug，在实际运行中画出其关联的状态模型图，进而探索从正常状态到异常状态的各种可能性。状态表另外，还可以将状态模型图转换成状态表，这样可能有更多的机会发现状态的转换（状态模型图可以帮助我们从整体上理清被测系统的各种状态）.假设我们现在有一个闹钟，它的功能界面如下：如图所示，它的主要功能包括：开启和关闭闹钟，设置闹钟贪睡功能，按下贪睡键，9点后闹钟会再次响起几分钟的沉默。状态模型图如下：状态模型图转换成表状态图如下：然后结合上面的状态表，我们可以探索，例如：setting+timetopoint—>表示当前时间有刚刚设置，会发生什么？我们要探索的所有不确定性都标记为？？？,并为不需要探索或不合逻辑的状态组合标记N/A。要探索生态系统，我们要测试的软件一定不能单独存在。首先，它必须在操作系统上运行，然后它需要使用内存、文件系统、数据库和网络连接等系统资源。此外，某些软件还可能与其他软件或外部服务通信。我们之前的讨论是基于内部系统，但从系统层面考虑软件同样重要。画一个生态系统图软件的生态系统图包括软件所在的环境，所有的入口和所有的外部依赖。我们可以将其作为探索地图，围绕连接和依赖关系进行有针对性的系统探索，从而发现与系统各部分相关的外部风险。我们以一个信用卡支付的web系统为例：上图中各个元素的含义如下：中间的大圆圈代表软件内部依赖和外部依赖的边界。圆圈右侧外侧代表软件的用户分类，其中web系统包括管理员和普通用户。圆圈的左外侧表示软件所依赖的组件（或系统）。这里只列出了“支付网关”，但是我们测试的软件应该比这个复杂很多，应该有很多依赖，都可以列在系统图中间。圈内是软件的内部实现，主要考虑软件的数据存储，软件的架构设计（根据情况，如果没有探索的价值），以及软件的部署方式软件。此外，还可能包括系统对外提供的接口或组件。画系统图的时候，如果不是特别清楚，可以咨询开发，或者找他们要系统设计图。通过这个系统图，我们可以直观的了解软件的整个运行环境，从而找到可以探索的测试点。探索信任边界所谓信任边界简单的说就是：我们信任我们所依赖的外部系统（数据、接口、网络）。以上面的生态图为例，我们相信圈外的“支付网关”能够为我们提供正确的数据。但是，我们在做探索性测试的时候，一定要努力打破这个“信任边界”。对于不同情况下的外部依赖，我们可以探讨以下几种情况：网络数据与网络断开，系统的一部分被放置在防火墙或其他网段上。边。降低网速（弱网测试）。删除文件损坏文件的内容使文件变得非常大将文件设置为只读删除文件的所有权限填满硬盘驱动器以致无法写入文件。外部依赖接口mock接口，使接口不按规则返回数据。让外部依赖接口挂掉。让外部依赖接口返回不同状态码的数据。小结由于本文内容较多，且多为理论知识，我们简单回顾一下上面介绍的内容：第1节强调要突破常规操作系统，通过名词和动词的结合寻找探索点。此外，我们还可以专注于软件设计。不同的字符。第二节介绍了软件系统中的实体、属性和依赖关系，以及它们在增删改查过程中的可探索点。第三节介绍了软件系统中的各种状态。当我们进行探索性测试时，我们可以找到不同状态之间的路径，更重要的是，我们可以找到相对隐藏的、短暂的中间状态。第四节介绍了软件系统的外部环境，根据它们的变化观察软件系统的变化。探索性测试目前多以理论为主，但看了相关的学习资料后，还是觉得它确实是我们做常规测试时的重要补充。后面会慢慢整理出一些实用有效的。方法。但是我觉得理论知识同样重要，希望大家有所收获。
