作为测试人员，几乎人人都有意无意地做着探索式测试，但真正做好探索式测试的需要大量练习。为了练习和提高探索式测试的技能，我们测试团队近期又组织了一次探索式测试道场。（关于探索式测试道场，请参考http://www.testingdojo.org/tiki-index.php?page=Testing%20Dojos）这次我们沿袭上次的新老测试人员结对的方式，只是换做老测试人员执行，新测试人员观察和建议。测试的任务是在30分钟内对一个探索式测试工具RapidReporter进行测试和评估，看是否有充足理由表明我们不能在日常工作中使用它。
作为此次活动的组织者，我观察到了一些和上次新测试人员主测时不一样的一些现象。（关于上次探索式测试道场的总结，请参考http://www.51testing.com/?uid-56882-action-viewspace-itemid-814226）本文将对这些现象进行总结。因为类似的现象或多或少在我身上也存在,本人也从个人角度提出了相应改进的建议，以供大家讨论。
我将我观察到的主要问题总结为CUTE，即Charter，User，Thinking，Experience四个方面。
问题1：Charter定得不好
因为大部分人对RapidReporter不熟悉，所以本次道场大部分测试人员制定的Charter类似于“熟悉该软件基本流程，模拟用户操作”。而针对原始目标“看是否有充足理由表明我们不能在日常工作中使用RapidReporter”，其实更应该去寻找用户可能碰到的比较严重的问题或者极限情况下不能处理的问题。因为大家把熟悉软件基本流程作为了Charter，所以在整个session中大量的时间放在了摸索一些细节的功能上，而对于其它耗时较多的或者破坏性的测试即使有想到，测试时间也不多。
缺乏清晰的指导和实例分析，我想这是我们在实践SBTM之初不太容易写好Charter的原因之一。
Charter（测试章程）是基于测程的探索式测试(SBTM)中比较核心的一个概念。根据提出SBTM方法的Bach兄弟中的Jonathan Bach在Session-based test management一文中的表述：“By‘chartered’, we mean that each session is associated with a mission—what we are testing or what problems we are looking for.”我们可以了解到Charter主要是为每一个session制定一个目标，测什么或者找什么。但在同一篇文章中稍后的部分，我们又看到了这样的描述“Session charter (includes a mission statement, and areas to be tested)”。这里表明Charter是既要包含测试目的又包含测试范围的，而不是二者之一。所以这里会让人产生一些疑问。虽然探索式方面的资料比较多，但对于什么样的Charter才是好的Charter，不好的Charter会带来哪些问题，我目前还没有找到太多资料。
制定Charter的改进方法：
在敏捷开发中描述用户故事的时候，我们常用这样的标准格式＂As a ..., I want to ..., so that ..."。为了让Charter的制定更有效和简洁，我也想用一种标准格式＂By testing ...through ... to ..."来规范Charter的制定。通过这样的格式，可以强迫你在开始测试前就明确本次测试中核心的三个元素：测试范围、测试方法、测试目标。按照这样的格式，我们可以较容易地制定出有效的Charter。比如，通过参考需求文档测试A功能来熟悉此功能与其它系统的交互；通过数据的多样性变化来测试B流程对各种数据的容错能力；通过检查UI来测试C模块是否符合UI规范。
问题2：从用户角度的测试还不够多，不够真实
针对本次道场的测试目标，如果我们从用户的角度考虑，有很多值得尝试的方向。如，不同用户环境的异构性（包括操作系统、语言包等）、工具本身对.NET 3.5的要求与我们被测系统可能的冲突、超长时间的session、记录大量数据的session、双屏下的截屏。。。从本次道场单个测试人员的思路上来看，想到的还不够多。同时，部分测试人员使用的测试数据也不够真实。比如，如果我们只用bug1这样的测试数据来作为bug记录，那么我们怎么能确认象平时一个bug的简要描述可能需要30~50个字符的时候程序确实可以正常记录呢？又如，为了造超长的字串或者特殊字符，有的测试人员在敲键盘，有的在别的文档中拷贝一段字串过来，但是是否直接把前两天你报的一个真实的带有出错日志的缺陷录入进来可能更有说服力呢？因为一个真实的出错日志，其长度和本身包含的特殊字符比我们自己臆造的要更有效。
从用户角度测试的改进方法：
如果被测系统是面向广大人民群众的，如互联网或移动类型的应用，那就做role play，把你自己想象成你熟悉的每个人：年老的父母，淘气的孩子，爱音乐的朋友，忙碌的自己。。。当然，还要知道你的产品最关注的人群，从而加强对他们特点的模拟。如果被测系统是有一定专业性的，那只有增强自己的专业知识，并运用专业知识来指导你的测试。如果可能的话，我们需要学习业务领域知识，使用业务上类似的其它软件，分析产品环境的数据，从而了解并模拟用户常用的和可能的流程、数据等。另外，去客户现场感受他们的工作环境、软硬件设备、输入习惯、出错概率、工作效率等也十分有益。当我们在戏谑不写单元测试的开发人员是不系保险绳的徒手攀岩新手，不了解用户场景的测试人员是否也一样呢？
