【正文】 nt, wTotalNetIWF。 DWORD dwCCID, dwResult, dwAtmPort。 DWORD dwResult。 ．．． } 其中涉及 DLCI值的變量都為 WORD（即無符號短整型）類型，在程序的處理時，出現(xiàn) WORD和 DWORD（無符號長整型）類型在一句中同時存在的情況，至此可以判斷問題出在這里。 至此， DLCI數(shù)據(jù)恢復出錯的原因完全找到，解決的方 法是將 DLCI的類型改為 DWORD類型。、屏蔽 amp。 在函數(shù) L2_TO_L1()中，有如下語句： linkstate_ptr = (head + 1) % W_MOD 。 第一個語句求欲重發(fā) 的消息包個數(shù)，第二個語句求重發(fā)的起始位置，當 Vs小于n_r時，將造成實際重發(fā)數(shù)小于欲重發(fā)數(shù)，同時造成實際起始重發(fā)位置和欲重發(fā)起始位置錯開，從而引起鏈路復位。 MOD128 。）和求模（ %）這小小的區(qū)別，造成的竟是鏈路復位這種嚴重的錯誤。 首先試 BSN參數(shù)越界情況，即參數(shù) BSN超過 32路查詢，選了幾個數(shù)據(jù)段，問題就出來了。amp。 【結 論】 為數(shù)據(jù)超出范圍溢出造成， int值賦值給 BYTE，造成數(shù)據(jù)丟失。 TUP也會產(chǎn)生如此錯誤。 char型強制轉換成 WORD型。 在 byMsg1大于 127時，輸出錯誤的結果。 WORD wCheckSum=*pCheck。i++) { wCheckSum^=(*pCheck)。 上面的例子是不同類型變量之間直接比較操作，還有一種情況是函數(shù)的返回值與另一不同類型的變量比較，見下面例子： 【例四】 ， while( ftell(fp) Part[3]) {..... } ftell返回 long型，而 Part是 DWORD型，有符號變量和無符號變量的比較，可能造成死循環(huán)。但近期測試發(fā)現(xiàn)，如果兩局通過 DT板進行一號對接， MPU備份倒換卻發(fā)生斷話。 【思考與啟示】： 自環(huán)是在測試環(huán)境下常用的一種提高效率的手段，但一旦條件允許，我們的測試工作應盡量模擬網(wǎng)上的實際環(huán)境進行。執(zhí)行如下命令： LST AMA: TP=NRM, SD=1999amp。重建連接后，發(fā)現(xiàn)話單臺的命令不能執(zhí)行。 反饋到開發(fā)人員那里，發(fā)現(xiàn)該現(xiàn)象與設計的初衷是相違背的。//加一天 while((amp。//退出第二層循環(huán) , while(timeCur = timeEnd) break。這是在設計時要避免的，在測試中要注意的問題。 if ( ( bsn % 16 ) == 7 || ( bsn % 16 ) == 8 ) return TRUE。 當端口在 32路用戶板上，但端口號不是 15或 16時，不同的 32路端口的起始地址 g_wASL32StartPSN，會導致不同的非 1 16端口被誤認為是反極性端口。 return FALSE。 【處理過程】 該錯誤比較隱蔽，現(xiàn)在說明如下： Max2B1QStatTime 最大統(tǒng)計時間 Max2B1QStatPortNum最大統(tǒng) 計端口數(shù) MAX_2B1Q_STAT_PSN 最大統(tǒng)計內(nèi)存分配數(shù)量 其中： Max2B1QStatTime（最大統(tǒng)計時間）和 Max2B1QStatPortNum （最大統(tǒng)計 端口數(shù)）的乘積不能大于 MAX_2B1Q_STAT_PSN 程序如下： //查詢數(shù)據(jù)庫，獲得 Max2B1QStatTime的值 = 10。 //查詢數(shù)據(jù)庫成功 if( error_code == DB_SUCCESS ) { // Max2B1QStatTime配置的值 if ( MAX_2B1Q_STAT_PSN ) Max2B1QStatTime = MAX_2B1Q_STAT_PSN。directQueryCond, (BYTE FAR *)amp。 } 此處 ifelse if 分支沒有判斷 值為 0的情況，即數(shù)據(jù) 庫為Max2B1QStatPortNum配置的值為 0： == 0，則Max2B1QStatPortNum就為缺省值 32。好多問題就是因為條件判斷不完全造成的。 呼叫幾萬次后停止呼叫，取話單進行觀察。開發(fā)人員認為是 CCB的問題，后來一查果然如此。 【案例 】 【案例描述】 在進行 128模塊 V5用戶 CENTREX新業(yè)務測試時，偶然遇到一個怪現(xiàn)象：對群內(nèi)一個 V5ST用戶只開放 MCT權限，在進行惡意呼叫追查時，有一次報惡意呼叫追查成功音只報了一半，當正要報出惡意呼叫的號碼時，業(yè)務中斷重新回到通話態(tài)，隨即重新追查一次，報“已申請其它新業(yè)務，本次申請不成功”。 【處理過程】 出現(xiàn)這個問題后，及時與開發(fā)人員 A取得了聯(lián)系，并一起試圖重現(xiàn)這個問題，通過許多次的反復操作，又出現(xiàn)了一次這種情況。 在追查這個問題時，開發(fā)人員 A又發(fā)現(xiàn)了一個可能導致死機的嚴重問題：在用戶啟動 MCT服務 , 正在聽報追查號碼的 MCT音時 , 若惡意用戶此時掛機 , CCB的處理中 , 只針對 ST用戶送 DISCONNECT, 而對 V5ST用戶送的是RELEASE消息 , 這導致 V5X收到此消息后 , 將該 V5ST用戶的 cr2清除掉 , V5_USER_TALBE[ ]. cr2變?yōu)?0xFFFF, 這樣在 V5_CR_VOICETONE超時后 , 程序中會檢查 cr2的 狀態(tài)是否為 HOLD, 當取 cr2的內(nèi)容時 , 由于 cr2已被清除 , 會發(fā)生指針越界的 GP錯誤。說老實話，我們的產(chǎn)品還有 許多問題 ，需要我們扎扎實實鍥而不舍的工作。如何定位這個問題呢？ 定位這種問題可以利用 WINDOWS中的一個系統(tǒng)資源監(jiān)視工具。 然后針對一個可疑的操作，快速大量地重復進行。 通過以上的步驟，終于找出引起資源耗盡的罪魁禍首。mRecordsInBuffer[EVENT_ALARM]。 //If a warn with a certain Csn is not in EventFilterIndex //it is not necessary to be added to HistoryFilterIndex int item_total=()。k++) if(EventFilterIndex[k]Csn==itemCsn) { find_flag=true。 } //建議在此處加上 : // else // delete item。 實際上，這種思想是造成我們產(chǎn)品不穩(wěn)定的原因之一。下面舉幾種常見的內(nèi)存泄漏錯誤，供測試人員在代 碼審查中參考： 1. 函數(shù)有多個出口時，沒有在每個出口處對動態(tài)申請的內(nèi)存進行釋放。 if (pTableGoTop(FALSE) != DBIERR_NONE) return。請看如下代碼段： .... struct FileInfo * pdbffile = new struct FileInfo。 pdbffileprev = NULL。 dbf_Finish = FALSE。 } } 3. 連續(xù)二次內(nèi)存動態(tài)分配，在第二次分配失敗時，忘記釋放第一次已經(jīng)申請到的內(nèi)存。 if( pMsgDBApp_To_Logic == 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 得不到釋放 } 造成內(nèi)存泄漏的情況很多，以上是幾種典型的情況。 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( pMsgDB_DEV == NULL ) return。 if(FALSE == Copy(TRUE)) { dbf_start_needed = TRUE。 //賦值之前沒有檢查一下 pfile是否為空，如果不為空，會造成 pfile指向的內(nèi)存丟失。 pdbffilesrame = srcRootPath。 delete[] pRecord。下面的代碼段就是這樣的例子： ..... pRecord = new char[pTableGetRecordLength()]。這個地方不注意也是原因之一吧。 有的程序員認為，后臺運行的環(huán)境有大量內(nèi)存，幾個字節(jié)的浪費不會造成死機等重大事故。 } if(find_flag) { (item)。 for(int k=0。 itemCsn=Buffer[EVENT_ALARM][m].Csn。 【案例 】 【正 文】 某產(chǎn)品后臺軟件版本，是用 C++寫的，程序員在寫代碼時，經(jīng)常在構造函數(shù)中申請一塊內(nèi)存，而不釋放，在程序其他代碼中也經(jīng)常只管申請，不管釋放。操作后，觀察此時的資源狀況，并記下此時的數(shù)據(jù)，與操作前的數(shù)據(jù)比較，如果操作前后的數(shù)據(jù)數(shù)據(jù)沒有變化或變化很小，可排除此項操作，否則就可斷定此項操作會引起資源耗盡。 工具有了，那么如何發(fā)現(xiàn)導致不斷消耗資源的特定操作呢？ 首先和開發(fā)人員共同探討，列出幾個最可能消耗資源的操作和一些操作組合，這樣就縮小了監(jiān)視范圍，避免沒有范圍的碰運氣，否則如大海撈針。如果網(wǎng)管軟件不關掉再重新啟動的話，就會出現(xiàn) WINDOWS資源完全耗盡的現(xiàn)象，最終網(wǎng)管系統(tǒng)反應很慢，無法正常工作。 【思考與啟示】 我們平常一些熟視無睹的業(yè)務或按正常流程操作沒有問題的業(yè)務，不能保證它就一定沒有問題，要善于抓住一絲一毫的異?，F(xiàn)象。 除了取消此次 MCT服務 , 將用戶切換回與惡意呼叫者的通話外 , 如果不釋放 MCT_HANDLE, 由于每個模塊只有一個這樣的資源 , 則下一次使用MCT業(yè)務的用戶不能成功 , 因為會在申請 MCT_HANDLE時失敗 , V5模塊和 ST模塊在這個地方處理都有問題 , 沒有將 MCT_HANDLE釋放掉 , 對于 V5用戶會聽新業(yè)務失敗音 , 對于 ST用戶會聽音樂。為了重現(xiàn)，再次掛機，重新呼叫，應用此新業(yè)務，但這個現(xiàn)象一直沒有出現(xiàn)。 更正 reset_CCB_for_reseatch_called_location()中清除被叫信息的代碼，重選中繼時不清除被叫用戶這部分屬性。 通知開發(fā)人員后，首先我們再次對計費數(shù)據(jù)進行了確認。 30路話路通過 TUP自環(huán)呼叫另外 30路話路，計費數(shù)據(jù)的設定是這樣的：通過計費情況索引對主叫計費，得到詳細話單。 造成這種錯誤的原因是判斷語句對條件判斷不完整。 //查詢數(shù)據(jù)庫成功 if( error_code == DB_SUCCESS ) { // Max2B1QStatPortNum配置的值，如果其缺省值和 Max2B1QStatTime乘積值大于 MAX_2B1Q_STAT_PSN的話： if ( ( * Max2B1QStatTime) MAX_2B1Q_STAT_PSN ) Max2B1QStatPortNum = MAX_2B1Q_STAT_PSN / Max2B1QStatTime。 } //