|
穩紮穩打 步步為營
公司有專門的測試組,有一次,測試組的一個同事笑着恭維我說:你寫的東西,我一般都很難挑出錯,你大概有什麼秘密武器吧!我確實有件武器,但一點都不秘密:那就是測試,測試再測試.程序員最重視的工作應該是測試.
很 多人錯誤地認為測試是軟件編寫後期的工作,即軟件完工之後,再進行測試.我認為測試不但應該融入編寫過程中,即每寫完一個函數,都要進行測試,甚至在編寫 程序之前,我們就必須考慮如何建立一個方便,快捷準確的測試系統.這就像古時候的軍隊打仗一樣,要兵馬未動,糧草先行.
測試的基本原則 是:檢驗軟件是否滿足規定的需求,確認運行結果是否符合預期結果.它是軟件質量的基本保證( oftware quality assurance ).軟件工業界喜歡將測試分成五個循序漸進的層次:單元測試,集成測試,確認測試,系統測試,驗收測試( http://en.wikipedia.org/wiki/Software_testing ).很多大軟件公司也依據這一理論,建立了嚴格的測試程序.在這裡,我不想過多介紹這些測試理論,大家在互聯網上可以找到很多這方面的資料.我只想談談我 本人在實際編碼過程中是如何進行測試的.
一般來說,我每寫完一個模塊,我就寫一個相應的MAIN程序,來測試該模塊中的每一個函數.這樣做有兩個明顯的好處:1 模塊中的每一個函數的運行結果都得到驗證; 2 如果我們能夠很方便地寫出MAIN程序,也就證明了模塊本身具有很好的獨立性,事實上也恰恰證明了模塊結構的合理性.如果我在寫這個MAIN程序的過 程中,遇到很多困難,比方說,我不得不牽扯到其他模塊,那麼我就會考慮是否我的軟件結構不太合理.模塊測試結束後,我會把這些小的MAIN程序都保留起 來.一旦我需要對模塊進行修改,我再把這些這些小程序拿出來,對修改過的模塊進行新一輪的測試.
將許多經過單獨測試的模塊融入系統之後, 我再對系統進行整體測試.在這個階段,我的很多同事喜歡立即把產品放到真實的操作環境中去測試.我不太喜歡這樣的做法.我以為真實的操作環境中有太多的不 定因數,比方說測試時間的局限,數據本身千變萬化等等.在這種情況下,一旦出現問題很難找出原因.我更喜歡,在進入真實操作環境之前,先建立一個模擬環 境.舉個例子,我曾經寫過這樣一個數據處理軟件:我從另一個軟件中得到很多數據,然後我對這些數據進行一定的加工處理,然後再將處理後的數據傳遞給另外一 個圖形軟件,該圖形軟件最後將數據顯示出來.我們可以看到,整個數據處理流程經歷了三個軟件環節.我寫的程序處在第二個環節.如果我立即將程序放到實際操 作環境中去,通過圖形軟件顯示的數據來進行測試.那麼我至少會遇到下面兩個問題:
1 數據變化很快,我無法確認圖形軟件中顯示的數據是否符合預期結果.
2 即使我能確認圖形軟件顯示的數據有誤,但是我還是無法知道問題出在哪個環節.
這 時候,最好的辦法就是編寫一個測試軟件.建立一個可控制的模擬測試系統.我的具體做法是:編寫一個簡單的測試軟件,它的工作是模擬上述數據處理流程中的環 節一和環節三.這樣它將一些可控制的模擬數據注入到數據處理軟件中,同時它又將得到處理後的數據.最後它對兩組數據進行比較,很快就能發現問題所在.也許 有人就要問了,誰能保證你的測試軟件沒有問題呢?在我看來,這個問題得從兩個方面來考慮:
1 相對於被測試的軟件,測試程序通常都比較簡單,不太容易出錯,即使有錯,也很容易修改.
2 我們應該儘量用一些高層語言來編寫測試程序.我個人最偏愛的語言是:PYTHON.
PYTHON 是一種面向對象、腳本式計算機程序設計語言.它功能強大而完善.很多任務如果用C或C++來寫,會很複雜,但轉到PYTHON,就十分簡單.我認 為,PYTHON是用底層語言工作的程序員進行測試不可缺少的工具.( http://www.python.org/ ).
程序通過了模擬系統的測試後,我們再把它放到真實的操作環境中去.一般來說,我習慣讓程序在真實環境中至少運行兩到三天.最後才將軟件交給測試組.通過這樣一個穩紮穩打, 步步為營的測試過程,軟件的質量自然有所保證了.
|
|
