淺談在軟體開發中的開發與測試 – 上

我們知道開發人員與測試人員在某種程度上可以說是冤家對頭，因為開發總是認為我做的產品是完美無缺的，沒有Bug的，但是測試總是想方設法給你挑刺，因而產生了“矛盾”。很多公司對開發的績效評估裡就有一條是每千行代碼產生的Bug量，當然是越少越好了，但是對於測試的績效評估也有一條平均每天提交的Bug量，所以表明上看起來這種矛盾真的是無法避免的，因為大家都要“混飯”吃的。

 

但是大家其實心裡都很清楚，一個產品不可能沒有Bug的，或多或少，或大或小，總是會有Bug存在，不然微軟也不會這樣經常發布補丁了，連微軟這種層級的公司都會Bug，所以對於Bug的存在，我們大可以泰然處之。

 

雖然可以泰然處之，但是對於Bug我們還是需要很重視，因為既然產生Bug，總是某一方面沒有想到或者是想錯了，所以我是建議可以通過對Bug分布進行分析，找出哪些地方特別容易出Bug，然後在開發過程中特別注意。對於我們公司而言，之前說過了我們是用TechExcel DevSuite 系統來管理，所以我們在開發中會加入幾個強制檢查項，比如說是否相容不同資料庫，是否支援不同語言，是否考慮過不同瀏覽器，開發在完成代碼如果不檢查這幾項的話，是無法把開發工作單位直接交給測試來測的，這樣就可以從某種程度上避免一些Bug的產生。

 

不過即使避免了總還是會有一些Bug會被找到的，呵呵，沒有Bug還要測試幹嘛呀？在很多公司裡測試人員的數量都大於開發人員的，像微軟這種公司，可能是2：1的關係，為什麼需要這麼多測試呢？

第一方面，當然是他們的產品太大了，太複雜了

第二方面，一個產品的品質光靠開發是不行的，因為開發雖然能把產品做出來，也可能可以用，但是他們可能沒法考慮其他一些方面，比如使用者體驗上，比如壓力測試上，比如不同語言下的應用，甚至是不同作業系統下的應用等等，這些方面光靠開發可能沒法想全，甚至即使想全了也做了，你能保證在哪些環境就一定不出問題嗎，畢竟開發編程總是在一個環境下的編的，他編完即使自己測了一下也不可能把所有環境下都測過的。

第三方面，因為一個產品/一個功能需要在很多外在環境下測試（作業系統，資料庫，瀏覽器，網路），另外一個功能需要測試點又很多（正常輸入，非正常輸入，臨界，壓力值等），所以即使是一個功能，需要測試的地方就很多，何況產品大功能多的了。而且，我們知道一個人再強，他能想到的測試點總是有限的，所以我還需要另外的人對一個已經測過的功能點進行再次驗證測試 (關於這個方面，由於我們公司是用DevSuite
方案中的 DevTest 工具來管理測試覆蓋面的，所以稍微可以減少一些測試人員配置)。另外對於一個開發來講，由於功能點是他做的，所以別人發現了問題讓他修，其實他是可以修起來很快，代碼都輕車熟路的，所以如果一個測試配一個開發的話，可能發現的Bug量無法讓開發完全忙起來，從領導角度說這個比較浪費成本的。

 

所以考慮到這些原因，一般大公司就會有很多的測試人員了，當然現在的情況又有不少改變了，隨著自動化測試的引入，需要人工的地方會相對減少，所以有不少公司開始減少純手工測試的活，但是做過開發的人也知道，如果一個產品很複雜，光靠自動化測試是遠遠不夠的，所以呢，我相信手工測試還會在很長時間記憶體在，至少在我能看到的範圍呢，好像還沒法用自動化測試來代替。

 

不過在國內的話，我接觸到的大多數軟體公司裡，對測試人員的配置都不太多，當然我不認為他們是忽視軟體品質，他們可能認為功能做出來了，開發直接測一下就好了，測試人員的話只要最後綜合跑一下就Ok了。我相信這個是怎麼保證軟體品質的一種認知的觀念問題，我認為這樣就可以保證產品品質，你認為那樣才可以保證品質，大家各有說法，但是從我們公司的角度來說，我們還是比較看重品質的，可能也跟我們公司背景有關吧，外企，跟國外比較接軌。所以我們公司現在的開發與測試組態是大於1：1的，不過比微軟還是差一點。