【正文】 ? 問題分類 1 邏輯類問題（ A類）－指設(shè)計、編碼中出現(xiàn)的計算正確性和一致性 、程序邏輯控制等方面出現(xiàn)的問題，在系統(tǒng)中起關(guān)鍵作用，將導(dǎo)致軟件死機、功能正常實現(xiàn)等嚴(yán)重問題； 接口類問題（ B類）－指設(shè)計、編碼中出現(xiàn)的函數(shù)和環(huán)境、其他函數(shù)、全局 /局部變量或數(shù)據(jù)變量之間的數(shù)據(jù) /控制傳輸不匹配的問題，在系統(tǒng)中起重要作用，將導(dǎo)致模塊間配合失效等嚴(yán)重問題； 維護(hù)類問題（ C類）－指設(shè)計、編碼中出現(xiàn)的對軟件系統(tǒng)的維護(hù)方便程度造成影響的問題，在系統(tǒng)中不起關(guān)鍵作用，但對系統(tǒng)后期維護(hù)造成不便或?qū)е戮S護(hù)費用上升； 可測試性問題（ D類）－指設(shè)計、編碼中因考慮不周而導(dǎo)致后期系統(tǒng) 可測試性差的問題。 ? 處罰辦法 問題發(fā)生率： P=D/S D=DA++ 其中： P －問題發(fā)生率 D － 1個季度內(nèi)錯誤總數(shù) DA － 1個季度內(nèi) A類錯誤總數(shù) DB － 1個季度內(nèi) B類錯誤總數(shù) DC － 1個季度內(nèi) C類錯誤總數(shù) S － 1個季度內(nèi)收到問題報告單總數(shù) 1）當(dāng) D≥ 3時，如果 P≥ 3％，將進(jìn)行警告處理，并予以公告； 2）當(dāng) D≥ 5時，如果 P≥ 5％，將進(jìn)行罰款處理，并予以公告。 目 錄 一、邏輯類代碼問題 第 5頁 變量 /指針在使用前就必須初始化 第 5頁 【案例 】 第 5頁 防止指針 /數(shù)組操作越界 第 5頁 【案例 】 第 5頁 【案例 】 第 6頁 【案例 】 第 7頁 【案例 】 第 8頁 避免指針的非法引用 第 9頁 【案例 】 第 9頁 變量類型定義錯誤 第 10頁 【案例 】 第 10頁 正確使用邏輯與 amp。amp。、屏蔽 amp。操作符 第 17頁 【案例 】 第 17頁 注意數(shù)據(jù)類型的匹配 第 18頁 【案例 】 第 18頁 【案例 】 第 18頁 用于控制條件轉(zhuǎn)移的表達(dá)式及取值范圍是否書寫正確 第 20頁 【案例 】 第 20頁 【案例 】 第 21頁 【案例 】 第 22頁 條件分支處理是否有遺漏 第 24頁 【案例 】 第 24頁 引用已釋放的資 源 第 26頁 【案例 】 第 26頁 分配資源是否已正確釋放 第 28頁 【案例 】 第 28頁 【案例 】 第 29頁 【案例 】 第 30頁 【案例 】 第 32頁 【案例 】 第 33頁 【案例 】 第 35頁 【案例 】 第 38頁 1防止資源的重復(fù)釋放 第 39頁 【案例 】 第 39頁 1公共資源的互斥性和競用性 第 40頁 【案例 】 第 40頁 【案例 】 第 40頁 二、接口類代碼問題 第 43頁 對函數(shù)參數(shù)進(jìn)行有效性檢查 第 43頁 【案例 】 第 43頁 【案例 】 第 43頁 【案例 】 第 44頁 【案例 】 第 46頁 【案例 】 第 47頁 【案例 】 第 48頁 注意多出口函數(shù)的處理 第 49頁 【案例 】 第 49頁 三、維護(hù)類代碼問題 第 51頁 統(tǒng)一枚舉類型的使用 第 51頁 【案例 】 第 51頁 注釋量至少占代碼總量的 20％ 第 51頁 【案例 】對 XXX產(chǎn)品 BAM某版本部分代碼注釋量的統(tǒng)計 第 51頁 四、產(chǎn)品兼容性問題 第 52頁 系統(tǒng)配置、命令方式 第 52頁 【案例 】 第 52頁 【案例 】 第 53頁 設(shè)備對接 第 54頁 【案例 】 第 54頁 其他 第 55頁 【案例 】 第 55頁 五、版本控制問題 第 58頁 新老代碼中同一全局變量不一致 第 58頁 【案例 】 第 58頁 六、可測試性代碼問題 第 59頁 調(diào)試信息 /打印信息的正確性 第 59頁 【案例 】 第 59頁 一、邏輯類代碼問題 變量 /指針在使用前就必須初始化 【案例 】 C語言中最大的特色就是指針。指針的使用具有很強的技巧性和靈活性，但同時也帶來了很大的危險性。在 XXX的代碼中有如下一端對指針的靈活使用： ... ... _UC *puc_card_config_tab。 ... ... Get_Config_Table( AMP_CPM_CARD_CONFIG_TABLE, amp。ul_card_config_num, amp。puc_card_config_tab, use_which_data_area )。 ... ... b_middle_data_ok = generate_trans_middle_data_from_original_data( puc_card_config_tab, Ul_card_config_num) .... ... 其中紅色部分巧妙的利用指向指針的指針為指針 puc_card_config_tab賦值 ,而在蘭色部分使用該指針。但在 Get_Config_Table函數(shù)中有可能失敗返回而不給該指針賦值。因此，以后使用的可能是一個非法指針。 指針的使用是非常靈活的，同時也存在危險性，必須小心使用。指針使用的危險性舉世共知。在新的編程思想中，指針基本上被禁止使用（ JAVA中就是這樣），至少也是被限制使用。而在我們交換機的程序中大量使用指針，并且有增無減。 防止指針 /數(shù)組操作越界 【案例 】 在香港項 目測試中，發(fā)現(xiàn) ISDN話機撥新業(yè)務(wù)號碼時，若一位一位的撥至 18位，不會有問題。但若先撥完號碼再成組發(fā)送，會導(dǎo)致 MPU死機。 處理過程： 查錯過程很簡單，按呼叫處理的過程檢查代碼，發(fā)現(xiàn)某一處的判斷有誤，本應(yīng)為小于 18的判斷，寫成了小于等于 18。 結(jié) 論： 代碼編寫有誤。 思考與啟示： 極限測試必須注意，測試前應(yīng)對某項設(shè)計的極限做好充分測試規(guī)劃。 測試極限時還要注意多種業(yè)務(wù)接入點，本例為 ISDN。對 于交換機來說，任何一種業(yè)務(wù)都要分別在模擬話機、 ISDN話機、 V5話機、多種形式的話務(wù)臺上做測試。對于中繼的業(yè)務(wù)，則要充分考慮各種信令： TUP、 ISUP、 PRA、NO V5等等。 【案例 】 對某交換類進(jìn)行計費測試，字冠 011對應(yīng) 1號路由、 1號子路由，有 4個中繼群11,12,13,14(都屬于 1模塊 )，前后兩個群分別構(gòu)成自環(huán)。其中 11,13群向為出中繼 ,12,14群向為入中繼，對這四個群分別進(jìn)行計費設(shè)置，對出入中繼都計費。電話 60640001撥打 01160010001兩次，使四個群都有機會被計 費，取話單后瀏覽話單發(fā)現(xiàn)對 11群計費計次表話單出中繼群號不正確，其它群的計次表中出中繼群號正常。 處理過程： 與開發(fā)人員在測試組環(huán)境多次重復(fù)以上步驟，發(fā)現(xiàn) 11群的計次表話單有時正常，有時其出中繼群號就為一個隨機值，發(fā)生異常的頻率比較高。為什么其它群的話單正常，唯獨 11群不正常呢？ 11群是四個群中最小的群，其中繼計次表位于緩沖區(qū)的首位，打完電話后查詢內(nèi)存發(fā)現(xiàn)出中繼群號在內(nèi)存中是正確的，取完話單后再查就不正確了。 結(jié) 論： 話單池的一個備份指針 Pool_head_1和中繼計次表的頭指針重合，影響到第一個中繼計次表的計費。 思考與啟示： 隨機值的背后往往隱藏著指針問題，兩塊內(nèi)存緩沖區(qū)的交界處比較容易出現(xiàn)問題，在編程時是應(yīng)該注意的地方。 【案例 】 【正 文】 在接入網(wǎng)產(chǎn)品 A測試中，在內(nèi)存數(shù)據(jù)庫正常的情況下的各種數(shù)據(jù)庫方面的操作都是正常的。為了進(jìn)行數(shù)據(jù)庫異常測試，于是將數(shù)據(jù)庫內(nèi)容人為地破壞了。發(fā)現(xiàn)在對數(shù)據(jù)庫進(jìn)行比較操作時，出現(xiàn)程序跑死了現(xiàn)象。 經(jīng)過跟蹤調(diào)試發(fā)現(xiàn)問題出現(xiàn)在如下一段代碼中 : 1 for(i=0。 ipSysHeaddbf_count。 i++) 2 { 3 pDBFat = (_NM_DBFAT_STRUC *)(NVDB_BASE + DBFAT_OFFSET + i*DBFAT_LEN)。 4 if(fat_check(pDBFat) != 0) 5 { 6 pSysHeadsystem_flag = 0。 7 head_sum()。 8 continue。 9 } 10 if(strlen(dbfdbf_name) != 0 amp。amp。 strncmp(dbfdbf_name, pDBFatdbf_name, strlen(dbfdbf_name)) == 0) 11 { 12 dbf_ptr1 = (_UC *)pDBFatdbf_head。 13 filesize = pDBFatdbf_fsize。 14 break。 15 } 16 } 在測試時發(fā)現(xiàn)程序死在循環(huán)之中，得到的錯誤記錄是 Bus Error（總線出錯），由此可以說明出現(xiàn)了內(nèi)存操作異常。 經(jīng)過跟蹤變量值發(fā)現(xiàn)循環(huán)變量 i的閥值 pSysHeaddbf_count的數(shù)值為0xFFFFFFFF，該值是從被破壞的內(nèi)存數(shù)據(jù)庫中獲取的，正常情況下該值小于 127。而 pDBFat是數(shù)據(jù)庫的起始地址，如果 pSysHeaddbf_count值異常過大，將導(dǎo)致pDBFat值超過最大內(nèi)存地址值，隨后進(jìn)行的內(nèi)存操作將 導(dǎo)致內(nèi)存操作越界錯誤，因而在測試過程中數(shù)據(jù)庫破壞后就出現(xiàn)了主機死機的現(xiàn)象。 上面的問題解決起來很容易，只需在第一行代碼中增加一個判斷條件即可，如下： for(i=0。 ipSysHeaddbf_coun amp。amp。 i MAX_DB_NUM。 i++) // MAX_DB_NUM=127 這樣就保證了循環(huán)變量 i的值在正常范圍內(nèi)，從而避免了對指針 pDBFat進(jìn)行內(nèi)存越界的操作。 從上面的測試過程中，我們可以看到：如此嚴(yán)重的問題，僅僅是一個簡單的錯誤引起的。實際上，系統(tǒng)的不穩(wěn)定往 往是由這些看似很簡單的小錯誤導(dǎo)致的。這個問題給我們教訓(xùn)的是：在直接對內(nèi)存地址進(jìn)行操作時，一定要保證其值的合法性，否則容易引起內(nèi)存操作越界，給系統(tǒng)的穩(wěn)定性帶來潛在的威脅。 【案例 】 近日在 CDB并行測試中發(fā)現(xiàn)一個問題：我們需要的小區(qū)負(fù)荷話統(tǒng)結(jié)果總是為零，開始還以為小區(qū)負(fù)荷太小，于是加大短消息下發(fā)數(shù)量，但還為零，于是在程序中加入測試代碼，把收到的數(shù)據(jù)在 BAM上打印出來 , 結(jié)果打印出來的數(shù)據(jù)正常 ,不可能為零 ,仔細(xì)查看相關(guān)代碼 ,問題只可能在指針移位上有問題 ,果然在函