前段時間經常抱怨公司不是軟件公司，沒有充足的軟件測試來保障軟件快速更迭帶來的質量保障，導致軟件質量有著嚴重的問題，最近仔細想了一下開源項目的質量保障機制，又有了一些新的收獲。

在以前的軟件開發公司，是有專門的測試人員和開發人員緊密合作，為了出同一個版本而共同奮斗，因為目的統一，所以大家的合作極其緊密，也相對不那么在意流程的約束，可以較為高效的快速修復問題。大部分時候都是看起來很美好的，不過也有不夠好的時候，那就是這樣的組合方式其實是養足了開發人員的惰性，想到反正有測試人員把關，所以也不用那么在意程序的質量。

現在的公司，不再是軟件公司，基本上可以說是沒有測試人員的，只有質量保證人員，他們的目的僅僅是站在客戶的立場上來看系統是否能夠正常運行，他們不再需要和開發人員一同為了某個時間點一同奮斗，因為他們拿到的版本就是認為基本上沒有問題的版本，如果出現問題，他們也不需要和開發一同協同努力在某個時間點內完成，只需要報出問題，待開發完成修復后，拿到下一個版本后進行驗證即可。這樣做的確有個好處就是責任明確，分工細致，不好的就是哪怕一個小小的問題，可能都會耗上40+倍（這個是毫不夸張的數量）的時間去處理。

為此，我是想破了腦袋都想不出好的解決方案，大領導曾出過主意，公司不允許這種類型的測試人員存在，他也沒有辦法，不過可以考慮找實習生負責，不過比起軟件公司開發人員和測試人員1：1的比例或者2：1的比例來說實在是太小了，實習生的不成熟，再加上測試工作本就不是一件簡單的事情，使得這樣的方案根本不可行。

其實我們現在面臨的問題就是如何讓開發人員可以自行完成測試工作，使得產品可以成熟的發布，然后結論就是只要開發人員的經驗充足，素養足夠高就可以達到了，但明顯這種團隊的成本極高，相當不合算，如果是我自己的公司，我一定會為我的開發人員們1：1的配備測試人員，這樣的話，我不需要人人都是老手且素養高，會有測試人員去逼著他們前進，測試人員也不用人人都是精英，只要能按照測試用例忠實的一步一步執行那就可以上崗了。

好吧，繞了一圈又回去了，不過這樣一繞讓我明白了，為什么軟件公司都喜歡這樣的配置了，因為這樣成本最低，且見效好。不過不管怎么說，這件事情其實對開發人員本身來說并不是很好，本來尚欠考慮質量的開發人員在保姆測試人員的嬌慣下，更是難以提高了。

在這里我又想到一個特殊的個例，那就是開源項目，參與人員一多，那就一定不能保證每一個人都能如發起人那樣的有經驗和高素養，那開源項目是如何控制質量的呢？

綜合起來看，主要是以下兩個途徑：

• 發起人審查每一段簽入主干的代碼
  
• 用測試驅動的方式配上持續集成的手段保證代碼的質量
  
  

前者可以很好的保證質量，只要發起人有足夠高的素養和足夠的責任心，便能保證代碼倉庫中的每一段代碼都如他自己寫的一樣，故代碼質量便能得到相當好的保障。

而后者則可以更加輕松的保證代碼的質量，只要整個系統的絕大部分（通常需80%以上）都被自動測試覆蓋，于是任何的代碼改動都需要通過自動測試的驗證，在大覆蓋率的前提下，只要能夠通過所有自動測試，已經說明了這段新代碼的質量，如果能輔以第一步的發起人代碼審查機制，便能充分的保障代碼質量。

這個是我在github上面常見到的場景，其實給我們提供了很好的借鑒意義，或許大幅度提高自動測試的覆蓋率才是當前解決問題的核心。