軟體測試之注意事項

標籤：

1． 尋找bug時的注意事項

（1）軟體系統的實現過程就是一組控制項實現自己的功能邏輯的過程。我們通過幾個常用的web控制項，來說明一下我們需要注意的地方。

  文字框（TextBox）

文字框更多的情況下是用來輸入資訊的。文字框都一樣，可是不同地方的文字框需要輸入的資訊就不會都一樣了，比如說，有的是用來輸入時間日期的，有的是用來輸入文字的。首先我們要結合需求，確定文字框的具體作用，要是用來輸入日期時間的，就要注意可以輸入幾種格式的日期時間，是唯讀，還是可進行手動修改的，是否對漢字、特殊符號等做了輸入限制（很多時候，錄入不匹配的資訊，系統會出現錯誤）。要是用來輸入文字的，驗證是否對錄入的文字長度做了限制（如果超出資料庫設定的最大值，會出錯）還要注意文字框設定的可視長度，和錄入的資訊以及頁面的整體風格是否和諧。

  標籤（label）

標籤，基本上不用實現什麼邏輯功能，只是起到顯示標記的作用。對於標籤，我們注意的就是不要出現錯別字（當然，任何地方都不能有錯別字這樣低級的錯誤），當標籤和其它控制項聯合使用的時候，我們要結合頁面的整體風格，確認它的設定是否合適，如label與其他控制項之間的距離、標籤的字型樣式及顏色是否合適等。

  選項按鈕（RadioButton）

選項按鈕，顧名思義，就是只能選擇一個。一般情況下，選項按鈕都是以組出現的。如錄入性別資訊時，有“男”和“女”兩個選項，我們要確認只能選擇其中的一種，不允許兩項都可以選擇，而且提交的是選擇的資訊。

  複選框（CheckBox）

可以這樣說，複選框和選項按鈕的作用是相對的。使用複選框的地方，一定是要求可以進行多選的，自然就要驗證是否實現了多選功能。這裡我舉這樣一個例子：有

A、B、C三個查詢條件，是用複選框的形式實現的。當驗證完每一個查詢條件後，最好再進行組合驗證，就是說當只選擇A和C或B和C時進行查詢。也許有時候bug是由後台查詢語句出錯導致的，並不是複選框本身的錯誤。我想說的是不要忘記進行這樣的測實驗證。

 下拉式清單（DropDownList）

下拉式清單的作用和選項按鈕的功能有些相似，從列表中選擇一條自己需要的資訊。很多時候，列表的選項中有一條是使用頻率最多的，即使使用者沒有做特殊要求，系統最好把使用頻率最多的那一項設定為預設選項，這樣可省去使用者的一次操作步驟(不僅是這裡，要注意整個系統中對預設選項的設定，軟體就是應該最大程度的方便使用者)。而且還要注意下拉式清單的寬度是否合適，列表資訊是否顯示完全了。

 按鈕（Button/Submit）

我們要注意Button和submit兩種按鈕的不同之處，Button主要是用來實現相應的方法函數，submit是用來提交相應的表單到相應的action處。這裡有一點就是，當單擊執行一個刪除類的按鈕時，一定要加上提示資訊，而且提示資訊上要有確定和取消功能，以防使用者不小心刪錯資訊。

（2） 現在的軟體系統不再像以前那樣單調，軟體中實現了很多特效。舉一個簡單的例

子來說明一下，比如對一個按鈕，當游標放到上面的時候，它是一種效果，當游標離開之後，它又是另一種效果。也要注意游標的變化，當游標在可輸入的文字框上面時是“I”形狀的，在一般的按鈕上是彎曲三個手指的小手形狀的。我們要注意特效的統一性，而且特效也不是用的越多越好。效果的實現使系統變得更加的多彩，使用者也會更加愉快的使用軟體。

（3） 每一個稍微複雜一點的系統一般都是由多個頁面組成的，而不會只使用一個單調

的頁面，這時我們就要注意介面顯示的色調風格是否統一、字型大小從標題到具體內容是否體現出層級，同類、同層次的風格設定是否統一。雖說系統可以由多個介面組成，但是我們也不希望看到冗餘的介面。也許有的需求中並沒有對介面作出特殊的要求，但是我認為高品質的介面也是一款高品質的軟體不可或缺的組成部分。

（4） 測試軟體時，一定不要漫無目的的測來測去。這樣不僅會增大工作量，而且也不

能對系統作出徹底的測試，。我們要有計劃有目的的進行測試工作。要是擔心忘記某些功能點，“地毯式”測試也是行得通的，從頁面的第一個功能點到最後一個進行地毯式的搜尋測試。

（5） 注意介面上的分頁和捲軸等小問題，有的地方資訊很少，一頁足可以顯示完，

就不需要分頁功能了；有的視窗會看到捲軸，如果再把視窗設定的大一點，就可以全部顯示了，那就最好把捲軸去掉，我想每個使用者都希望一眼就看到所有的資訊，而不想拉來拉去的。還有就是該有時間的地方，一定要有時間資訊，尤其是涉及到列印報表的地方。

（6） 一般的系統都需要使用使用者名稱和密碼登陸，而且會為不同的使用者指派不同的許可權。

不要總是使用正確的使用者和密碼在相應的許可權範圍內進行測試工作，從開啟登陸視窗的那一刻就要意識到測試工作已經開始了。在測試過程中不要按部就班的操作程式，你也不知道使用者在使用過程中會怎樣操作程式，有時候就要反其道而行之，要知道測試是具有破壞性的。

（7） 使用者使用軟體的環境和軟體開發時的環境不可能完全一樣。我們可以考慮並驗證

以下這幾個問題：

   其他的瀏覽器是否有相同的問題?

   其他的軟硬體設定是否有相同的問題?

   不同的安排設定是否有相同的問題?  

    以前的版本否有相同的問題?

