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

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

　　但是大家其實心裡都很清楚，一個産品不可能沒有bug的，或多或少，或大或小，總是會有bug存在，不然微軟也不會這樣經常釋出更新檔了，連微軟這種級别的公司都會bug，是以對于bug的存在，我們大可以泰然處之。

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

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

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

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

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

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

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

　　介紹了一下測試的必要性，再回過頭來繼續說開發與測試的“沖突”，其實這個沖突從本質上來說是由于績效管理時過分強調了開發人員造成的bug，而這個“過分強調”又必須是測試人員一定要強調的。是以呢，沖突就開始産生了，開發說，這個不是bug，或者說我不能重制，還說，你幹嘛老是提bug，是不是對我有啥不滿的。久而久之，“沖突”産生了，激化了，産品品質下降了......從上司層角度來說，他們當然也希望開發做出來産品是沒有bug的，這樣子我連測試人員都不用配了，成本下降很多了。當然，大多數上司也知道這個是不可能的，與其由于産品品質下降造成産品不好賣，還不如配幾個測試人員了。配了測試人員，又出現“沖突”了，我想許多公司的上司已經處理得很好了，不過我還是想簡單介紹一下我們公司的處理方案：

　　1、把産品的銷售業績與開發、測試綁定，也就是說銷售得好，獎金就多，當然要銷售得好，産品品質也得好，那就得開發與測試互相合作了。現在許多公司其實開發與測試工資與獎金比較固定，不會因為業績好而增加獎金之類的。我們公司有明确規定，這個産品利潤的百分之幾是歸開發，百分之幾歸測試，進而從制度上就讓開發與測試有了定心丸，去好好把産品品質搞好。

　　2、在對于各個銷售人員的績效考核上，增加其他考核項，把每千行bug的産生量權重降低，增加諸如，bug修複成功率，類似功能再次出現bug的百分比，與測試人員合作效率等考核項，這樣子的話，開發人員就會開始很重視和測試人員的交流，因為他們開始知道跟測試人員的合作好壞決定了他們能拿到的money。（剛才有人問怎麼拿到這些類似bug 修複成功率這種值，一般好一點的 bug 管理工具裡都能拿到，我們在 devsuite 系統裡自動生成的）

　　3、當然對測試人員也需要增加一些新的考核項，比如是bug的描述是否能讓開發一次看清楚等。

　　通過這些措施，開發與測試的效率提高很多，進而使得産品品質也提高很多。哲學上說，沖突是事物發展的動力，學會利用這種沖突來讓公司健康穩健地發展是每個成功公司需要學會的，我們公司現在來說不能算特别成功，但是我們在這個方向上前進着。

　　後序：有個朋友評論說：（以下是原話）

　　軟體測試部門是輔助軟體開發部門将産品做好！

　　他們不是對立的關系，而是互相幫助的關系。

　　現實中，經常看到研發部門看不起測試部門，而測試部門則叫闆研發部門，說産品存在如何多的問題。。。

　　牢記産品是做出來的，不是測試出來！

　　測試團隊一定要擺正自己的位置，是協助研發團隊将産品做好，提高産品品質！發現問題，跟蹤解決問題！一定不要将與研發人員的關系搞僵！

　　時刻牢記：大家是一個團隊！大家有一個共同的目标：将産品做好！開發與測試應該認識到大家是一個團隊，一個整體，隻有緊密合作才能把産品做好出來。

　　其實大方向我還是比較認同的，确實，開發和測試需要緊密合作，發揮團隊精神才能把産品做好，這樣子産品才能有機會賣好，公司也才能發展，是以這個朋友評論的話，我覺得可以認為是一種理想的開發與測試關系。但是要實作這個理想的關系，光靠這兩個部門自身是無法徹底實作的，我們需要在整個公司層面制定合理的制度，從根本上解決問題。假設我給開發的考核中代碼品質（也就是每千行出得bug數）權重很大，而給測試人員考核時每日發現bug數權重很大，勢必會造成開發與測試之間的某種沖突加劇，其實他們也知道要合作，不能有沖突，但是自己是出來打工的，你給我提這麼多bug，我錢就會少拿；我不給你提這麼多bug，我錢也少拿。 是以我寫這篇文章的目的，其實是怎麼讓開發與測試達到一個理想的關系，而不是說開發與測試應該達到一個怎麼樣的關系。