“探索式软件测试”是软件测试专家Cem Kaner博士于1983年提出的，并受到语境驱动软件测试学派（Context Driven Testing School）的支持。由于符合快速提交的理论，且随着近年来敏捷开发的出现，探索式软件测试被重新提出，并且受到广泛重视。
探索式测试Exploratory Testing是一种自由的软件测试风格，它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
6.1 探索式软件测试中用到的一些方法
6.1.1 表单输入的测试探索
1.超长或不符合格式的字符输入的测试探索
由于表单输入的数据最终一般都存入到数据库中，所以对于输入的数据，一定要对其长度或类型进行限制。输入一个超长或不符合格式的字符串，一般有以下4种处理方式。
（1）在输入界面中被锁定
如，表单要求输入的字符串最长长度为40，当输入第41个字符时，页面是不允许输入的。
再如，表单只允许输入阿拉伯数字，如果输入了一个字符“A”，页面也是不允许的。
（2）在鼠标失去焦点后，利用Ajax和JavaScript技术立即给出错误提示
（3）输入后，在提交表单时，输入界面会提示表单中有超长或不符合格式的字符，并且表单不允许被提交
（4）输入后，在提交表单时，会在另外的页面中提示表单中有超长字符或不符合格式的字符被输入，并且表单不允许被提交
如果在表单输入了超过长度或不符合格式的字符串，提交后界面没有任何提示信息，甚至出现系统奔溃，或者出现数据库发生异常的英文日志显示在页面上，那么这显然是一个Bug。
如果符合以上4中处理，从安全性角度考虑，需通过开发工程师查看对应的代码，尤其是数据存储到数据库之前，确认程序是否对输入字符的长度或类型进行再一次校验。举个例子，输入页面的文件名为table.html，后台存入数据库操作的文件名为insert.jsp。一个黑客为了破坏这套系统，它用其他软件制造了一个表单页面代替table.html。在他的页面中输入超过长度或者不符合格式的数据，然后通过insert.jsp提交到数据库中，由于insert.jsp没有对输入字符进行校验，从而造成系统瘫痪。
案例6-1 文本框的输入
某文本框只允许输入长度为5-20的字符串，请设计超长或不符合格式的文本框的测试用例。
输入数据 | 期望结果 |
4个'a' | 给出出错提示 |
5个'a' | 数据正确录入 |
20个'a' | 数据正确录入 |
21个'a' | 给出出错提示 |
4个'我' | 给出出错提示 |
5个'我' | 数据正确录入 |
19个'我' | 数据正确录入 |
20个'我' | 数据正确录入 |
1个空格+4个'a' | 给出出错提示 |
1个空格+5个'a' | 数据正确录入 |
1个空格+4个'我' | 给出出错提示 |
1个空格+5个'我' | 数据正确录入 |
1个空格+20个'a' | 数据正确录入 |
1个空格+21个'a' | 给出出错提示 |
1个空格+20个'我' | 数据正确录入 |
1个空格+21个'我' | 给出出错提示 |
1个空格在4个'a'中间 | 数据正确录入 |
1个空格在3个'我'中间 | 给出出错提示 |
1个空格在19个'a'中间 | 数据正确录入 |
1个空格在20个'我'中间 | 给出出错提示 |
2.保留字符输入的软件测试探索
表单输入的数据，除了存储倒数库中，还会显示在界面上。例如在修改个人信息的案例中，系统会把以前输入到数据库中的数据显示到界面上，这样便于用户对信息中不合适的地方进行修改。要对这种类型的软件测试进行探索，首先要搞清楚这套产品对表单输入数据使用的是何种方式输出？这种输出方式中存在哪些保留字符？输出的方法是用HTML语言显示的，HTML保留字符有：<、>、“、‘、&、空格、回车等。HTML显示这些字符时可以用其他字符进行替换。一个正常的操作是从数据库中输出保留字符以后，程序对这些保留字符通过正则替换转码为HTML重对应的可以显示的字符串，如“<”转换为<，空格转为 ……如果在表单中输入了这些字符，或者输入一段含有这些字符的HTML代码或者JavaScript代码，如<a href="http://www.sina.com.cn">进行新浪</a>，然后在显示页面中查看输出的格式是否正确，如果不正确，或者出现显示页面错乱，甚至执行了JavaScript语句，这属于XSS注入，肯定一个Bug。保留字符的测试用例举例如下表。
输入数据 | 期望结果 |
<script>alert(document.cookie)</script> | 显示'<script>alert(document.cookie)</script>'，不执行javascript语句alert(document.cookie) |
6.1.2 模糊查询输入框输入数据的测试探索
目前除了一些专业的搜索引擎（如Google、百度）以及流行的大数据存储方式采用非关系型数据库或者NoSQL技术进行存储，对于大多数软件系统，通常还是采用传统的关系型数据库进行存储。若一个用户想查询标题中含有“云计算”的标题，再通过单击相应标题查看文章内容，通常对应的SQL查询语句为：select url,title,content from paper where title like "%$title%';（$title为模糊查询文本框提交过来的字符串，这里为“云计算”）。下面深入讨论一下SQL语句中%这个关键而特殊的模糊查询字符，假设用户在模糊查询输入框中输入%，而程序没有对%进行特殊处理，上述的SQL语句就变味select url,title,content from paper where title like '%%%'，这样的查询输出结果不是把文章标题中含有%字符的标题输出，而是把这个数据库表中所有的记录都给输出来了，这属于SQL注入，也是一个Bug。
案例：模糊搜索。某文本框为根据关键字进行模糊搜索，可以设计测试用例如下表所示。
数据 | 期望结果 |
“软件测试” | 显示含有“软件测试”标题的所有文章 |
“ 软件测试” | 显示含有“软件测试”标题的所有文章 |
“软件测试 ” | 显示含有“软件测试”标题的所有文章 |
“软件 测试” | 显示含有“软件 测试”标题的所有文章 |
"%" | 显示含有“%”标题的所有文章，不显示所有文章 |
10万个a | 系统不奔溃，给出友好的提示信息 |
空字符串 | 按照系统要求，什么都不输出，或输出所有记录 |
6.1.3 对文件的探索
系统中需要上传文件，有如下两种情形。
（1）选择文件直接上传。
（2）选择文件，按【上传】键，然后完成上传任务。
案例：考虑（2）情形的上传文件，测试用例如下表。
描述 | 期望结果 |
选择的文件被删除： 1.选择文件a.txt 2.删除文件a.txt 3.按【上传】键 | 提示信息：a.txt已经被删除 |
文件的内容被损坏： 1.建立文件a.txt 2.将文件名改为a.jpg 3.选择文件a.jpg（这里要求只能上传图片格式文件） 4.按【上传】键 | 提示信息：a.jpg格式不正确 |
使用空文件 1.建立一个文件名为a.txt的空文件 2.选择文件a.txt 3.按【上传】键 | 提示信息：文件不能为空的信息 |
系统要求文件不能超过2MB 1.建立一个符合格式的超过2MB大小的文件 2.选择这个文件 3.按【上传】键 | 提示信息：文件大小不能超过2MB |
用其他软件打开需要上传的文件 1.用photoshop打开a.jpg 2.选择a.jpg 3.按【上传】键 | 根据用户需求 1.a.jpg倍上传 2.提示信息：a.jpg已经被其他软件打开，请关闭后再上传 |
6.1.4 登录界面的测试探索
对于登录页面，除了可以使用之前介绍的方法外，还需要对SQL注入进行测试。如果用户知道或者猜到系统数据库的表明，那就更可怕了，如在密码栏中输入：“*;DROP TABLE USER;”，如果程序中没有做合适的处理，这样的数据库中的数据表就会被删除。改进后的登录页面测试用例见下表。
编号 | 用户名 | 密码 | 验证码 | 期望结果 |
1 | Tom | khnygh | 243546 | 提示：用户名或密码错误 |
2 | Kenny | oooo | 243546 | 提示：用户名或密码错误 |
3 | Kenny | khnygh | 12345 | 提示：验证码有错误 |
4 | Kenny | khnygh | 243546 | 进入系统 |
5 | 1111 | 2222' or 1=1;-- | 123456 | 提示：用户名或密码错误 |
6.1.5 根据机器的声音探索
通过机器的声音有些时候也可以发现一些软件缺陷。
案例：测试中的望闻问切。
甲同学晚上加班进行一个模块的性能测试，测试数据的结果总不能令他满意，他不断地进行复测，但总找不出原因。由于当时已经接近21:00，公司里只剩下他一个人，非常安静。他突然发现每经过一段时间，硬盘总是发出一种单调并且奇怪的声音，他立刻意识到时硬盘的问题，经过排查，是硬盘操作太频繁造成。第二天他让开发工程师查看后，发现这是由于开发人员修改一个缺陷所引起的，这个缺陷是数据经常从缓存中读取，准确性不高，而改成从硬盘中读取，当准确性上去后，性能却就成为另外一个问题。
对于某些测试，需要通过“切”的方法进行测试，如摸机箱或者摸嵌入式设备的外部查看是否过热等方式。
6.1.6 通过查看Log日志探索
通信系统、嵌入式系统等是没有用户界面的，对这类系统进行探索式测试时，查看系统日志是一种最好的选择。在Linux/UNIX系统中，可以对日志文件进行以下操作（假设log日志为a.log）：
>tail a.log | grep error
>tail a.log | grep fail如果有查询结果，就可以顺藤摸瓜，查找问题所在。当然，并不是通信系统、嵌入式系统中才可以用这种方法，其他系统也可以使用，甚至会挖掘出一些隐藏的、没有爆发的缺陷。
案例：java.net.SocketException。
在某网站接口测试中发现一个自动化测试用例没有通过，经过使用>tail a.log | grep error，发现如下结果：
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:121)
at org.apache.jk.core.MsgContext.action(MsgContext.java:301)通过这个结果，开发人员进一步查询，发现到问题的根本原因是MySQL的链接超过8小时，MySQL自动断开连接造成的。
6.1.7 在开头/结尾处进行探索
在文件开头或者结尾处进行操作往往也会发现缺陷。
案例：文章结尾的输入。测试一个文本编辑软件，在编辑的文本中的其他地方插入一些文字都没有问题，但是在文本的最后插入一些文字，再保存后重新打开，被插入的文字不见了。
案例：移动记录到第一条。通过上下箭头试图把记录上下移动一个单位，测试发现当移动到非第一条时没有问题，但是移动到第一条时，系统管理科卡主没有任何反应。经过排查，发现是由于开发人员在计算时把第一个标记为的“0”记为“1”造成的问题。
6.1.8 多次执行同样操作进行探索
这也是一种经常发现缺陷的情形。比如，软件可以打开任意多个窗口，你试图打开这样的10个、20个、50个，甚至100个窗口，然后进行操作，看系统会有什么反应。这样的问题往往会导致响应速度变慢，甚至系统宕机。
案例：ERP软件多窗口操作。某ERP软件可以同时打开多个窗口来编辑库存信息。测试工程师小张打开1-30个窗口没有问题，但是打开第31个窗口后，系统发生了死机的情形。后来经需求、设计、项目经理、开发、测试等一起讨论，综合各方面因素决定，最多只允许打开20个窗口，当用户试图打开第21个窗口时，系统将给出“本系统最多只允许打开20个窗口”的提示信息。
6.1.9 通过复制/粘贴进行探索
在文本框中编辑时，往往会用键盘手工进行输入，如果通过复制/粘贴进行操作，也许会发现一些缺陷。一种类型的缺陷是在复制时复制了字符串前后的空格，而程序没有对其进行判断，显示时把前后空格显示出来。
另外一种情形如图3-1所示。
这种类型的文本框不允许通过鼠标进行复制和粘贴，必须使用Ctrl+C、Ctrl+V。对于这种情形，需要认真测试。另外，这种情况下，从安全角度考虑：可以输入简单的HTML标记符，如<a href="...">、<b>、</b>、<br>、<font size="1">、<font>……，但是不允许输入存在安全风险性的标记，如<script>、</script>、document.cookie、alert……等。
案例：富文本编辑器安全性测试。
操作 | 期待输出 |
进入HTML编辑框，输入“<a href="https://www.baidu.com”>百度</a> | 显示“百度”，点击百度超链接后进入百度网站 |
输入“<font size="4”>百度</font> | “百度”显示为4号字体 |
输入<script>alert(document.cookie)</script> | 显示提示信息：<script>，</script>，document，cookie，alert等敏感字符不允许输入 |
输入<a href="#?id=1&drop table customer"> | 显示提示信息：drop table等明恩字符不允许输入 |
6.1.10 通过测试结果进行探索
通过某个测试的测试结果，还可以设计出更多、更深入的测试用例。比如，在用户注册时，发现【取消】按键的功能没有起作用，这样就必须对系统中所有表单提交功能中，对含有的【取消】按键都进行测试。再如，在对电子商务测试过程中发现，用支付宝存款存在问题，那么就必须测试微信、银行借记卡、银行信用卡付款是否同样存在问题。另外，根据软件缺陷的80/20法则，如果在某个模块中测试出很多问题，那么就需要对这个模块进行更详尽的测试，以便发现更多的缺陷。
案例：关于删除的缺陷。测试某个网站。
测试步骤：
（1）登录系统；
（2）对某一篇文章非本人提交的评论点击删除；
（3）提示：你没有权限进行删除操作；
（4）该评论没有被删除；
（5）跳转到其他页面；
（6）返回到刚才试图删除的文章页面。
结果：该评论已经不存在。
根据这个测试结果，考虑到本网站还有BBS模块，于是测试工程师对BBS帖子的删除进行了类似的操作，发现了同样的问题。
