最近一直在研究從測試的角度提公升軟體質量，構建自動化測試機制。在此過程中，發現了n多的問題。因為本人目光短淺，只能確定在工作部門內確實存在如此問題，至於整個公司是否如此，未曾考證。本著解放思想，實事求是，一切從實際出發的馬克思列寧主義思想，總結了以下四點。
1 受制於流程
目前的開發流程走的是典型的瀑布模型，各個階段的時間按需分配好，研發人員只要按部就班的進行就好了，除了到最後大家都抱怨時間不夠用之外，好像也沒有什麼大問題了。每個人都激情飽滿投入到自己的工作中，至於這項工作為什麼要做，作了有什麼意義，就很少有人考慮到了。cmm確實是很好的開發流程，但是它只是一種工具，幫助我們提高生產力，更有效率的開發產品。做任何事情，都應該是人主動，工具只是用來提供方便，人不能讓工具牽著走。
單元測試的重要性，每個人都知道，但並不是每個人都能理解為什麼要做單元測試，作了有什麼用，相信大多數的開發人員寫單元測試都是為了應付qa的檢查。那麼為什麼我們的開發流程要有單元測試這麼一項呢？迄今為止，人類所能發現的最有效的保證軟體質量的方法就是為其編寫測試**(這樣做也是基於一種假設，即測試**是很簡單的，簡單到不能出錯的程度，所以不用編寫測試**的測試**)。因為測試**可以自動執行，可重複，而且結果，風險都是預期的，一切都可以控制在人的掌控範圍內。而我們常用的** review，除錯等手段都是不可重複，風險未知的。（不要說「高風險，高回報「 ,這句話用在這裡明顯不合適）。開發人員的程式完成後，有什麼證據能證明**的質量是合格的呢？空口無憑，這時候，測試**就是最好的證據。它將一切指標都量化在具體的可考證的測試程式上，使你的工作輸出有了可統計的書面資料。
假設程式設計師不知道上面這些道理，但是我們的領導，qa是肯定知道的，要不然也不會要有單元測試輸出了。我們可愛的程式設計師在開發結束時，也還是為qa輸出了單元測試**，有好多還達到了100%，敬業精神可嘉。現在問題來了，所有的測試**到此為止，立刻被掛起，再無人過問。 馬克思主義辯證法確實博大精神，雖然大家都學過，但是能真正領會在心的人確實不多。任何事物都是不停運動的，我們始終要以運動的眼光看待問題，而不能靜止的看問題。軟體開發是乙個不斷漸進的過程，源程式永遠不可能停在某一點上，在每一點上，我們都要對其質量進行保證。現在大家都知道要保證開發結束這個點的質量，因為提供了測試**。但是到修改乙個bug，更改乙個問題單後，在此後的每乙個點上，都沒有人關注測試**了。如果測試**只能保證很久以前的，現在已經不使用的某個版本的質量，那麼我們當初作寫測試**又是為了什麼？
任何流程都是有利有弊，我們在做事的時候要多思考，多用辯證的觀點看問題。在每天忙忙碌碌的工作中，停下5分鐘，思考一下這樣作的意義。
另外，在程式設計師編寫**的時候，如果用條條框框來限制他，而且這些條條框框對實際工作又沒有什麼實際意義，那麼他就會在其中做一些投機取巧的工作，這一點在實際工作中並不少見。所以在適當的工作中使用適當的流程很重要。
2 盲目看重**量
現在**量這個詞很時髦，大家都掛在嘴邊，數字大的人好像也是好自豪的樣子。專案的一切統計資料都是依賴於此。類似各個階段review的錯誤數，測試用例必須失敗數等等。而且有一點很不好，誰的**量大，開發速度快，誰就是程式設計高手，誰的工作輸出就多。這也是我們軟體質量一直上不去的元素之一。因為我們度量方式出了問題。實現同樣的功能，編寫1000行**可能要半個小時，但要編寫200行完成，可能就要花費1個小時或者更多。應為前者更多的是copy/paste的堆砌，只涉及很少的腦力勞動，後者則應用了更多的創造性思維在其中。出來的**質量也是顯而易見，後者更容易維護，更容易擴充套件。現在據我所知道的，部門的大部分**都是到處是copy/paste，重複，冗餘**一大片。而且很多人還陷在其中，樂此不彼。
說到這裡，想起了有一篇文章說，為什麼我們以前的產品質量很好，現在的則很差，得出的結論是人沒有了以前的那種精神。這固然是乙個方面，但我覺得還有更深層次的原因（我覺得我周圍的同志都是很有責任心，都很刻苦）。以前的軟體生產本身就侷限在當時的需求之上，並沒有考慮到以後的擴充套件，所以在架構在拓展性方面很差;很多軟體的初始版本開發工作都是新手寫的（至少通過看**可以得出這個結論），很多地方地方都是程式寫的很死，根本沒有考慮以後怎麼辦。當然，這些在當時都不是問題，所以當時的軟體質量就很好。但是現在情況不同（唯一不變的就是還是新手多），當初隱藏的問題一一都暴露出來了，我要新增乙個功能，怎麼能加進入已經成為了乙個很大的問題了。我相信每個人都有這種體會，要在乙個巨大的函式中加幾句話實現乙個新功能，這裡面充斥了大量的if/else，費了大半天看明白點後，再在裡面加上乙個if/else 實現自己的功能。如果是乙個有激情的程式設計師，想把這些**重構一下，無奈這些**的測試**早就無影無蹤了，根本就無法保證重構後的質量，也只能罷手。我們的軟體現在就是處在這樣一種惡性迴圈中，只不過現在還沒有到無法自拔的地步。
現在，迫切需要進行的是重構專案**，尤其老**，重構的結束以建立了完善的單元測試為標誌。
3 沒有完善的自動化測試機制，凡事靠人力。
作為乙個業界高階的企業，我們到現在還沒有建立起完善的自動化測試機制，凡事都要靠人力。重構裡面有一條經驗，事不過三，三必重構，說的是如果**有3個地方重複了，就要想辦法重構了。同理，若你做同樣的事情三次以上，就要考慮是否可以讓其自動進行了。我們現在的情況是，只要人能作的事情，都由人來做，人不能做的，才讓電腦作；而不是想辦法讓電腦作盡可能多的事情。（如果人能編譯程式的話，也一定會有人去做的）如果建立了完善的單元測試，自動化測試指令碼，那麼每一次出版本後都可以對這些基本功能自動測試，得出測試結果，就不用人力反覆驗證這些基本功能了。測試部之所以反對研發對程式大改，也是基於此，因為又要將所有的功能測試一遍。試想，如果所有的重複驗證工作都可以自動進行的話，那麼將節省多少精力和成本，而且出錯率比人工要低的多。當然這是乙個終極目標，但現在我們連一步都沒有邁出去。 部門經常發生問題單漏驗，版本編譯出錯等問題，其中有人的工作態度的問題，但其根本原因是我們妄圖憑人力來取代電腦的工作。人不可能做到事無鉅細，萬事總有疏漏的時候，懲罰措施再怎麼嚴厲，還是會有人會犯，只要有可能犯的錯誤，就一定會有人犯的。這一點，再完善的流程也保證不了。比如漏合入某個檔案導致版本編譯不過，其實很好解決。每乙個小時自動編譯所有檔案，按照出錯資訊的關鍵字將結果傳送給相關人員，這樣就能在第一時間發現問題，不用等到出版本的時候才知道出了問題。
只要肯想辦法，我們平時的很多任務作都可以自動化完成的。像出版本，安裝，驗證這些基本功能，只要肯作，實現起來並不難。一開始做，好像沒有什麼實際的好處，但使用的時間越長，你就可以從中受益越多。
4 盲目依賴流程
如果手裡只有一把錘子，那麼看什麼問題都想釘子。就像很多程式設計師，以為使用的是物件導向的程式語言，編出來的程式就是物件導向的。我們現在的問題是，以為只要嚴格按照流程作了，出來的產品質量就是過硬的。這就犯了教條主義錯誤。有些增強性質的專案，可能就是在某個方法加一兩句話，也要按照從需求開始的一系列流程來進行。造成巨大的資源浪費。對待問題，應該一切從實際出發，實事求是，使用最合適的手段來解決相應的問題。現在並不是我們的流程還缺什麼，而是應該從流程中去掉點什麼，使其能和具體的開發有效的結合，提高生產率。
我們的問題單驗證，版本驗證流程步驟已經很多了，可是還是不能有效的解決問題，原因是不是我們的步驟還太少？此流程建立的時代，自動化的測試工具，理念還很匱乏，所以只能憑藉繁雜的手續來保證問題的解決。但是現在，各種自動化的測試工具已經發展的很完善了（相當一部分都是開源免費的），適當的使用工具可以縮短我們的流程，提高我們的效率。
以上4點，我認為是現在急需解決的關鍵問題。如果它們都被解決了，那麼一直困擾我們的其他疑難雜症都會迎刃而解。
流程就是好嗎？
最近一直在研究從測試的角度提公升軟體質量，構建自動化測試機制。在此過程中，發現了n多的問題。因為本人目光短淺，只能確定在工作部門內確實存在如此問題，至於整個公司是否如此，未曾考證。本著解放思想，實事求是，一切從實際出發的馬克思列寧主義思想，總結了以下四點。1 受制於流程 目前的開發流程走的是典型的瀑...
流程就是好嗎？
最近一直在研究從測試的角度提公升軟體質量，構建自動化測試機制。在此過程中，發現了n多的問題。因為本人目光短淺，只能確定在工作部門內確實存在如此問題，至於整個公司是否如此，未曾考證。本著解放思想，實事求是，一切從實際出發的馬克思列寧主義思想，總結了以下四點。1 受制於流程 目前的開發流程走的是典型的瀑...
流程就是好嗎？
最近一直在研究從測試的角度提公升軟體質量，構建自動化測試機制。在此過程中，發現了n多的問題。因為本人目光短淺，只能確定在工作部門內確實存在如此問題，至於整個公司是否如此，未曾考證。本著解放思想，實事求是，一切從實際出發的馬克思列寧主義思想，總結了以下四點。1 受制於流程 目前的開發流程走的是典型的瀑...