" 探索式测试"是测试专家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退回了。上述例子是审核通过在先，审核退回在后。同样道理，我们可以考虑审核退回在先，审核通过在后的情形。
|
