流程就是好嗎?

2021-04-15 16:40:16 字數 3531 閱讀 9214

最近一直在研究從測試的角度提公升軟體質量,構建自動化測試機制。在此過程中,發現了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 受制於流程 目前的開發流程走的是典型的瀑...