對軟體測試的要求太高？

　　1、對軟體測試的要求太高了

　　在國內培訓的時候經常遇到的一個說法：“（比如軟體測試自動化，工具，流程）的確好處很多，但是它對軟體測試的要求太高了”。剛開始的時候我很驚訝，第一次聽到對軟體測試要求太高的說法，後來聽多了才慢慢意識到這才是問題所在。如果你認為國內的測試比國外落後N年的話，我覺得“對測試的要求太高了“的觀念就是導致這個落後的根本原因。我一直在觀察和對比國內外測試的區別，當然有技術上的，工具上的，流程上的區別等等，但是這些差別都只是表象，根本的差別是觀念上的差別，也就是測試在研發中的真正角色。這個不是找到多少個bug的問題，也不是採用什麼測試方法的問題，而是是否把測試做為支撐研發兩條腿中的一條腿的問題。測試是一個專門的職業，和開發一樣有不同級別。初級人員解決簡單的事情，高階人員必須負責解決複雜，高難度的事情。這樣才能形成一個完善的測試人員職業發展體系。很多測試經理一直很困惑說我們也在加大在測試上的投資，參加很多技術、流程、管理培訓，但是效果都不好。原因就是我們不能總是希望通過學習一個技術，或一個工具來解決觀念上的問題，當然沒有效果。也容易跟風，剛學會手工測試，又要測試自動化了；剛學會測試自動化；又要ET了。剛學會ET，又要敏捷了。沒有觀念就沒有主見。所以改變觀念才是提高軟體質量的根本途徑。

　　那麼如何改變觀念呢？我也不知道。公司老闆不願改變呢？我也沒有辦法。但是重要的是你知道問題所在了，這就是解決了最大的難題。如果自己都覺得測試沒有難度，沒有前途或者對測試要求太高了的話，如何指望得了別人？所以我們搞測試的人的一個重要職責就是：把這個觀念灌輸給其他人，把測試的門檻提高，對測試的要求沒用很高只有更高，其它問題也都解決了。

　　2、Dev不願意修改bug

　　這是一個很多測試抱怨的問題：自己辛辛苦苦找到一個bug，開發卻認為不是bug。或者更？？？令人氣憤的是開發在沒有溝通之前直接resolved as “by design” or “not repro”。這個情況通常在質量控制成熟度級別（1級或2級）較低的組出現較多。根本上解決的辦法是提高整個組的成熟度級別，當然需要在很多方面加以提高，這個問題就隨之而去了。可以使用以下幾個策略：

　　首先這裡牽涉到兩個問題：一個是resolve as “not repro”的問題。很多時候dev resolve as ‘not repro’是因為bug本身不清楚沒有足夠的資訊來判斷或進一步investigate（當然他應該和你確認一下先）。所以測試在報bug是一定要記錄足夠資訊。基本原則是當別人在看該bug是否有足夠的資訊來判斷該bug是怎麼回事或進一步investigate。我總結過一個好的bug描述應該是Concise，Accurate， Searchable， Entirety， 也就是 CASE 原則。可能你會覺得這需要太多的時間才能報一個bug了。的確是，但是總比你花了兩天找到一個bug，花了10秒鐘就把bug寫完了，結果過兩天dev resolve 成not repro強吧。另外就是自動報bug的工具，還有就是建立bug模板等都可以減少報bug的時間。

　　其次是’by design’的問題。很多時候測試不服氣認為就是bug，但是開發不同意修改。我想借用一句話來說明我的觀點：a good idea is not really good until it is accepted. 也就是說如果你不可以說服別人接受你的主意，再好的主意也沒有用。同樣的道理你認為的bug，如果不能說服別人，它也不是一個bug。或者bug只有在被修復時才是真正的bug。如果dev/test有分歧的話，通常PM負責一個功能，應該有PM做最後決定；如果沒有PM的話，通常有整個team來決定。當然如果你非常肯定，可以繼續找更多的理由來支援你的觀點。但是最終如果還是不能說服別人的話，還是要服從team的決定，雖然我們常說真理往往掌握在少數人的手裡，但是絕大多數時候都是少數人考慮不周。另外一點就是我們通常很少在是不是bug上有分歧，而是在什麼時候修復上有分歧。這是另外一個話題了，需要考慮很多其它非技術因素了。

　　3、如何做到自動報bug，並把相關的資訊放到bug裡面

　　我在comments裡已經回答過了，就把它拷貝一下吧以是完整：我前面提到微軟有很多工具來提高測試人員的工作效率，也就是說把時間花在需要專注的地方而不是在其他繁瑣的地方浪費時間。其中一個好的實踐就是自動報bug。其實整個過程比較直接：首先用來管理bug的工具應該會有API介面，所以可以使用工具來自動報bug。其次是新增分析處理工具，測試的出錯資訊比較容易獲取，比如測試用例出錯了，或者拋異常或者返回錯誤結果，可以容易地把異常資訊或錯誤資訊放到bug裡面；分析產品的日誌找到錯誤點有寫難度，需要和dev共同努力把測試日誌和產品日誌通過某些屬性（時間戳或操作id）關聯起來。或者簡單地把相關日誌、windows event log，等拷貝到network share，在bug中指向該路徑即可。還有對於UI測試，如果測試錯誤，一定要把當時的螢幕截圖抓下來放到bug中去。還是那句話，專注於應該要專注的地方而不是把時間浪費在其它步驟上了，測試用例出錯，不應該花太多時間去報bug （最多2分鐘）。同樣道理有了bug後dev可以直接去investigate，而不是花時間去找日誌在那裡？那裡出錯了？等等。有條件的產品組還可以進一步提高，比如工具自動報bug的時候可以到到資料庫里根據異常或錯誤資訊查詢一遍看一看以前有沒有類似的bug，或者做BI，這些資訊對於將來的分析和決策非常有幫助，而且也可以幫助預防bug。

本文轉載自51Testing軟體測試網，檢視更多：http://www.51testing.com/html/news.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1058338/，如需轉載，請註明出處，否則將追究法律責任。