浅谈探索式测试中用到的一些方法
作者: 顾翔
"探索式测试"是测试专家Cem Kaner博士在1983年提出，并受到语境驱动测试学派 （Context
Driven Testing
School）[1]的支持。随着近年来敏捷开发的出现，探索式测试的理论由于符合快速提交的理念，也被重新提出，并且受到了广泛的重视。其实我们以前在测试中也有意无意地使用到探索式测试中的一些方法，就是没有把它升华到一个理论的高度。探索式测试（Exploratory
Testing）：是一种自由的软件测试风格，强调测试人员展开测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。本文不涉及到探索式测试的详细定义，思想以及一些相关的模型（这些详细定义，思想和模型可以通过互联网或者目前出版的一系列书籍中找到），仅将在多年测试工作中用到的一些探索式测试方法介绍给大家，希望能对从事软件测试的同行有所帮助。
注：本文描述的测试产品对象大都数以基于B/S结构的产品为主，少部分会考虑其他类型的产品。
1、对表单输入的测试探索：输入表单在产品中经常出现，比如我们要成为某个网站的会员，
我们就要注册一些个人信息，然后通过表单页面上的[提交]按钮，存储到数据库中去。对表单元素输入的测试探索中我们经常需要考虑两个方面：对超长字符或特殊字符（比如只允许输入数字）输入的探索以及对保留字符的输入探索。
1.1对超长或不符合格式字符输入的测试探索。由于表单输入的数据最终一般都是存入到数据库中的，所以对于输入的数据一定要对输入字符的长度或者类型进行限制。一个正常的操作方法为：输入一个超长或不符合格式的字符串，会有如下三种处理方式：
a）超长或不符合格式的字符在输入界面中被锁定
：比如表单要求输入最长长度为40个字符串，当输入第41个字符串的时候，页面是不允许输入的
；再如，表单只允许输入阿拉伯数字，如果你输入了一个字符'A'， 页面也是不允许的。
b）超长或不符合格式的字符在输入界面中被输入，但在提交表单的时候，输入界面会提示表单中有超长或不符合格式的字符，且表单不允许被提交。
c）超长或不符合格式的字符在输入界面中被输入，但在提交表单后，会在另外的页面中提示表单中有超长字符或不符合格式的字符被输入，且表单不允许被提交。
我们如果在表单输入超长或不符合格式的字符，提交后界面如果没有任何提示信息，甚至出现系统崩溃，或者出现数据库发生异常的英文日志显示在页面上，那么这显然是一个bug。另外如果我们输入一个超长或特殊字符，符合上述3种处理方法，我们的测试并未结束，这时候你不妨可以问问开发人员对应的代码，查看一下代码，尤其是查看在存储到数据库之前，程序是否对输入字符的长度或类型进行再一次校验，这是从安全性角度的考虑的。举个例子：我们输入页面的文件名为table.htm,后台存入数据库操作的文件名为insert.jsp。一个黑客为了破坏这套系统，它用其他软件制造了一个表单页面代替table.htm。在他的页面中输入超长或者不符合格式的数据，然后通过你的insert.jsp提交到数据库中，由于insert.jsp没对输入字符进行校验，从而造成系统的瘫痪。这种案例在从事网站开发的时候经常遇到。
1.2对保留字符的输入的测试探索。对于表单输入数据除了存储到数据库中去之外，还会显示在界面上。下面拿查询个人信息作为一个例子，此时界面会把你以前输入到数据库中的数据显示到界面上来，这样便于你对信息中不合适的地方进行修改。我们要对这类种型的测试进行探索，首先要搞清楚这套产品对表单输入数据的是使用何种方式进行输出的？这种输出方式中存在哪些保留字符？我们比如输出的方法是用HTML语言显示的，HTML保留字符为：<,
>, ", ',
&，空格，回车这七种字符，HTML语言显示这些字符会用其他另外的字符串进行替换的。一个正常的操作是从数据库中输出保留字符以后，程序对这些保留字符通过正则替换转码为HTML中对应的可以显示的字符串，如'<'转为<，空格转为 …,如果你在表单输入这些字符，甚至可以输入一段含有这些字符的HTML代码或者javascript代码，如：<a
href="http://www.sina.com.cn">进入新浪</a>,然后在显示页面中进行查看，看看输出的格式是否正确。如果输出的格式不正确，或者出现显示页面错乱，甚至执行了javascript语句，这肯定是一个bug.
2、对于模糊查询输入框输入数据的测试探索。目前除了一些专业的搜索引擎，比如Google,百度以及目前流行的大数据存储方式采用非关系性数据库或者NO
SQL技术进行存储，对于大多数软件系统通常还是采用传统的关系性数据库进行存储。若一个用户想查询标题中含有'云计算'的标题，再通过点击相应标题查看文章内容。通常所对应的SQL查询语句为：select
url,title，content from paper where title like '%$title%'
($title为模糊查询文本框提交过来的字符串,在这里为"云计算"),让我们来深入讨论一下SQL语句中%这一个关键而特殊的模糊查询字符，假设用户在模糊查询输入框中输入%，而程序在处理的时候没有对%进行特殊处理，上述的SQL语句就变为select
url,title from paper where title like
'%%%'，这样的查询输出结果不是把文章标题中含有%字符的标题输出，而是把这个数据库表中所有的记录都给输出来了。如果在测试中发现这样的问题，可以告诉程序员把输入字符中的%，通过正则替换把%转意为/%,就可以了。
3、对于并发操作的测试探索。这里举一个例子，比如被测系统是一个需要审核员审核的一个博客系统。注册该网站的会员可以在博客上发布自己的博文，但是发表的博文必须通过该网站的审核员审核通过后才可以正式发布到网上去。在这个产品中，网站会员具有的权限是：a)
书写博文并提交给审核员进行审核；b)对审核员退回的博文进行修改然后重新提交；c)对已提交未审核的博文可以随时进行修改或删除；审核员具有的权限是a)审核通过，博文被正式发表在网上
b)审核退回，审核员需要书写退回理由。让我们来设想可能会发生如下这样过程，审核员A正在审核一篇博文，而这个时候书写这篇博文的会员B觉得这篇博文不太合适，要将它删除了。此时审核员A进行审核通过或者审核拒绝的时候会出现什么情况？我们希望出现的情况是：在审核员A进行操作以后，系统会出现相应的提示信息"该博文已经被发表者删除，请与作者联系"的提示信息。然而在测试过程中我们经常会出现数据库发生错误，页面显示系统调用的用户看不懂的英文错误日志信息。让我们再进行一次探索，比如这个时候有2位审核员A
和
C同时在对同一篇博文进行审核，审核员A进行了一次审核通过的操作，过了几分钟后，审核员C进行了一次审核退回的操作，我们期望审核员C看到的也是一条友好性的提示信息
：" 该博文已经被审核员A审核通过，请您与审核员A联系
"，而不是在页面中出现一些用户看不懂的英文错误日志信息或者这篇博文被后操作的审核员C退回了。上述例子是审核通过在先，审核退回在后。同样道理，我们可以考虑审核退回在先，审核通过在后的情形。
4、对于页面刷新功能的测试探索。
几乎所有的人机交互页面都具有刷新功能，刷新功能的目的在于当开发人员把页面作了变化后
，用户通过按刷新按钮，就可以及时地看到最新页面的内容。但是由于刷新功能的存在，往往给产品带来一定的隐患，暗藏着一些bug，下面是可能遇到的两种情形：
4.1 系统进入表单填写页面，填写内容，提交表单，页面出现"表单数据提交成功"的提示信息。
就在这个提交成功页面按下刷新按钮
，页面会出现用英文提示数据库错误日志，大致内容是表单中的某某字段不允许相同。显然，在刷新的时候，系统把表单数据又重新的进行了一次提交操作。正确处理办法是：刷新后，不再重新提交数据库，仍旧显示表单数据提交成功的提示信息，或者告诉用户不允许同时提交相同的信息。
4.2 查询到一条记录，点删除按钮，页面出现对应"记录删除成功"的提示信息。
就在这个删除成功提示页面按下刷新按钮，页面用英文提示数据库或程序中出现了空指针异常的错误日志，显然，在刷新的时候，程序对同一条记录又进行了一次删除操作。正确的办法是：不再重新删除记录，仍旧显示表单数据删除成功的提示信息；或者告诉用户修改的记录不存在，无法删除。
5、对于非常用功能的测试探索。
这里我们还是以表单提交页面做个例子。在一个表单提交页面中往往会出现2到3个按钮（button），一个是[提交]（Submit）按钮，一个是[重写]（Reset）按钮（这个按钮往往在有些页面被删除），还有一个是[取消]（Cancel）按钮。对于[提交]（Submit）按钮，几乎每一个测试人员都不会遗忘，而对于[重写]（Reset）和[取消]（Cancel）按钮，几乎无人问津，而在操作[重写]（Reset）或者[取消]（Cancel）按钮操作以后，往往会发现一些隐藏的
bug。
6、对于突发事故的测试探索。
比如一个程序正在进行工作：或许是在备份数据；或许通信系统正在进行通话；或者一个用户正在浏览一个网站，就在这个时刻，事故发生了，比如事故为发生了停电现象（在测试的时候你可以拔掉电源），事故被解除后（在测试的时候你可以再次插上电源），系统被重新运行，这个时刻你要仔细检查一下整个系统是否仍旧可以启动？各个功能是否可以正常运行？是不是存在着数据丢失现象？…
7、对于界面链接的测试探索。 一个复杂的系统往往存在数十个甚至上百个页面，这些页面存在着互相链接依赖的关系
，我们在浏览一些网站，甚至浏览某些著名的网站的时候，通常会点击一个链接，系统会告诉你这个页面不存在，这就是由于界面链接测试没有做好，为了避免这种情形的出现，可以用下面做法：是把所有的页面画在一张纸上，如果A页面有链接可以链接到B页面中，就从A画一条直线链接到B,在直线B处画一个箭头；同样如果B页面有链接可以反向链接到A页面中，就从B再画一条直线平行于上述直线链接到A,在直线A处画一个箭头。全部直线，箭头都画好后，选择一个起点页面，一个终点页面，然后设计一条路径，在软件上一步一步地按照计划好的路径进行操作。经过几个这样的路径操作后，图中所有的路径都会被覆盖，测试结束。虽然目前市场上存在检查WEB页面是否存在空链接的工具，但是采用这种方法，在操作过程中往往会发现这样或那样的其他bug。
8、对于需要多步操作来完成一个事物的测试探索。
有些操作往往需要进行多步操作才可以完成，比如提交一份你的求职简历，第一页填写你的基本信息，第二页填写你的教育经历，第三页填写你的工作经历，最后一页填写你的其他信息。在测试这样的软件产品的时候你可以尝试提交第一，二，三步以后回退到第一步，重新输入，软件会出现什么情况？再尝试提交第一，二步后放弃提交，退出，然后再一次进入，输入和上次相同的信息，软件会出现什么情况？
9、对于老功能的测试探索。
对于一些产品中一些老的功能，我们经常很容易忽视，有些老测试工程师会说，这些功能我们那个时候测试了不下几十次了，肯定没有问题，这样造成的结果是这些功能模块几个月甚至几年都不去测试一下。可以设想，当其他功能的接口，框架，结构…都在进行调整，变化，包括数据库的结构也可能作过相应的调整。这些调整或许会对老功能造成一定程度的影响，所以我们需要不时地对这些老功能进行测试，有时会发现一些意想不到的问题。
10、对于重灾区的测试探索。
我们经常会听到这么一句话：80%的Bug出现在20%的功能点上，所以你在测试的时候，对于经常出现Bug的功能点，你一定要小心，小心再小心；认真，认真，再认真地进行测试。在这里你往往你会找到更多的bug。
11、对于强迫症测试法的测试探索。 强迫症测试法是James A.
Whittaker在他的著作中《探索式软件测试》中描述的，采取强迫症测试法往往会发现程序中出现的系统内存泄露等问题。记得几年前我在测试一个产品角色功能模块的时候，需要不断的登出，登入系统，后来发现经过多次的登出，登入操作后系统就会出现死机的现象，最后经过程序员排查，发现是程序中一个指针用完以后没有及时释放造成的。由于我们不可能对所有模块都进行强迫症测试法，
所以在哪里进行强迫症测试法？这需要凭测试人员的经验，也要看运气，具有一定的偶然性。当然我们还可以借助某些工具来进行强迫症测试法，这样可以节省很多精力。
12、对于产品广告中提及功能的测试探索。
产品广告往往是由市场人员作为产品推销而书写的，对于广告中提及的功能，我们要与市场和销售人员进行及时沟通，比如这条语句在那个模块的哪个功能点实现的，然后在产品上具体操作一下，看看是否是那么回事情。广告具有一定的夸大性，这是在所难免的，但是对于夸大成份过大的部分，测试人员有提出修改建议的义务。
13、对于产品说明书的测试探索。产品说明书对于用户，特别是一些新用户是了解产品的一个强为有力的工具，所以作为测试人员应该认真对待，我们需要对用户手册中每一条功能进行严格核实。除此之外，我们应该站在用户角度去思考，考虑有些注意事项是否需要告诉用户，用户手册是否便于用户阅读，用户手册的书写逻辑是否合理以及手册中章节的前后顺序是否需要进行调整，以便用户能够更好的熟悉产品…
14、对于领域专家提及功能的测试探索。
比如我们正在做一个4G手机产品软件的时候，听到一个新闻，国际上某某通信专家提出以后4G手机产品必须具有X功能。我们要和需求人员，公司领导一起讨论确定这条新闻是否属实，这位专家是否在业内影响力有多大等信息。然后再查看我们的产品是否具有X功能？如果没有，规划立刻把X功能安排进开发计划中；否则，我们是否需要重新审视一下X功能，看看X功能是否需要做优化。
15、对于用户并发性的测试探索。
在互联网的时代，用户并发性是个常见的现象。这在制订需求的时候我们就应该定义好同时并发的最大数，然后测试人员根据产品的具体情况，选择合适的工具或者自己开发相应的工具，以便于到产品完成后按照性能指标要求用工具进行并发量测试。
16、对于稳定性的测试探索。
稳定性也是用户关心的一项性能指标，如同用户并发性一样，我们同样需要结合自身产品特性，选择合适的工具或者自己开发相应的工具，以便于到产品完成后按照性能指标要求用工具进行稳定性测试。
17、对于用户友好性的测试探索。
什么叫用户友好的，什么又叫用户不友好的，这是个仁者见仁，智者见智的问题，没有统一的规范。这项测试在许多企业很难展开。我采取的方法是如果没有客户，让一个模块由多个人进行测试，大家都认为不友好，那么作为不友好bug提出。若有客户，则优先考虑客户的意见。另外我们认为相同模块处理结果的一致性是用户友好性的一项衡量指标，比如提交客户信息后出现的是A风格的界面，提交产品信息后出现的是B风格的界面，这样的用户友好性肯定差。
18、对于兼容性的测试探索。
兼容性测试分为产品自身前后版本兼容性，产品在各个显示器或浏览器上显示兼容性，对运行的操作系统兼容性以及与其他产品的兼容性。关于这些兼容性的细节我在这里就不再提及的，大家到互联网上可以很清楚地看到其定义。
19、对于升级（upgrade）的测试探索。
一个产品不可能一次就能开发得满足用户的需求，肯定需要经过多个版本，尤其是敏捷开发概念提出以后，版本发布越来越频繁。现在产品大都支持在老产品的基础上，不删除产品，直接运行升级脚本，从而完成升级目的。对于一些实时性要求很高的产品，比如通信产品，在升级的过程中还需要考虑不影响通信业务的正常运行。另外测试完毕升级操作后，我们都要将产品进行还原(Restore)操作，还原到升级之前的版本，以保证维护人员在客户处万一升级失败，用户仍旧可以在老版本上继续进行使用。
20、总结：探索式测试强调在一个测程内进行测试设计，测试执行，然后对测试结果进行分析总结，从而进一步对业务知识，测试技巧，测试工具…进行学习。重新调整测试策略，然后进入下一个测程。所以及时地总结测试方法在探索式测试中是非常重要的，大家应该把测试方法放在一个大家都可以看到的地方，比如
WiKi，便于大家都可以及时进行查看和学习。测试人员学习测试方法可以提高自己的测试技能；开发人员学习测试方法可以在开发的时候尽量避免错误的发生，从而起到缺陷预防的效果。
[1] www.context-driven-testing.com
【投稿】【关闭窗口】【打印】