作為測試人員，幾乎人人都有意無意地做著探索式測試，但真正做好探索式測試的需要大量練習。為了練習和提高探索式測試的技能，我們測試團隊近期又組織了一次探索式測試道場。（關于探索式測試道場，請參考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一些，以簡明的章程為核心，以多樣的用戶場景為測試手段，積極思考，善用經驗，持續練習和提高探索式測試技能。