2． 提交bug時的注意事項

（1） 發現一個問題時，不必急著提交，可以先做驗證(包括複現、對比測試等)進行證實，

看是機率性問題還是每次必現的問題，需要時也應使用不同版本不同機器做對比驗證，當然，如果已經很確信是一個bug了，也就不用浪費時間去對比驗證了。

（2） 描述要清晰、準確，不要使用含糊的詞語(例如，好像，似乎)來描述發現的現象。

關於這點，如測試某款軟體時，提交一個bug描述為“軟體協助說明中好像有錯別字”，並沒有說出哪一頁哪一行以及具體哪個字錯了，應該修改成什麼樣的。因此就不能說是個好的描述。

（3） 要考慮開發人員的感受，有些問題尤其是有些主觀性比較強的問題，在問題描述

中一般不要出現帶強烈感情色彩的詞語標點符號，如“要求”、“必須”和驚嘆號等(特殊情況除外)。在提交此類問題時可以使用一些諸如“建議……”、“希望……”、“請……”之類比較委婉些的詞語。

（4） 不能確認一個現象是不是一個bug的時候可以向其他人或者開發人員進行確認，

然後再去提交。

（5） 機率性的問題，測試過程中難免遇到一些機率性問題，很難找出其產生的規律，

甚至該問題在測試過程中只出現一次，對於此類問題也一定要提交，並補充說明無法複現或者無規律。

（6） 描述問題時，要實事求是，不要誇大，比如機率性問題，本來出現的機率只有10%，

你把它寫成50%都是不應該的。

（7） 提交bug時，應該在描述清楚問題點的時候把正確的預期輸出結果寫明，即正確

的結果應該是什麼樣的，這點很重要。現在我們提交的bug中有些測試和開發雙方都知道該修改成什麼樣子了，而在bug描述中未寫出修改成什麼樣子的，如“來電時按掛機鍵不能拒接來電”這樣描述一個bug，並沒有寫明該如何修改，一般這樣描述大家一看就知道該如何修改，所以寫不寫預期正確結果大家都可以接受。但對於有些bug的描述一定要把預期的正確結果給寫進去，否則開發人員會無所適從，不知道該修改成什麼樣子的。

（8） 很多時候，提交的bug都需要重現，而有的bug是在測試過程中偶然間發現的，

時間一長，會對發現bug時的特定資料或環境模糊，導致不能重現bug。所以提交bug時描述的越詳細越好。如果語言文字難以清楚的描述出發現的問題，最好能附件圖片或者log記錄等做輔助說明。

（9） 提交測試bug的時候，如果該問題在某一特定環境下才能出現，一定要將該問題

產生的環境(硬體、軟體)描述清楚。

（10） 提交問題前要清楚的知道軟體需求、規格定義。相信很多人都遇到過這樣的尷尬

情況，提交了一個重要問題後，卻被告知其實那並不是一個問題，軟體就是那樣設計的或者需求就要求那樣處理的。

（11） 有些問題出現了，不一定就是我們測試軟體本身的問題，也可能是其他一些問題

導致的，如“手機通話時自動掉線”問題，這有可能是通道切換失敗導致的，是網路的問題，不是我們手機軟體本身的問題。類似情況還會很多，這都我們有著豐富的產品背景知識。

（12） 編寫bug report沒有什麼定式，沒有絕對的範本，最基本的是能夠讓客戶或目標修

改，瀏覽bug report人員看懂，而且在短時間內，而不需反覆思考的。其他有時要考慮目標讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨提交，bug的步驟劃分(到底是每一步都為一點，還是有些點可以合并)。在這一點上我覺得“靈活和適應”是很關鍵的。

（13） 在發現一個Bug並填寫完bug report之後，在review的時候，需要特別注意的一

點是：這個bug report會不會讓其他人還有聯想或發揮的空間。一個好的bug report是不可以細分的, 換句話說就是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。例如，有個測試人員發現在輸入16這個數字(允許範圍內)且提交時系統會返回一個錯誤：不能輸入48以下的數字。這確實是一個錯誤，但是如果就只按現在的步驟提交，另一個可能會有這樣的想法：是不是輸入48以下的數字都會有這樣的問題呢?這樣他有可能要求你在測試其他的資料。這樣就延長了這個bug的生命期，而且浪費了大家的時間。

（14） Bug提交完畢後，並不是就萬事大吉了，後續跟蹤驗證等還多著呢。

3． Bug提交之後需要注意的事項

（1） 如果編程人員需要問題重現，應盡量減少重現的步驟以達到用最少的步驟來重現

問題;這對編程人員來說是很有協助發現問題根源的。因為最少的步驟可以開發人員迅速、準確的鎖定問題的根源。

（2） 最好由報bug的人驗證bug是否可以關閉。任何人都可以修複bug，但只有那個發

現bug的人才能夠確信bug是否真正的已被修複。

（3） 當你的bug報告以“not repro(不可重現)”打回給你時，先檢查一個步驟是否有遺漏

或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現bug時才選擇這個選項。

（4） 要對提交的bug時刻進行跟蹤，要保持和編程人員的溝通交流，是bug及時得到

解決，以免影響項目的整體進度。

 

我想，作為一名軟體測試人員，即便再優秀、再喜歡這份工作，也會感覺到測試過程的枯燥乏味。有時候改掉一個bug，又會導致另一個或更多bug的出現，面對這種似乎無休止的進行下去的測試工作，心裡難免有些煩躁。但是煩躁歸煩躁，切不可讓自己的情緒過多的影響到自己的工作，時刻都要做到認真負責、腳踏實地，希望我自己也能夠這樣努力下去。

軟體測試之注意事項