研究了幾天的代碼，今天終于把一個故障定位出來了，卻一點成就感也沒有，我為我們的過程控制感到悲哀。這是在測試部發生的一個“不可思議”的問題，說它不可思議是因為出問題的模塊已經是很老的模塊了，這個故障我們還是第一次遇到。
從故障發生的現象和現場采集的數據找到了真正的問題。這兩天我拋開開發任務，認真的研究了一下代碼的邏輯，今天終于發現原來我們的代碼里面一個全局數組的使用可能存在越界，沒有任何保護措施。這個問題說簡單也簡單，說難也難。說它簡單是因為如果認真閱讀代碼，分析每一個邏輯分支的話，這個問題是不難發現的，說它難是因為代碼的可讀性太差，直接影響人的閱讀興趣，很難讓人有興趣去分析它的每一個邏輯分支。但是如果按照軟件工程提供的單元測試方法認真進行單元測試的話，這個問題是不難測出來的，所以，前期的單元測試做的肯定不充分。
這段代碼從產生到現在已經一年半了，測試部已經在幾個版本里測試過了，但是這種錯誤一般很難從現象上表現出來的，所以測試部責任不大。但是即使開發的時候單元測試不充分，這個模塊已經有好幾個人維護過了，每個人至少都會學習一遍代碼，代碼走查也做過多次了，但是這個問題也沒人發現。這也說明每一個維護人員都沒有認真的看代碼，只關注代碼實現的功能，沒有關注代碼的邏輯處理，我也不例外，可能跟代碼的可讀性差有關系。
回想這一年來，我已經處理過好幾個代碼邏輯上的問題了，問題定位都是花費了比較長的時間的，這不是因為我的能力問題，因為不只我一個人參與定位，最后還是我分析代碼找出原因的。這些都是可以在單元測試中發現的，單元測試的時候，可能一個測試用例就可以測試出來的。
雖然單元測試和代碼走查都可能發現這種故障，但是我覺得控制單元測試比控制代碼走查更容易一些，因為代碼走查還是跟人的因素比較大，但是單元測試只要按照方法做了，人的影響不是很大。
我們的項目經理不重視單元測試，也許他們不是真的不重視，但我感覺現實是這樣的。開發階段只有一個聯調任務，再加上現在大家還是習慣于任務驅動的，單元測試只是簡單的測試自己模塊的功能沒有問題，單元測試用例的覆蓋程度也沒有衡量標準。并且每個版本到了聯調階段本來就會延期，進度上的壓力，更難做到真正的單元測試了。
單元測試差的直接后果就是我們的維護成本相當的高，版本一到測試部，開發人員是需要經常去測試部定位故障的，更為遺憾的是，有些邏輯上隱藏的故障，依靠系統測試是很難發現的，我們的代碼一旦商用，故障在網上暴露出來，付出的代價更是不可估計的。
單元測試是在開發人員控制代碼質量比較好的一個階段，我們需要重視起來，盡量把故障在開發階段就消滅掉。
文章來源于領測軟件測試網 http://www.kjueaiud.com/