軟件測試Web測試經驗

軟件測試Web測試經驗   Web測試工具

這個測試項目記錄了包括重復在內的：200個偏差。大約有150個偏差報告給了開發人員，其中65個被接受，剩下的偏差不得不推遲到“下一個版本”，因此系統必須變成功能有限的產品——推遲了3個月。因此項目小組把測試看作是成功的。我們沒讓一個有太多“故障”的系統變成產品而把問題留給客戶。

    我們在前面提到的類比意思是說每個人在某個時候或其他時候都用過某種形式的探索性或雙人組技術。但是要把事情做對需要一定的技巧。那么它需要什么技巧?我們獲得了什么樣的有用經驗呢?

    有些人會說什么也沒有，他們會爭辯說這個項目太小了，而且太“緊迫”。我們很少有時間為雙人組做準備。我們并沒有一個定義好的、能衡量覆蓋率的方法。我們把探索性技術當作一條“出路”，因為我們并沒有足夠的信息來用傳統的測試腳本a因此從這個項目中并不能夠得出結論。

    其他一些人說我們確實學到了很多：探索性測試、雙人測試和管理高速的缺乏文檔的Web項目。很不幸，這種情況出現得比較頻繁，因為上市時間是所有客戶都關心的問題。這也是我們第一次嘗試測試的一種概念，在這個測試中，雙人組和探索性技術被“正式化，’了，不僅僅是項目的附屬，或臨時的測試方法。在很多方面它給予我們的比我們想要的還要多。

    就像James Bach陳述的那樣，在進行探索性測試的時候，測試人員需要提前進行探索性測試的。r培訓”。幸運的是，我們的測試人員在測試之前就已經完成了為期兩天的學習指導課程。為了確保盡可能全面，在第一天我們還或多或少地進行了正式的功能性測試。這不僅使測試人員對軟件有了更好的理解，而且還向他們指出了系統中錯誤可能發生的地方。這是很重要的，因為探索性測試就是使用您所知道的東西。確實會出現的一個問題是當在軟件的一小部分中發現錯誤的時候，所有的雙人組都開始檢查那個部分。由于雙人組沒有進行過探索性測試的培訓，因此我們需要在不同的方向上指引他們以提高測試的覆蓋率。也許在計劃階段就應該考慮到這個問題。

    同事提出了許多問題，他們不知道我們如何控制這樣一個非結構化的測試。在發現“故障”的時候，我們如何保證填寫了偏差報告?如何能知道測試人員是否堅持了測試計劃?如何確保他們是完全具有工作能力的?我們是否會不斷地在房間里轉來轉去?我們不是在一個房間里轉，而是在三個不同的房間里“跑”(因為我們把Windows 95、2000和NT放在不同的房間里了)。困難的事情不是讓測試人員進行測試，而是讓他們不要測試計劃以外的內容。當我們在幾個房間里穿梭的時候，我們腦子里會得到一幅測試人員工作的畫面(只有14個人，因此并不那么令人疲憊不堪)。只要我們看到有一組沒有在計劃區域內工作或是出現了別人已經報告過的錯誤，我們一般會給他們一些小的暗示。比如“您試過這個了嗎”或“如果您那樣做會發生什么?”為了使每個人都不脫離。r正軌”，我們這樣做就可以了。在分組工作時，其中一個測試人員總是負責填寫偏差報表。這是一個很容易填寫的表，但是使故障重現已經足夠了。在每

個暫停階段(在每次90分鐘的測試后)，如果可能的話我們與項目經理一起通讀所有的. 報告，以確保我們理解所記錄的東西以及確保我們有足夠的信息來重現故障。此外在每個暫停階段，我們常與所有人交流并且一天三次地把所有人聚集到一個房間里

原文轉自：http://www.kjueaiud.com