1．确定探索目标，探索式测试不是漫无目的的漫游，在进行探索式测试之前要确定主要探索的目标，有针对型地进行探索，并且要给其分配时间，最佳方法是结合测试用例和测试需求来开展，抛开测试用例的探索是失败的探索。
如：2011-8-20日，探索目标，录入系统导入与导出功能。
2．客户现场测试法：确定功能测试目标之后，根据需求分析其业务流程，检查其主要功能是否符合功能定义。
如：录入系统，导入功能：按照指定的模板，导入数据到临时表。
录入系统，导出功能：将临时表和历史库中查询出来的数据，导出。
确定业务流程之后，我们就可以开展业务流的测试，并结合考虑客户工作环境，这里的导入导出功能主要用到xls和txt文件，所以要考虑的是客户的excel软件环境。
那么我们探索的方向就可以类似于下面这样，你探索过的地方最好记录下来，在某个时候你可以再回顾这个探索的过程，并检查是否有遗漏处：
导入功能：1.导入窗口能打开吗？
2.能将模板中的数据导入吗？
3.导入的速度够快吗？
4.能将非2003的Excel文件导入吗？
。。。。。。
导出功能：1.导出窗口能正常打开吗？
2.能实现将数据导出为xls或txt吗？
3.导出速度够快吗？
。。。。。。
3.边界测试法：在上面探索保证业务流可以走通之后，我们可以继续探索那些躲在边角的东西。软件测试的经验告诉我们，在功能测试时发现的缺陷大多是由边界由起的。而此类问题，开发人员又常常没有处理这些异常，程序抛出异常之后，软件崩溃的可能性较高。所以此类测试是在保证业务流之后的重点测试方向。
数量边界：我们首先想到的肯定是数量边界，所以我们可以继续探索：
导入功能：1.导入0行数据，显示还是提示？提示又提示什么？
2.导入Excel的65536行数据，效果如何？
3.导入的Excel有多列，行数为65536行，效果如何？
。。。。。。
导出功能：1.表中的数据为0行，能够导出为xls或txt吗？
2.表中的数据，满了，能够导出为xls或txt吗？
3.有多行数据和多列数据，能够导出为xls或txt吗？
。。。。。。
状态的边界：程序的状态，一般只有这三种情况：开始，挂起，停止。基本策略就是打断程序的这三种状态。
所以我们可以继续进行状态的边界探索：
导入功能：1.某个Excel我正打开着，能够导入吗？
2.如果导入过程中，我关闭或修改了Excel，数据处理是什么样子的？
3.如果在导入过程中，我退出了这个页面，数据又怎么处理呢？
。。。。。。
导出功能：1.导出过程中，我退出了这个页面，还能导出吗？
2.我已经打开了某个xls或txt，然后我再导出想覆盖它，我能导出吗？
。。。。。。
操作频率的边界：操作频率他的边界只有1次或多次。多次没有上限，这时我们可以根据软件的特点和业务流的特点来确定。
我们继续我们的操作频率的探索：
导入功能：1.如果某个Excel达65536*120行的数据，用户可能一天至少导入10次，程序能支持吗？
。。。。。。
导出功能：1.如果某个Excel达65536*120行的数据，用户可能频率比较高，一天能够导出50次吗？
。。。。。。
联想测试法：联想不是漫无目的的联想，联想要有主题或者根据某一些发现的问题进行其它功能的联想测试。
比如：我们发现了导出10次12789行的数据后，客户端内存消耗达1G，报system.out.meroy的错误，我们就可以继续展开类似的联想探索：
1. 多次，横向录入和纵向录入切换，效果如何？
2. 多次，修改大量数据如何？
3. 多次，替换效果如何？
。。。。。。
组合测试法：在上面的测试方法的基础上，结合功能的应用场景，继续探索进入探索。
导入功能：1.导入的模板，名称字符错了，怎么办？
2.导入的模板，名称字符大小写转换了，还能导入？
3.导入的模板，有了单元格的格式，还能导入吗？
4.导入的模板，被合并单元格了，还能导入吗？
5.导入的模板，被合并的单元格，比较多，还能导入吗？
6.纵向录入时，导入可以吗？
7.冻结了窗口，还可以导入吗？
。。。。。。
导出功能：1.纵向录入时，可以导出吗？
2.冻结了窗口，还可以导出吗？
。。。。。。
探索式测试的方法很多，我现在能表达出来的就只有这些，所以请大家谅解我不能够举更多的例子。
（看着挺好的，就转过来了）
