【正文】 軟件編程規(guī)范培訓(xùn)實(shí)例與練習(xí)? 問題分類1 邏輯類問題（A類）－指設(shè)計(jì)、編碼中出現(xiàn)的計(jì)算正確性和一致性、程序邏輯控制等方面出現(xiàn)的問題，在系統(tǒng)中起關(guān)鍵作用，將導(dǎo)致軟件死機(jī)、功能正常實(shí)現(xiàn)等嚴(yán)重問題； 接口類問題（B類）－指設(shè)計(jì)、編碼中出現(xiàn)的函數(shù)和環(huán)境、其他函數(shù)、全局/局部變量或數(shù)據(jù)變量之間的數(shù)據(jù)/控制傳輸不匹配的問題，在系統(tǒng)中起重要作用，將導(dǎo)致模塊間配合失效等嚴(yán)重問題； 維護(hù)類問題（C類）－指設(shè)計(jì)、編碼中出現(xiàn)的對軟件系統(tǒng)的維護(hù)方便程度造成影響的問題，在系統(tǒng)中不起關(guān)鍵作用，但對系統(tǒng)后期維護(hù)造成不便或?qū)е戮S護(hù)費(fèi)用上升； 可測試性問題（D類）－指設(shè)計(jì)、編碼中因考慮不周而導(dǎo)致后期系統(tǒng)可測試性差的問題。? 處罰辦法 問題發(fā)生率： P=D/S D=DA++ 其中： P －問題發(fā)生率 D －1個(gè)季度內(nèi)錯(cuò)誤總數(shù) DA －1個(gè)季度內(nèi)A類錯(cuò)誤總數(shù) DB －1個(gè)季度內(nèi)B類錯(cuò)誤總數(shù) DC －1個(gè)季度內(nèi)C類錯(cuò)誤總數(shù) S －1個(gè)季度內(nèi)收到問題報(bào)告單總數(shù) 1）當(dāng)D≥3時(shí)，如果P≥3％，將進(jìn)行警告處理，并予以公告； 2）當(dāng)D≥5時(shí)，如果P≥5％，將進(jìn)行罰款處理，并予以公告。目 錄一、邏輯類代碼問題第5頁變量/指針在使用前就必須初始化第5頁【】第5頁防止指針/數(shù)組操作越界第5頁【】第5頁【】第6頁【】第7頁【】第8頁避免指針的非法引用第9頁【】第9頁變量類型定義錯(cuò)誤第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)計(jì)第51頁四、產(chǎn)品兼容性問題第52頁系統(tǒng)配置、命令方式第52頁【】第52頁【】第53頁設(shè)備對接第54頁【】第54頁其他第55頁【】第55頁五、版本控制問題第58頁新老代碼中同一全局變量不一致第58頁【】第58頁六、可測試性代碼問題第59頁調(diào)試信息/打印信息的正確性第59頁【】第59頁一、邏輯類代碼問題變量/指針在使用前就必須初始化【】 C語言中最大的特色就是指針。指針的使用具有很強(qiáng)的技巧性和靈活性，但同時(shí)也帶來了很大的危險(xiǎn)性。在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ù)中有可能失敗返回而不給該指針賦值。因此，以后使用的可能是一個(gè)非法指針。指針的使用是非常靈活的，同時(shí)也存在危險(xiǎn)性，必須小心使用。指針使用的危險(xiǎn)性舉世共知。在新的編程思想中，指針基本上被禁止使用（JAVA中就是這樣），至少也是被限制使用。而在我們交換機(jī)的程序中大量使用指針，并且有增無減。防止指針/數(shù)組操作越界【】 在香港項(xiàng)目測試中，發(fā)現(xiàn)ISDN話機(jī)撥新業(yè)務(wù)號碼時(shí)，若一位一位的撥至18位，不會有問題。但若先撥完號碼再成組發(fā)送，會導(dǎo)致MPU死機(jī)。 處理過程： 查錯(cuò)過程很簡單，按呼叫處理的過程檢查代碼，發(fā)現(xiàn)某一處的判斷有誤，本應(yīng)為小于18的判斷，寫成了小于等于18。 結(jié) 論： 代碼編寫有誤。思考與啟示： 極限測試必須注意，測試前應(yīng)對某項(xiàng)設(shè)計(jì)的極限做好充分測試規(guī)劃。 測試極限時(shí)還要注意多種業(yè)務(wù)接入點(diǎn)，本例為ISDN。對于交換機(jī)來說，任何一種業(yè)務(wù)都要分別在模擬話機(jī)、ISDN話機(jī)、V5話機(jī)、多種形式的話務(wù)臺上做測試。對于中繼的業(yè)務(wù)，則要充分考慮各種信令：TUP、ISUP、PRA、NOV5等等?！尽?對某交換類進(jìn)行計(jì)費(fèi)測試，字冠011對應(yīng)1號路由、1號子路由，有4個(gè)中繼群11,12,13,14(都屬于1模塊)，前后兩個(gè)群分別構(gòu)成自環(huán)。其中11,13群向?yàn)槌鲋欣^,12,14群向?yàn)槿胫欣^，對這四個(gè)群分別進(jìn)行計(jì)費(fèi)設(shè)置，對出入中繼都計(jì)費(fèi)。電話60640001撥打01160010001兩次，使四個(gè)群都有機(jī)會被計(jì)費(fèi)，取話單后瀏覽話單發(fā)現(xiàn)對11群計(jì)費(fèi)計(jì)次表話單出中繼群號不正確，其它群的計(jì)次表中出中繼群號正常。處理過程： 與開發(fā)人員在測試組環(huán)境多次重復(fù)以上步驟，發(fā)現(xiàn)11群的計(jì)次表話單有時(shí)正常，有時(shí)其出中繼群號就為一個(gè)隨機(jī)值，發(fā)生異常的頻率比較高。為什么其它群的話單正常，唯獨(dú)11群不正常呢？11群是四個(gè)群中最小的群，其中繼計(jì)次表位于緩沖區(qū)的首位，打完電話后查詢內(nèi)存發(fā)現(xiàn)出中繼群號在內(nèi)存中是正確的，取完話單后再查就不正確了。結(jié) 論： 話單池的一個(gè)備份指針Pool_head_1和中繼計(jì)次表的頭指針重合，影響到第一個(gè)中繼計(jì)次表的計(jì)費(fèi)。思考與啟示： 隨機(jī)值的背后往往隱藏著指針問題，兩塊內(nèi)存緩沖區(qū)的交界處比較容易出現(xiàn)問題，在編程時(shí)是應(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)行比較操作時(shí)，出現(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 } 在測試時(shí)發(fā)現(xiàn)程序死在循環(huán)之中，得到的錯(cuò)誤記錄是Bus Error（總線出錯(cuò)），由此可以說明出現(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)存操作越界錯(cuò)誤，因而在測試過程中數(shù)據(jù)庫破壞后就出現(xiàn)了主機(jī)死機(jī)的現(xiàn)象。 上面的問題解決起來很容易，只需在第一行代碼中增加一個(gè)判斷條件即可，如下：　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試過程中，我們可以看到：如此嚴(yán)重的問題，僅僅是一個(gè)簡單的錯(cuò)誤引起的。實(shí)際上，系統(tǒng)的不穩(wěn)定往往是由這些看似很簡單的小錯(cuò)誤導(dǎo)致的。這個(gè)問題給我們教訓(xùn)的是：在直接對內(nèi)存地址進(jìn)行操作時(shí)，一定要保證其值的合法性，否則容易引起內(nèi)存操作越界，給系統(tǒng)的穩(wěn)定性帶來潛在的威脅。 【】 近日在CDB并行測試中發(fā)現(xiàn)一個(gè)問題：我們需要的小區(qū)負(fù)荷話統(tǒng)結(jié)果總是為零，開始還以為小區(qū)負(fù)荷太小，于是加大短消息下發(fā)數(shù)量，但還為零，于是在程序中加入測試代碼，把收到的數(shù)據(jù)在BAM上打印出來, 結(jié)果打印出來的數(shù)據(jù)正常,不可能為零,仔細(xì)查看相關(guān)代碼,問題只可能在指針移位上有問題,果然在函數(shù)中發(fā)現(xiàn)一處比較隱蔽的錯(cuò)誤。/* 功能:一個(gè)BM模塊內(nèi)所有小區(qū)CDB側(cè)廣播消息忙閑情況 *//*************************************************************/void Cell_CBCH_Load_Static(struct MsgCB FAR *pMsg) { 。 memcpy((_UC *)amp。tmp_msg,pMsg,sizeof(tmp_msg))。 pMsg=pMsg+sizeof(tmp_msg)。//sizeof(tmp_msg)=10。本意是想移動10個(gè)字節(jié),可是實(shí)際上指針移動了10*sizeof(struct MsgCB)個(gè)字節(jié)。 CellNum=。 。 }1 所以結(jié)構(gòu)指針傳入函數(shù)后，如要進(jìn)行指針移動操作，最好先將其轉(zhuǎn)化為_UC型再說?？傊羔槻僮饕⌒臑樯稀１苊庵羔樀姆欠ㄒ谩尽俊菊? 文】在一次測試中，并沒有記得做了什么操作，發(fā)現(xiàn)HONET系統(tǒng)的主機(jī)復(fù)位了，之后，系統(tǒng)又工作正常了。由于沒有打開后臺的跟蹤窗口，當(dāng)時(shí)查了半天沒有眉目。過了半天，現(xiàn)象又出現(xiàn)了，而且這次是主機(jī)在反復(fù)復(fù)位，系統(tǒng)根本無法正常工作了。我憑記憶，判斷應(yīng)該是與當(dāng)時(shí)正在測試的DSL板的端口配置有關(guān)。于是將板上所有端口配置為普通2B+D端口，重新加載在主機(jī)數(shù)據(jù)，現(xiàn)象消失。于是初步定位為主機(jī)在DSL端口處理過程中有重大錯(cuò)誤。我在新的數(shù)據(jù)上努力恢復(fù)原出問題的現(xiàn)象，卻一直沒有重現(xiàn)，于是恢復(fù)原數(shù)據(jù)，加載后立即重現(xiàn)。并注意到，當(dāng)DSL端口激活時(shí)，主機(jī)復(fù)位。仔細(xì)比較兩種數(shù)據(jù)的差別，發(fā)現(xiàn)出現(xiàn)主機(jī)復(fù)位問題的數(shù)據(jù)中DSL板配置了MNT/MLT端口，但是沒有做DSL端口之間的半永久數(shù)據(jù)。于是在程序中不斷加打印語句，通過后臺的DBWIN調(diào)試程序跟蹤，最后終于定位為：()函數(shù)中處理U口透傳的if ( SPC_STATE_OK == pSpcCBbySpcState )語句時(shí)，主機(jī)復(fù)位。但是該語句似乎并無不妥。再分析整個(gè)函數(shù)，pSpcCB在函數(shù)前部分已經(jīng)被賦值，pSpcCB = SpcCB + (PortTable+index)spcNo。但由于得到 index 后，沒有任何判斷，導(dǎo)致若MNT/MLT端口沒有做半永久，端口激活后，執(zhí)行此部分函數(shù)，(PortTable+index)spcNo 有可能為NULL_WORD，于是，運(yùn)算后，pSpcCB 可能為非法值。此時(shí)主機(jī)在取進(jìn)行判斷，就不知會導(dǎo)致什么后果了。其實(shí)，改起來很簡單，只要在這兩句前增加一個(gè)判斷就行了。于是，修改代碼為：if ( (PortTable+