qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

          ET道場小記

            作為測試人員,幾乎人人都有意無意地做著探索式測試,但真正做好探索式測試的需要大量練習(xí)。為了練習(xí)和提高探索式測試的技能,我們測試團隊近期又組織了一次探索式測試道場。(關(guān)于探索式測試道場,請參考http://www.testingdojo.org/tiki-index.php?page=Testing%20Dojos)這次我們沿襲上次的新老測試人員結(jié)對的方式,只是換做老測試人員執(zhí)行,新測試人員觀察和建議。測試的任務(wù)是在30分鐘內(nèi)對一個探索式測試工具RapidReporter進行測試和評估,看是否有充足理由表明我們不能在日常工作中使用它。

            作為此次活動的組織者,我觀察到了一些和上次新測試人員主測時不一樣的一些現(xiàn)象。(關(guān)于上次探索式測試道場的總結(jié),請參考http://www.51testing.com/?uid-56882-action-viewspace-itemid-814226)本文將對這些現(xiàn)象進行總結(jié)。因為類似的現(xiàn)象或多或少在我身上也存在,本人也從個人角度提出了相應(yīng)改進的建議,以供大家討論。

            我將我觀察到的主要問題總結(jié)為CUTE,即Charter,User,Thinking,Experience四個方面。

            問題1:Charter定得不好

            因為大部分人對RapidReporter不熟悉,所以本次道場大部分測試人員制定的Charter類似于“熟悉該軟件基本流程,模擬用戶操作”。而針對原始目標“看是否有充足理由表明我們不能在日常工作中使用RapidReporter”,其實更應(yīng)該去尋找用戶可能碰到的比較嚴重的問題或者極限情況下不能處理的問題。因為大家把熟悉軟件基本流程作為了Charter,所以在整個session中大量的時間放在了摸索一些細節(jié)的功能上,而對于其它耗時較多的或者破壞性的測試即使有想到,測試時間也不多。

            缺乏清晰的指導(dǎo)和實例分析,我想這是我們在實踐SBTM之初不太容易寫好Charter的原因之一。

            Charter(測試章程)是基于測程的探索式測試(SBTM)中比較核心的一個概念。根據(jù)提出SBTM方法的Bach兄弟中的Jonathan BachSession-based test management一文中的表述:“Bychartered’, we mean that each session is associated with a missionwhat we are testing or what problems we are looking for.”我們可以了解到Charter主要是為每一個session制定一個目標,測什么或者找什么。但在同一篇文章中稍后的部分,我們又看到了這樣的描述“Session charter (includes a mission statement, and areas to be tested)”。這里表明Charter是既要包含測試目的又包含測試范圍的,而不是二者之一。所以這里會讓人產(chǎn)生一些疑問。雖然探索式方面的資料比較多,但對于什么樣的Charter才是好的Charter,不好的Charter會帶來哪些問題,我目前還沒有找到太多資料。

            制定Charter的改進方法:

            在敏捷開發(fā)中描述用戶故事的時候,我們常用這樣的標準格式"As a ..., I want to ..., so that ..."。為了讓Charter的制定更有效和簡潔,我也想用一種標準格式"By testing ...through ... to ..."來規(guī)范Charter的制定。通過這樣的格式,可以強迫你在開始測試前就明確本次測試中核心的三個元素:測試范圍、測試方法、測試目標。按照這樣的格式,我們可以較容易地制定出有效的Charter。比如,通過參考需求文檔測試A功能來熟悉此功能與其它系統(tǒng)的交互;通過數(shù)據(jù)的多樣性變化來測試B流程對各種數(shù)據(jù)的容錯能力;通過檢查UI來測試C模塊是否符合UI規(guī)范。

            問題2:從用戶角度的測試還不夠多,不夠真實

            針對本次道場的測試目標,如果我們從用戶的角度考慮,有很多值得嘗試的方向。如,不同用戶環(huán)境的異構(gòu)性(包括操作系統(tǒng)、語言包等)、工具本身對.NET 3.5的要求與我們被測系統(tǒng)可能的沖突、超長時間的session、記錄大量數(shù)據(jù)的session、雙屏下的截屏。。。從本次道場單個測試人員的思路上來看,想到的還不夠多。同時,部分測試人員使用的測試數(shù)據(jù)也不夠真實。比如,如果我們只用bug1這樣的測試數(shù)據(jù)來作為bug記錄,那么我們怎么能確認象平時一個bug的簡要描述可能需要30~50個字符的時候程序確實可以正常記錄呢?又如,為了造超長的字串或者特殊字符,有的測試人員在敲鍵盤,有的在別的文檔中拷貝一段字串過來,但是是否直接把前兩天你報的一個真實的帶有出錯日志的缺陷錄入進來可能更有說服力呢?因為一個真實的出錯日志,其長度和本身包含的特殊字符比我們自己臆造的要更有效。

            從用戶角度測試的改進方法:

            如果被測系統(tǒng)是面向廣大人民群眾的,如互聯(lián)網(wǎng)或移動類型的應(yīng)用,那就做role play,把你自己想象成你熟悉的每個人:年老的父母,淘氣的孩子,愛音樂的朋友,忙碌的自己。。。當(dāng)然,還要知道你的產(chǎn)品最關(guān)注的人群,從而加強對他們特點的模擬。如果被測系統(tǒng)是有一定專業(yè)性的,那只有增強自己的專業(yè)知識,并運用專業(yè)知識來指導(dǎo)你的測試。如果可能的話,我們需要學(xué)習(xí)業(yè)務(wù)領(lǐng)域知識,使用業(yè)務(wù)上類似的其它軟件,分析產(chǎn)品環(huán)境的數(shù)據(jù),從而了解并模擬用戶常用的和可能的流程、數(shù)據(jù)等。另外,去客戶現(xiàn)場感受他們的工作環(huán)境、軟硬件設(shè)備、輸入習(xí)慣、出錯概率、工作效率等也十分有益。當(dāng)我們在戲謔不寫單元測試的開發(fā)人員是不系保險繩的徒手攀巖新手,不了解用戶場景的測試人員是否也一樣呢?



            問題3:忙于敲鍵盤和點鼠標,主動思考太少

            雖然探索式測試講究的是根據(jù)上一個輸出決定下一步輸入,但如果全是這種"反應(yīng)"式的被動思考,那么很容易迷失測試思路。如果我一而再再而三地走一步看一步,卻處處碰壁得不到想要的結(jié)果,那么我很可能在這條縱深的路上已經(jīng)走了太遠,心理上感到嚴重受挫,從而不甘心另起爐灶從零開始,于是猶豫中還會在以前走過的路徑上再次盲目搜尋。這時我的輸入變成一種下意識的慣性行為,測試可以說已經(jīng)失控。當(dāng)我在道場中觀察別人操作的時候,我發(fā)現(xiàn)新老測試人員都會有這樣的失控時刻。

            思考的改進方法:

            我想,如果在探索式測試中,在大量反應(yīng)式的被動思考的同時結(jié)合一定的主動思考,則應(yīng)該會有更好的效果。比如,我們可以在設(shè)立了測試章程后花幾分鐘時間用思維導(dǎo)圖的形式主動構(gòu)思幾個測試方向,然后在每個方向上更多地依賴觀測到的現(xiàn)象決定下一步。當(dāng)然,我們也可能會因為收獲了新的信息而修改原來的方向。但真正開始動手執(zhí)行測試前讓腦子先行,可以在測試的廣度上有一個好的基礎(chǔ),輔助以執(zhí)行過程中每條思路下的探索,在測試的深度上也能收放更為自如。又如,當(dāng)我們碰到了測試的瓶頸,腦子暫時短路的時候,不如暫停操作,換為純思考,好好整理一下思路,理一理頭緒。

            問題4:被原有測試經(jīng)驗所累,運用新的經(jīng)驗較慢

            人的經(jīng)驗在大部分的時候都是雙刃劍。豐富的測試經(jīng)驗在我們身上烙下深深的烙印,它有時是一種優(yōu)勢,有時是一種束縛。在本次道場中,雖然我們明明知道環(huán)境的兼容性是本次測試中我們更需要測試的高風(fēng)險的地方,但在不知不覺中我們已經(jīng)在超長字符和快捷鍵這種細節(jié)處浪費了太多時間。我想這是因為在過去我們的測試中,這一類型的測試是必要(用戶關(guān)心)且有效的(可以找到缺陷),而我們在進入本次測試的時候沒有刻意擺脫這種經(jīng)驗的影響。

            經(jīng)驗主義的改進方法:

            善用經(jīng)驗的關(guān)鍵是知道如何根據(jù)本次測試的上下文決定多大程度利用經(jīng)驗和拋棄經(jīng)驗。當(dāng)我們測試熟悉的業(yè)務(wù)系統(tǒng)時,當(dāng)我們的被測系統(tǒng)使用的是我們熟悉的技術(shù)時,當(dāng)與我們合作的是熟悉的開發(fā)團隊時,我們當(dāng)然應(yīng)該更多地參考甚至相信我們的經(jīng)驗。而當(dāng)我們測試一個不熟悉的系統(tǒng)時,則更明智的選擇是提醒自己不去太早地做太多假設(shè)和偏向某一種熟悉的曾經(jīng)好用的測試思路,回到一些更抽象的測試模型,回到最基本的不討巧的測試方法,緊扣本次測試任務(wù)制定相應(yīng)的章程,和選擇更適合本次測試的方法。

            總結(jié)

            下一次探索式測試,無論是一個人孤獨地坐在工位上進行,還是如這次大家在一起認真練習(xí)和熱烈討論,我都希望能夠再CUTE一些,以簡明的章程為核心,以多樣的用戶場景為測試手段,積極思考,善用經(jīng)驗,持續(xù)練習(xí)和提高探索式測試技能。

          posted on 2012-10-16 09:45 順其自然EVO 閱讀(329) 評論(0)  編輯  收藏 所屬分類: 敏捷測試

          <2012年10月>
          30123456
          78910111213
          14151617181920
          21222324252627
          28293031123
          45678910

          導(dǎo)航

          統(tǒng)計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 汾阳市| 交城县| 长汀县| 闽清县| 湘乡市| 泸西县| 乌兰浩特市| 长春市| 滁州市| 霍城县| 泽普县| 湛江市| 玛纳斯县| 吉水县| 潍坊市| 缙云县| 靖江市| 廉江市| 武夷山市| 海丰县| 东明县| 惠安县| 通化市| 浑源县| 台北市| 陆河县| 苍南县| 仁布县| 班玛县| 仙游县| 巴林左旗| 宜兰市| 襄城县| 宣化县| 沈丘县| 永济市| 象山县| 夏津县| 阿克陶县| 湘西| 武邑县|