from http://blog.csdn.net/feixiaoxing/article/details/40480189
聯(lián)系信箱：feixiaoxing @163.com
很多工程師都有一個(gè)不好的習(xí)慣，因?yàn)榇蠖鄶?shù)it工程師都喜歡寫代碼，但是不喜歡測試代碼。在他們眼里，把功能做出來是一件很牛逼的事情，而軟件測試則是一件低級、價(jià)值量不高的事情。事實(shí)上是否真的如此呢，恐怕未必。姑且不談你寫的這份代碼是否真的會(huì)給用戶或者消費(fèi)者帶來價(jià)值，但是一份極其不穩(wěn)定甚至?xí)r常崩潰的軟件，肯定不會(huì)帶來什么好感，這也就意味著公司投資你作了這個(gè)勞動(dòng)很可能是個(gè)無用功。這個(gè)問題其實(shí)不光小公司有，大公司也是如此。
（1）很多朋友沒有代碼質(zhì)量意識。一份軟件的價(jià)值，一方面體現(xiàn)在是否可以滿足客戶的需求，另一方面也體現(xiàn)在它是否可以穩(wěn)定長久地運(yùn)行。代碼運(yùn)行的時(shí)間越長、越穩(wěn)定和健壯，這樣才能最大程度保留代碼的價(jià)值。
（2）測試工程師遠(yuǎn)沒有開發(fā)工程師了解代碼的健康程度。很多公司的測試工程師只是按照黑盒的方法對軟件進(jìn)行測試，這些測試的內(nèi)容包括了功能、易用性、邊界測試、兼容性、性能等等，但是這些測試都沒有開發(fā)者自己寫的單元測試重要。大多數(shù)單元測試可以在第一時(shí)間發(fā)現(xiàn)問題、解決問題，而不是等到測試的時(shí)候來進(jìn)行解決。如果開發(fā)者覺得代碼哪寫的好像有問題，那么十有八九有問題。只是個(gè)時(shí)間問題而已。
（3）好代碼是不停修改和重構(gòu)得來的。之前看了很多的代碼，這包括vxworks、gcc、linux、mysql等等，它們中的很多代碼從上個(gè)世紀(jì)八九十年代就已經(jīng)存在了，到今天還在修改。有的是重新調(diào)整流程，有的是為了適配新的cpu，還有的是為了兼容新的設(shè)備特性。所以說，一份健康的代碼需要反復(fù)的測試、反復(fù)的重構(gòu)、反復(fù)的運(yùn)行，沒有什么是一層不變的。在服務(wù)器上運(yùn)行的很多系統(tǒng)代碼，不知道經(jīng)過了多少次推倒重來的修改，經(jīng)過了多少次作者的代碼檢查，估計(jì)只有真正經(jīng)歷的人才知道。
（4）現(xiàn)有的工具可以極大地幫助我們進(jìn)行代碼的各種測試，我有一篇文章談到了這些工具。比如說，CUnit可以幫助我們進(jìn)行單元測試；splint可以進(jìn)行代碼的靜態(tài)檢查；valgrind可以進(jìn)行代碼的泄漏測試；gcov可以進(jìn)行覆蓋率的測試；gprof可以進(jìn)行代碼性能的統(tǒng)計(jì)測試；gdb的watch功能可以直接幫助我們檢查數(shù)據(jù)是否越界；core dump可以幫助我們保存程序的相關(guān)內(nèi)存信息，為我們逆向調(diào)試提供了方便。當(dāng)然，上面說的都是linux上面的工具，大家可以根據(jù)自己的環(huán)境，看看有沒有什么合適的工具幫到自己提高一下代碼的質(zhì)量。
（5）有些錯(cuò)誤是隨機(jī)的，但是有一定的概率性。這就要求我們對相關(guān)數(shù)據(jù)的輸入、輸出進(jìn)行記錄和處理。實(shí)現(xiàn)這個(gè)功能不難，用fprintf和fscanf就可以做到，下面是我自己寫的一份簡單代碼，算是拋磚引玉之用，
