【正文】 象，最終網(wǎng)管系統(tǒng)反應很慢，無法正常工作。操作后，觀察此時的資源狀況，并記下此時的數(shù)據(jù)，與操作前的數(shù)據(jù)比較，如果操作前后的數(shù)據(jù)數(shù)據(jù)沒有變化或變化很小，可排除此項操作，否則就可斷定此項操作會引起資源耗盡。 itemCsn=Buffer[EVENT_ALARM][m].Csn。 } if(find_flag) { (item)。這個地方不注意也是原因之一吧。 delete[] pRecord。 //賦值之前沒有檢查一下 pfile是否為空，如果不為空，會造成 pfile指向的內存丟失。 if( pMsgDB_DEV == NULL ) return。測試人員在作代碼審查時，對上述幾種情況要尤其注意。 ... ... if (TSS_State[testpsn].state == TEST_DEV_BUSY || TSS_State[testpsn].state == TEST_DEV_ERROR ) {... } else if (TSS_State[testpsn].state == TEST_DEV_IDLE ) {... } // 缺少 else 分支，可能造成 pPower_test_answer 得不到釋放 } 造成內存泄漏的情況很多，以上是幾種典型的情況。 } } 3. 連續(xù)二次內存動態(tài)分配，在第二次分配失敗時，忘記釋放第一次已經(jīng)申請到的內存。 pdbffileprev = NULL。 if (pTableGoTop(FALSE) != DBIERR_NONE) return。 實際上，這種思想是造成我們產(chǎn)品不穩(wěn)定的原因之一。k++) if(EventFilterIndex[k]Csn==itemCsn) { find_flag=true。mRecordsInBuffer[EVENT_ALARM]。 然后針對一個可疑的操作，快速大量地重復進行。說老實話，我們的產(chǎn)品還有 許多問題 ，需要我們扎扎實實鍥而不舍的工作。 【處理過程】 出現(xiàn)這個問題后，及時與開發(fā)人員 A取得了聯(lián)系，并一起試圖重現(xiàn)這個問題，通過許多次的反復操作，又出現(xiàn)了一次這種情況。開發(fā)人員認為是 CCB的問題，后來一查果然如此。好多問題就是因為條件判斷不完全造成的。directQueryCond, (BYTE FAR *)amp。 【處理過程】 該錯誤比較隱蔽，現(xiàn)在說明如下： Max2B1QStatTime 最大統(tǒng)計時間 Max2B1QStatPortNum最大統(tǒng) 計端口數(shù) MAX_2B1Q_STAT_PSN 最大統(tǒng)計內存分配數(shù)量 其中： Max2B1QStatTime（最大統(tǒng)計時間）和 Max2B1QStatPortNum （最大統(tǒng)計 端口數(shù)）的乘積不能大于 MAX_2B1Q_STAT_PSN 程序如下： //查詢數(shù)據(jù)庫，獲得 Max2B1QStatTime的值 = 10。 當端口在 32路用戶板上，但端口號不是 15或 16時，不同的 32路端口的起始地址 g_wASL32StartPSN，會導致不同的非 1 16端口被誤認為是反極性端口。這是在設計時要避免的，在測試中要注意的問題。//加一天 while((amp。重建連接后，發(fā)現(xiàn)話單臺的命令不能執(zhí)行。 【思考與啟示】： 自環(huán)是在測試環(huán)境下常用的一種提高效率的手段，但一旦條件允許，我們的測試工作應盡量模擬網(wǎng)上的實際環(huán)境進行。 上面的例子是不同類型變量之間直接比較操作，還有一種情況是函數(shù)的返回值與另一不同類型的變量比較，見下面例子： 【例四】 ， while( ftell(fp) Part[3]) {..... } ftell返回 long型，而 Part是 DWORD型，有符號變量和無符號變量的比較，可能造成死循環(huán)。 WORD wCheckSum=*pCheck。 char型強制轉換成 WORD型。 【結 論】 為數(shù)據(jù)超出范圍溢出造成， int值賦值給 BYTE，造成數(shù)據(jù)丟失。 首先試 BSN參數(shù)越界情況，即參數(shù) BSN超過 32路查詢，選了幾個數(shù)據(jù)段，問題就出來了。 MOD128 。 在函數(shù) L2_TO_L1()中，有如下語句： linkstate_ptr = (head + 1) % W_MOD 。 至此， DLCI數(shù)據(jù)恢復出錯的原因完全找到，解決的方 法是將 DLCI的類型改為 DWORD類型。 DWORD dwResult。 ．．． } DWORD RestoreFrNetExtIWFData ( WORD wSlotID, BYTE *pReadPoint ) { WORD wCount, wTotalNetIWF。 WORD wHdlcPort, wAtmPort, wIci 。 WORD wPeerOldAtmPort。帶著這個目的查看原代碼，發(fā)現(xiàn)在以下代碼中有問題： int _GetFrDlci( DWORD* dwDlci, char* str, DWORD dwDlciType, DWORD dwPortType, DWORD dwSlotID, DWORD dwPortID) { DWORD tempDlci。 另一個問題是為什么 23/4類型的 DLCI數(shù)據(jù)不能恢復？這是由于對于 23/4類型的 PVC，其 DLCI的取值范圍為： 131072~4194303，而程序強制轉換并恢復的數(shù)據(jù)最大只能是 65535，所以這條 PVC不能恢復。 DWORD dwCCID, dwPeerCCID, dwAtmPort, dwPeerAtmPort。 [wCount].dwMapMode = gFrPVCC[bSlotID][dwCCID].dwMapMode。 DWORD dwCCID, dwPeerCCID。 WORD wPeerHdlcDlci。 至此基本可以斷定原因就是出在這里。 } } 修改后，問題不再重現(xiàn)。 于是在程序中不斷加打印語句，通過后臺的 DBWIN調試程序跟蹤，最后終于定位為：每當執(zhí)行到 DeviceDslMsgProc()函數(shù)中處理 U口透傳的 if ( SPC_STATE_OK == pSpcCBbySpcState ) 語句時，主機復位。由于沒有打開后臺的跟蹤窗 口，當時查了半天沒有眉目。 pMsg=pMsg+sizeof(tmp_msg)。 i++) // MAX_DB_NUM=127 這樣就保證了循環(huán)變量 i的值在正常范圍內，從而避免了對指針 pDBFat進行內存越界的操作。 14 break。 i++) 2 { 3 pDBFat = (_NM_DBFAT_STRUC *)(NVDB_BASE + DBFAT_OFFSET + i*DBFAT_LEN)。為什么其它群的話單正常，唯獨 11群不正常呢？ 11群是四個群中最小的群，其中繼計次表位于緩沖區(qū)的首位，打完電話后查詢內存發(fā)現(xiàn)出中繼群號在內存中是正確的，取完話單后再查就不正確了。 思考與啟示： 極限測試必須注意，測試前應對某項設計的極限做好充分測試規(guī)劃。 指針的使用是非常靈活的，同時也存在危險性，必須小心使用。指針的使用具有很強的技巧性和靈活性，但同時也帶來了很大的危險性。 ? 處罰辦法 問題發(fā)生率： P=D/S D=DA++ 其中： P －問題發(fā)生率 D － 1個季度內錯誤總數(shù) DA － 1個季度內 A類錯誤總數(shù) DB － 1個季度內 B類錯誤總數(shù) DC － 1個季度內 C類錯誤總數(shù) S － 1個季度內收到問題報告單總數(shù) 1）當 D≥ 3時，如果 P≥ 3％，將進行警告處理，并予以公告； 2）當 D≥ 5時，如果 P≥ 5％，將進行罰款處理，并予以公告。ul_card_config_num, amp。而在我們交換機的程序中大量使用指針，并且有增無減。對于中繼的業(yè)務，則要充分考慮各種信令： TUP、 ISUP、 PRA、NO V5等等。 【案例 】 【正 文】 在接入網(wǎng)產(chǎn)品 A測試中，在內存數(shù)據(jù)庫正常的情況下的各種數(shù)據(jù)庫方面的操作都是正常的。 8 continue。而 pDBFat是數(shù)據(jù)庫的起始地址，如果 pSysHeaddbf_count值異常過大，將導致pDBFat值超過最大內存地址值，隨后進行的內存操作將 導致內存操作越界錯誤，因而在測試過程中數(shù)據(jù)庫破壞后就出現(xiàn)了主機死機的現(xiàn)象。這個問題給我們教訓的是：在直接對內存地址進行操作時，一定要保證其值的合法性，否則容易引起內存操作越界，給系統(tǒng)的穩(wěn)定性帶來潛在的威脅。 CellNum=。于是將板上所有端口配置為普通 2B+D端口，重新加載在主機數(shù)據(jù)，現(xiàn)象消失。 但由于得到 index 后，沒有任何判斷，導致若 MNT/MLT端口沒有做半永久，端口激活后，執(zhí)行此部分函數(shù)， (PortTable+index)spcNo 有可能為 NULL_WORD，于是，運算后， pSpcCB 可能為非法值。因為問題很隱蔽，直接分析海一樣的代碼是很難發(fā)現(xiàn)的。 1 char szLine[80]。 DWORD SaveFrNetIntIWFData ( DWORD *pdwWritePoint ) { BYTE bSlotID, bPeerSlotID。 ．．． [wCount].bSlotID = bSlotID。 WORD wOldAtmPort, wAtmDlci, wHdlcPort, wHdlcDlci。 WORD wHdlcPort, wOldAtmPort, wCIR。 【案例 】 【正 文】 在 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。amp。 w_head = (LinkState[logic_link]. + W_MOD retran_num) % W_MOD 。 【結 論】：由于鏈路通信對系統(tǒng)效率要求很高，算法采用效率最高的，但位與（ amp。300和 0amp。消息處理不合理。 函數(shù)形參和實參不一致，實際上和第一種情況本質上是一樣的，只是表現(xiàn)的形式不太一樣，這種情況也是代碼中經(jīng)常出現(xiàn)的問題 ,下面例子是測試中曾經(jīng)發(fā)現(xiàn)的一個小問題： 【例二】在 file01中的 INT DebugMsgProc(char byMsg0, char byMsg1)函數(shù)，兩個形參都是 char型，而實際傳入的參數(shù)都是 BYTE型，結果函數(shù)中的如下語句： PrintfE(PID_RED, %d ticks time out!,byMsg1)。idwLen/2。 用于控制條件轉移的表達式及取值范圍是否書寫正確 【案例 】 【案例描述】： 在測試主機 MPU板倒換功能時，如果 MPU備份充分，倒換前后對處于激活狀態(tài)的電路應無影響，即不影響通話。但是當時間的跨度較大時，詳細話單數(shù)量較多，問題就出現(xiàn)了。 重復上述步驟，當終端與 BAM的連接尚未關閉時主動 斷開此次連接，結果同上。 修改 ProcessQueryBill()函數(shù) //只輸出滿足條件的前 200張話單 if (++wBillCount == 200) { timeCur = timeEnd + tsOneDay。 ( ( ( bsn g_wASL32StartPSN ) % 32 ) == 15 || ( ( bsn g_wASL32StartPSN ) % 32 == 16 ) ) ) r