【正文】 43頁 【案例 】 第 43頁 【案例 】 第 43頁 【案例 】 第 44頁 【案例 】 第 46頁 【案例 】 第 47頁 【案例 】 第 48頁 注意多出口函數(shù)的處理 第 49頁 【案例 】 第 49頁 三、維護(hù)類代碼問題 第 51頁 統(tǒng)一枚舉類型的使用 第 51頁 【案例 】 第 51頁 注釋量至少占代碼總量的 20％ 第 51頁 【案例 】對(duì) XXX產(chǎn)品 BAM某版本部分代碼注釋量的統(tǒng)計(jì) 第 51頁 四、產(chǎn)品兼容性問題 第 52頁 系統(tǒng)配置、命令方式 第 52頁 【案例 】 第 52頁 【案例 】 第 53頁 設(shè)備對(duì)接 第 54頁 【案例 】 第 54頁 其他 第 55頁 【案例 】 第 55頁 五、版本控制問題 第 58頁 新老代碼中同一全局變量不一致 第 58頁 【案例 】 第 58頁 六、可測(cè)試性代碼問題 第 59頁 調(diào)試信息 /打印信息的正確性 第 59頁 【案例 】 第 59頁 一、邏輯類代碼問題 變量 /指針在使用前就必須初始化 【案例 】 C語言中最大的特色就是指針。 目 錄 一、邏輯類代碼問題 第 5頁 變量 /指針在使用前就必須初始化 第 5頁 【案例 】 第 5頁 防止指針 /數(shù)組操作越界 第 5頁 【案例 】 第 5頁 【案例 】 第 6頁 【案例 】 第 7頁 【案例 】 第 8頁 避免指針的非法引用 第 9頁 【案例 】 第 9頁 變量類型定義錯(cuò)誤 第 10頁 【案例 】 第 10頁 正確使用邏輯與 amp。puc_card_config_tab, use_which_data_area )。 防止指針 /數(shù)組操作越界 【案例 】 在香港項(xiàng) 目測(cè)試中，發(fā)現(xiàn) ISDN話機(jī)撥新業(yè)務(wù)號(hào)碼時(shí)，若一位一位的撥至 18位，不會(huì)有問題。 【案例 】 對(duì)某交換類進(jìn)行計(jì)費(fèi)測(cè)試，字冠 011對(duì)應(yīng) 1號(hào)路由、 1號(hào)子路由，有 4個(gè)中繼群11,12,13,14(都屬于 1模塊 )，前后兩個(gè)群分別構(gòu)成自環(huán)。為了進(jìn)行數(shù)據(jù)庫異常測(cè)試，于是將數(shù)據(jù)庫內(nèi)容人為地破壞了。 9 } 10 if(strlen(dbfdbf_name) != 0 amp。 上面的問題解決起來很容易，只需在第一行代碼中增加一個(gè)判斷條件即可，如下： for(i=0。 【案例 】 近日在 CDB并行測(cè)試中發(fā)現(xiàn)一個(gè)問題：我們需要的小區(qū)負(fù)荷話統(tǒng)結(jié)果總是為零，開始還以為小區(qū)負(fù)荷太小，于是加大短消息下發(fā)數(shù)量，但還為零，于是在程序中加入測(cè)試代碼，把收到的數(shù)據(jù)在 BAM上打印出來 , 結(jié)果打印出來的數(shù)據(jù)正常 ,不可能為零 ,仔細(xì)查看相關(guān)代碼 ,問題只可能在指針移位上有問題 ,果然在函數(shù)中發(fā)現(xiàn)一處比較隱蔽的錯(cuò)誤。 。于是初步定位為主機(jī)在 DSL端口處理過程中有重大錯(cuò)誤。此時(shí)主機(jī)在取進(jìn)行判斷，就不知會(huì)導(dǎo)致什么后果了。 變量類型定義錯(cuò)誤 【案例 】 【正 文】 在 FRI板上建幾條 FRPVC，其 DLCI類型分 別為： 10Bit/2bytes、10bit/3bytes、 16bit/3bytes、 17bit/4bytes、 23bit/4bytes。 ID LowPVCEP。 DWORD dwCCID, dwPeerCCID。 [wCount].wHdlcPort = wHdlcPort。 DWORD dwMapMode, dwCIR, dwBe。 WORD wPeerHdlcPort, wPeerOldAtmPort。相應(yīng)的 DLCI值為： 123 99 12697 1234567，然后保存，重起 MUX，觀察 PVC的恢復(fù)情況，結(jié)果 DLCI值為 1 234和 991的 PVC正確恢復(fù)，而 DLCI=126975的 PVC恢復(fù)的數(shù)據(jù)錯(cuò)誤為 61439，而 DLCI=1234567的 PVC完全沒有恢復(fù)。 DWORD dwDlciVal[5][2] = { {16,1007}, {16,1007}, {1024,64511}, {2048,129023}, {131072,4194303} } 。 WORD wHdlcPort, wAtmPort, wIci, wPeerIci, wPeerHdlcPort 。 [wCount].wHdlcDlci = gFrPVCEP[bSlotID ][ gFrPVCC[bSlotID][dwCCID].dwLoPVCEP ].dwDLCI。 DWORD dwCCID, dwResult, dwAtmPort。 ．．． } 其中涉及 DLCI值的變量都為 WORD（即無符號(hào)短整型）類型，在程序的處理時(shí)，出現(xiàn) WORD和 DWORD（無符號(hào)長(zhǎng)整型）類型在一句中同時(shí)存在的情況，至此可以判斷問題出在這里。、屏蔽 amp。 第一個(gè)語句求欲重發(fā) 的消息包個(gè)數(shù)，第二個(gè)語句求重發(fā)的起始位置，當(dāng) Vs小于n_r時(shí)，將造成實(shí)際重發(fā)數(shù)小于欲重發(fā)數(shù)，同時(shí)造成實(shí)際起始重發(fā)位置和欲重發(fā)起始位置錯(cuò)開，從而引起鏈路復(fù)位。）和求模（ %）這小小的區(qū)別，造成的竟是鏈路復(fù)位這種嚴(yán)重的錯(cuò)誤。amp。 TUP也會(huì)產(chǎn)生如此錯(cuò)誤。 在 byMsg1大于 127時(shí)，輸出錯(cuò)誤的結(jié)果。i++) { wCheckSum^=(*pCheck)。但近期測(cè)試發(fā)現(xiàn)，如果兩局通過 DT板進(jìn)行一號(hào)對(duì)接， MPU備份倒換卻發(fā)生斷話。執(zhí)行如下命令： LST AMA: TP=NRM, SD=1999amp。 反饋到開發(fā)人員那里，發(fā)現(xiàn)該現(xiàn)象與設(shè)計(jì)的初衷是相違背的。//退出第二層循環(huán) , while(timeCur = timeEnd) break。 if ( ( bsn % 16 ) == 7 || ( bsn % 16 ) == 8 ) return TRUE。 return FALSE。 //查詢數(shù)據(jù)庫成功 if( error_code == DB_SUCCESS ) { // Max2B1QStatTime配置的值 if ( MAX_2B1Q_STAT_PSN ) Max2B1QStatTime = MAX_2B1Q_STAT_PSN。 } 此處 ifelse if 分支沒有判斷 值為 0的情況，即數(shù)據(jù) 庫為Max2B1QStatPortNum配置的值為 0： == 0，則Max2B1QStatPortNum就為缺省值 32。 呼叫幾萬次后停止呼叫，取話單進(jìn)行觀察。 【案例 】 【案例描述】 在進(jìn)行 128模塊 V5用戶 CENTREX新業(yè)務(wù)測(cè)試時(shí)，偶然遇到一個(gè)怪現(xiàn)象：對(duì)群內(nèi)一個(gè) V5ST用戶只開放 MCT權(quán)限，在進(jìn)行惡意呼叫追查時(shí)，有一次報(bào)惡意呼叫追查成功音只報(bào)了一半，當(dāng)正要報(bào)出惡意呼叫的號(hào)碼時(shí)，業(yè)務(wù)中斷重新回到通話態(tài)，隨即重新追查一次，報(bào)“已申請(qǐng)其它新業(yè)務(wù)，本次申請(qǐng)不成功”。 在追查這個(gè)問題時(shí)，開發(fā)人員 A又發(fā)現(xiàn)了一個(gè)可能導(dǎo)致死機(jī)的嚴(yán)重問題：在用戶啟動(dòng) MCT服務(wù) , 正在聽報(bào)追查號(hào)碼的 MCT音時(shí) , 若惡意用戶此時(shí)掛機(jī) , CCB的處理中 , 只針對(duì) ST用戶送 DISCONNECT, 而對(duì) V5ST用戶送的是RELEASE消息 , 這導(dǎo)致 V5X收到此消息后 , 將該 V5ST用戶的 cr2清除掉 , V5_USER_TALBE[ ]. cr2變?yōu)?0xFFFF, 這樣在 V5_CR_VOICETONE超時(shí)后 , 程序中會(huì)檢查 cr2的 狀態(tài)是否為 HOLD, 當(dāng)取 cr2的內(nèi)容時(shí) , 由于 cr2已被清除 , 會(huì)發(fā)生指針越界的 GP錯(cuò)誤。如何定位這個(gè)問題呢？ 定位這種問題可以利用 WINDOWS中的一個(gè)系統(tǒng)資源監(jiān)視工具。 通過以上的步驟，終于找出引起資源耗盡的罪魁禍?zhǔn)住? //If a warn with a certain Csn is not in EventFilterIndex //it is not necessary to be added to HistoryFilterIndex int item_total=()。 } //建議在此處加上 : // else // delete item。下面舉幾種常見的內(nèi)存泄漏錯(cuò)誤，供測(cè)試人員在代 碼審查中參考： 1. 函數(shù)有多個(gè)出口時(shí)，沒有在每個(gè)出口處對(duì)動(dòng)態(tài)申請(qǐng)的內(nèi)存進(jìn)行釋放。請(qǐng)看如下代碼段： .... struct FileInfo * pdbffile = new struct FileInfo。 dbf_Finish = FALSE。 if( pMsgDBApp_To_Logic == NULL ) return。 if( Msg_Queue[ces].msghead != NULL_PTR )//message buffer notempty { //get first message record pMsgRecord = Msg_Queue[ces].msghead。 static void OncePowerCmdHandle( struct HT_Appmsg * msg ) { ... ... pPower_test_answer =(struct _oncepower_test_answer *)GetBuff(sizeof(struct _oncepower_test_answer),__LINE__)。 if(FALSE == Copy(TRUE)) { dbf_start_needed = TRUE。 pdbffilesrame = srcRootPath。下面的代碼段就是這樣的例子： ..... pRecord = new char[pTableGetRecordLength()]。 有的程序員認(rèn)為，后臺(tái)運(yùn)行的環(huán)境有大量?jī)?nèi)存，幾個(gè)字節(jié)的浪費(fèi)不會(huì)造成死機(jī)等重大事故。 for(int k=0。 【案例 】 【正 文】 某產(chǎn)品后臺(tái)軟件版本，是用 C++寫的，程序員在寫代碼時(shí)，經(jīng)常在構(gòu)造函數(shù)中申請(qǐng)一塊內(nèi)存，而不釋放，在程序其他代碼中也經(jīng)常只管申請(qǐng)，不管釋放。 工具有了，那么如何發(fā)現(xiàn)導(dǎo)致不斷消耗資源的特定操作呢？ 首先和開發(fā)人員共同探討，列出幾個(gè)最可能消耗資源的操作和一些操作組合，這樣就縮小了監(jiān)視范圍，避免沒有范圍的碰運(yùn)氣，否則如大海撈針。 【思考與啟示】 我們平常一些熟視無睹的業(yè)務(wù)或按正常流程操作沒有問題的業(yè)務(wù)，不能保證它就一定沒有問題，要善于抓住一絲一毫的異常現(xiàn)象。為了重現(xiàn)，再次掛機(jī)，重新呼叫，應(yīng)用此新業(yè)務(wù)，但這個(gè)現(xiàn)象一直沒有出現(xiàn)。 通知開發(fā)人員后，首先我們?cè)俅螌?duì)計(jì)費(fèi)數(shù)據(jù)進(jìn)行了確認(rèn)。 造成這種錯(cuò)誤的原因是判斷語句對(duì)條件判斷不完整。 } //查詢數(shù)據(jù)庫，獲得 Max2B1QStatPortNum的值 = 11。 判斷條件較多時(shí)開發(fā)人員也應(yīng)該適當(dāng)分開寫，既使代碼更易讀，又不容易出錯(cuò)。 作者的本意是如果是 32路用戶板（藍(lán)色字體判斷），就看端口號(hào)是否是第 15和 16路，如果是，就是反極性端口，返回 TRUE，否則就不是，應(yīng)該返回 FALSE。 一些 MML命令從完成的功能來講可能是沒什么問題的，但其執(zhí)行對(duì)系統(tǒng)性能的影響我們?cè)跍y(cè)試時(shí)時(shí)往往給 忽視了。查看一下源代碼，問題就發(fā)現(xiàn)了。1, SA=YES。 【處理過程】： 據(jù)查， MPU倒換時(shí)會(huì)自動(dòng)復(fù)位處于“故障”態(tài)的電路，但由于計(jì)算錯(cuò)誤（多加了 32），錯(cuò)復(fù)位了下一個(gè) PCM系統(tǒng) 32路電路。 } //binlen had already word alignment return (wCheckSum)。下面兩個(gè)例子是該類錯(cuò)誤的兩種典型情況： 【例三】 file02文件中某函數(shù)中如下代碼，可能造成死循環(huán)： ...... int i。 【案例 】 【正 文】 當(dāng)我們使用 PCLINT檢查代碼時(shí)，會(huì)發(fā)現(xiàn)大量的數(shù)據(jù)類型不匹配的告警，大部分情況下，這種代碼上存在的問題并不會(huì)引起程序功能實(shí)現(xiàn)上的錯(cuò)誤，但有些情況下，也許會(huì)產(chǎn)生嚴(yán)重的問題： 一、不同數(shù)據(jù)類型變量之間賦值引起的問題，實(shí)際上，該類問題也可以分為幾