作为测试人员，几乎人人都有意无意地做着探索式测试，但真正做好探索式测试的需要大量练习。为了练习和提高探索式测试的技能，我们测试团队近期又组织了一次探索式测试道场。（关于探索式测试道场，请参考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，把你自己想象成你熟悉的每个人：年老的父母，淘气的孩子，爱音乐的朋友，忙碌的自己。。。当然，还要知道你的产品最关注的人群，从而加强对他们特点的模拟。如果被测系统是有一定专业性的，那只有增强自己的专业知识，并运用专业知识来指导你的测试。如果可能的话，我们需要学习业务领域知识，使用业务上类似的其它软件，分析产品环境的数据，从而了解并模拟用户常用的和可能的流程、数据等。另外，去客户现场感受他们的工作环境、软硬件设备、输入习惯、出错概率、工作效率等也十分有益。当我们在戏谑不写单元测试的开发人员是不系保险绳的徒手攀岩新手，不了解用户场景的测试人员是否也一样呢？
问题3：忙于敲键盘和点鼠标，主动思考太少
虽然探索式测试讲究的是根据上一个输出决定下一步输入，但如果全是这种＂反应＂式的被动思考，那么很容易迷失测试思路。如果我一而再再而三地走一步看一步，却处处碰壁得不到想要的结果，那么我很可能在这条纵深的路上已经走了太远，心理上感到严重受挫，从而不甘心另起炉灶从零开始，于是犹豫中还会在以前走过的路径上再次盲目搜寻。这时我的输入变成一种下意识的惯性行为，测试可以说已经失控。当我在道场中观察别人操作的时候，我发现新老测试人员都会有这样的失控时刻。
思考的改进方法：
我想，如果在探索式测试中，在大量反应式的被动思考的同时结合一定的主动思考，则应该会有更好的效果。比如，我们可以在设立了测试章程后花几分钟时间用思维导图的形式主动构思几个测试方向，然后在每个方向上更多地依赖观测到的现象决定下一步。当然，我们也可能会因为收获了新的信息而修改原来的方向。但真正开始动手执行测试前让脑子先行，可以在测试的广度上有一个好的基础，辅助以执行过程中每条思路下的探索，在测试的深度上也能收放更为自如。又如，当我们碰到了测试的瓶颈，脑子暂时短路的时候，不如暂停操作，换为纯思考，好好整理一下思路，理一理头绪。
问题4：被原有测试经验所累，运用新的经验较慢
人的经验在大部分的时候都是双刃剑。丰富的测试经验在我们身上烙下深深的烙印，它有时是一种优势，有时是一种束缚。在本次道场中，虽然我们明明知道环境的兼容性是本次测试中我们更需要测试的高风险的地方，但在不知不觉中我们已经在超长字符和快捷键这种细节处浪费了太多时间。我想这是因为在过去我们的测试中，这一类型的测试是必要（用户关心）且有效的（可以找到缺陷），而我们在进入本次测试的时候没有刻意摆脱这种经验的影响。
经验主义的改进方法：
善用经验的关键是知道如何根据本次测试的上下文决定多大程度利用经验和抛弃经验。当我们测试熟悉的业务系统时，当我们的被测系统使用的是我们熟悉的技术时，当与我们合作的是熟悉的开发团队时，我们当然应该更多地参考甚至相信我们的经验。而当我们测试一个不熟悉的系统时，则更明智的选择是提醒自己不去太早地做太多假设和偏向某一种熟悉的曾经好用的测试思路，回到一些更抽象的测试模型，回到最基本的不讨巧的测试方法，紧扣本次测试任务制定相应的章程，和选择更适合本次测试的方法。
总结
下一次探索式测试，无论是一个人孤独地坐在工位上进行，还是如这次大家在一起认真练习和热烈讨论，我都希望能够再CUTE一些，以简明的章程为核心，以多样的用户场景为测试手段，积极思考，善用经验，持续练习和提高探索式测试技能。