【文章內(nèi)容簡介】 值范圍為16~991，第四種取值范圍為2048~126975，第五種取值范圍為131072~4194303，所以當采用前三種DLCI類型時，采用WORD類型最大值為65535，已經(jīng)完全夠用了；而對于第四種類型時，其取值在超過65535時，獲取DLCI值的函數(shù)_GetFrDlci（）采用DWORD類型，而負責保存和恢復的兩個函數(shù)SaveFrNetExtIWFData（）和RestoreFrNetExtIWFData（），都把DLCI的值當作WORD類型進行處理，因此導致DLCI取值越界，于是程序把原本為長整型的DLCI強制轉(zhuǎn)換成整型，從而導致DLCI值在恢復時，比原數(shù)據(jù)小65536。而在程序運行過程中，這些數(shù)據(jù)保存在DRAM中，程序運行直接從DRAM中獲取數(shù)據(jù)，程序不會出錯；當FRI板復位或插拔后，需要從FLASH中讀取數(shù)據(jù)，此時恢復函數(shù)的錯誤就表現(xiàn)出來。 另一個問題是為什么23/4類型的DLCI數(shù)據(jù)不能恢復？這是由于對于23/4類型的PVC，其DLCI的取值范圍為：131072~4194303，而程序強制轉(zhuǎn)換并恢復的數(shù)據(jù)最大只能是65535，所以這條PVC不能恢復。 至此，DLCI數(shù)據(jù)恢復出錯的原因完全找到，解決的方法是將DLCI的類型改為DWORD類型。從這個案例可以看出，在程序開發(fā)中一個很低級的錯誤，將在實際工作中造成很嚴重的后果。正確使用邏輯與amp。amp。、屏蔽amp。操作符【】【案例描述】：由于C語言中位與比求模效率高，因而系統(tǒng)設(shè)計時，對于模128的地方都改為與127，系統(tǒng)定義的宏為define MOD128 127和define W_MOD 127(定義的宏的名字易引起誤解)，但實際程序中還是采取求模，從而引起發(fā)送窗口欲重發(fā)的和實際重發(fā)的不一致，最終導致鏈路復位此類嚴重問題，曾在定位此問題時花了不少時間。【處理過程】：處理過程如下：define MOD128 127 //隊列長128，當隊頭到128時，上其返回。define W_MOD 127 //發(fā)送窗口隊列，意義同上。在函數(shù)L2_TO_L1()中，有如下語句： linkstate_ptr = (head + 1) % W_MOD 。這里當head=126時， = 0，這將造成發(fā)送窗口指針和隊列窗口指針錯位，造成鏈路復位。另外，在重發(fā)函數(shù)void INVOKE_RETRANSMISSION(_US logic_link,_US n_r)中，有如下語句： retran_num = (LinkState[logic_link].Vs + MOD128 (_UC)n_r) % MOD128 。 w_head = (LinkState[logic_link]. + W_MOD retran_num) % W_MOD 。第一個語句求欲重發(fā)的消息包個數(shù)，第二個語句求重發(fā)的起始位置，當Vs小于n_r時，將造成實際重發(fā)數(shù)小于欲重發(fā)數(shù)，同時造成實際起始重發(fā)位置和欲重發(fā)起始位置錯開，從而引起鏈路復位。上面三個語句應(yīng)該做如下改動： linkstate_ptr = (head + 1) amp。 W_MOD 。 retran_num = (LinkState[logic_link].Vs + MOD128 + 1 (_UC)n_r) amp。 MOD128 。 w_head = (LinkState[logic_link]. + W_MOD + 1 retran_num) amp。 W_MOD ?！窘Y(jié) 論】：由于鏈路通信對系統(tǒng)效率要求很高，算法采用效率最高的，但位與（amp。）和求模（%）這小小的區(qū)別，造成的竟是鏈路復位這種嚴重的錯誤?！舅伎寂c啟示】：對這類問題，大家在閱讀代碼或代碼審查時一定要注意，仔細一點往往能發(fā)現(xiàn)問題，但在測試中來定位這種問題，花費的時間往往更長。注意數(shù)據(jù)類型的匹配【】【案例描述】 下面通過測試中的一個例子來說明這個問題：命令DSP N7C是用來顯示NO7電路狀態(tài)的，其參數(shù)設(shè)備類型DID支持TUP和ISUP，參數(shù)信道號BSN支持多值輸入（最多支持32路查詢），正常情況下該命令沒有問題。但試了非正常情況下，問題就出來了。 首先試BSN參數(shù)越界情況，即參數(shù)BSN超過32路查詢，選了幾個數(shù)據(jù)段，問題就出來了。對于0amp。amp。300和0amp。amp。256，該命令返回結(jié)果不一致，對前者認為參數(shù)越界，對后者返回執(zhí)行成功。 對于參數(shù)DID，選定一種設(shè)備類型（TUP或ISUP），讓參數(shù)BSN所包含的32路電路跨越TUP和ISUP，兩次結(jié)果是不一致的。【處理過程】 反饋到開發(fā)人員那里，第一個問題是BAM的問題，第二個問題是SM的問題?！窘Y(jié) 論】 為數(shù)據(jù)超出范圍溢出造成，int值賦值給BYTE，造成數(shù)據(jù)丟失。 問題的產(chǎn)生是因為查詢的第一個信道是TUP電路，但是卻按ISUP電路查詢。ISUP的維護處理函數(shù)判斷第一個信道不是ISUP信道，認為整個的PCM不是ISUP類型的PCM，返回全部的電路狀態(tài)為未安裝。消息處理不合理。TUP也會產(chǎn)生如此錯誤?！舅伎寂c啟示】 我們的MML命令并不是無懈可擊的，許多表面上的小問題，往往隱藏著代碼的缺陷和錯誤?！尽俊菊? 文】當我們使用PCLINT檢查代碼時，會發(fā)現(xiàn)大量的數(shù)據(jù)類型不匹配的告警，大部分情況下，這種代碼上存在的問題并不會引起程序功能實現(xiàn)上的錯誤，但有些情況下，也許會產(chǎn)生嚴重的問題： 一、不同數(shù)據(jù)類型變量之間賦值引起的問題，實際上，該類問題也可以分為幾種情況：直接賦值，比如，把一個WORD型變量賦給一個INT型變量，如果WORD型變量大于32767，INT型變量得到的就是一個負值了。 【例一】一次測試過程中發(fā)現(xiàn)，SDH送的告警在BAM調(diào)試窗口打印出紅色提示：File(XXX),Line(XXX):Invalid alarm id ,from: 7, AlarmId: 65463經(jīng)過檢查數(shù)據(jù)發(fā)現(xiàn)，并沒有ID為65463的告警，分析上報的數(shù)據(jù)幀，發(fā)現(xiàn)上報的告警ID為B7，原來代碼中有一處強制類型轉(zhuǎn)換： = (WORD)RecvBuffer[iTmpLen + 5]。char型強制轉(zhuǎn)換成WORD型。B7就變成了FFB7，十進制就是65463。由于char是有符號型，B7的第8位為1，所以轉(zhuǎn)換后為FFB7，而不是代碼作者希望的00B7，如果第8位是0，或該變量是BYTE型，轉(zhuǎn)換就不會有問題了。函數(shù)形參和實參不一致，實際上和第一種情況本質(zhì)上是一樣的，只是表現(xiàn)的形式不太一樣，這種情況也是代碼中經(jīng)常出現(xiàn)的問題,下面例子是測試中曾經(jīng)發(fā)現(xiàn)的一個小問題：【例二】在file01中的INT DebugMsgProc(char byMsg0, char byMsg1)函數(shù)，兩個形參都是char型，而實際傳入的參數(shù)都是BYTE型，結(jié)果函數(shù)中的如下語句：PrintfE(PID_RED, %d ticks time out!,byMsg1)。在byMsg1大于127時，輸出錯誤的結(jié)果。 二、不同數(shù)據(jù)類型之間的比較操作在循環(huán)終止條件的判斷中，不同類型變量的比較操作是容易造成死循環(huán)錯誤的地方，同時也是開發(fā)人員容易忽視的地方，值得測試人員多加留意。下面兩個例子是該類錯誤的兩種典型情況：【例三】file02文件中某函數(shù)中如下代碼，可能造成死循環(huán)： ...... int i。 WORD *pCheck =(WORD*)p。 WORD wCheckSum=*pCheck。 pCheck++。 for(i=1。idwLen/2。i++) { wCheckSum^=(*pCheck)。 pCheck++。 } //binlen had already word alignment return (wCheckSum)。 ...... 該段代碼是在DOS環(huán)境下用BC編譯的，由于循環(huán)變量i是int型（2個字節(jié)），而dwLen是DWORD型（4個字節(jié)），如果dwLen大于65536，那么該函數(shù)就是死循環(huán)了。上面的例子是不同類型變量之間直接比較操作，還有一種情況是函數(shù)的返回值與另一不同類型的變量比較，見下面例子：【例四】， while( ftell(fp) Part[3]) {..... } ftell返回long型，而Part是DWORD型，有符號變量和無符號變量的比較，可能造成死循環(huán)。類似的例子還有很多，類型不匹配的問題還有許多種情況，都是代碼中的隱患，有時會造成嚴重的后果，需要引起足夠的重視。對于該類問題，我們可以利用PCLINT工具對代碼進行細致的檢查。用于控制條件轉(zhuǎn)移的表達式及取值范圍是否書寫正確【】【案例描述】： 在測試主機MPU板倒換功能時，如果MPU備份充分，倒換前后對處于激活狀態(tài)的電路應(yīng)無影響，即不影響通話。但近期測試發(fā)現(xiàn)，如果兩局通過DT板進行一號對接，MPU備份倒換卻發(fā)生斷話。具體現(xiàn)象為：如果DT板的第1個PCM系統(tǒng)電路為故障，則MPU倒換時復位該DT板，如果DT板的第2個PCM系統(tǒng)電路為故障，則MPU倒換時復位下一塊DT。【處理過程】： 據(jù)查，MPU倒換時會自動復位處于“故障”態(tài)的電路，但由于計算錯誤（多加了32），錯復位了下一個PCM系統(tǒng)32路電路?！窘Y(jié) 論】： 如此嚴重問題為什么到今天才發(fā)現(xiàn)？因為我們在實驗室中一般采用同一單板的2個PCM系統(tǒng)自環(huán)進行測試，則不會在某單板上有故障和空閑電路共存，自環(huán)屏蔽了錯誤。【思考與啟示】： 自環(huán)是在測試環(huán)境下常用的一種提高效率的手段，但一旦條件允許，我們的測試工作應(yīng)盡量模擬網(wǎng)上的實際環(huán)境進行。【】 平時對計費功能進行測試的時候，瀏覽詳細話單都是比較注意話單本身的正確性，并沒有注意該命令對系統(tǒng)的影響。所以當瀏覽少量話單的時候，并沒有發(fā)現(xiàn)該命令的異常。但是當時間的跨度較大時，詳細話單數(shù)量較多，問題就出現(xiàn)了。執(zhí)行如下命令： LST AMA: TP=NRM, SD=1999amp。7amp。1, SA=YES。 當瀏覽了大約10萬張詳細話單后，終端與BAM的連接關(guān)閉。重建連接后，發(fā)現(xiàn)話單臺的命令不能執(zhí)行。觀察BAM的性能，發(fā)現(xiàn)話單臺仍占有CPU50%以上的利用率，說明原來的任務(wù)仍在執(zhí)行。需要關(guān)一下話單臺才能恢復正常。 重復上述步驟，當終端與BAM的連接尚未關(guān)閉時主動斷開此次連接，結(jié)果同上。 反饋到開發(fā)人員那里，發(fā)現(xiàn)該現(xiàn)象與設(shè)計的初衷是相違背的。本來話單臺控制最多輸出200張話單，這是為了防止過多話單的輸出顯示會增加BAM的開銷，從而降低BAM的性能。查看一下源代碼，問題就發(fā)現(xiàn)了。 話單臺控制最多輸出200張話單程序如下 while(timeCur = timeEnd) { timeCur += tsOneDay。//加一天 while((amp。rpt, sizeof(CBillReport)) == sizeof(CBillReport)) { ..................... //只輸出滿足條件的前200張話單 if (++wBillCount == 200) { break。 } }//一個文件查詢結(jié)束 }//所有文件查詢結(jié)束 在話單輸出200張之后，程序只退出一層循環(huán)，仍然會從下一天話單繼續(xù)輸出，導致向MML發(fā)幀過多，造成MML和話單臺都被堵死。 修改ProcessQueryBill()函數(shù) //只輸出滿足條件的前200張話單 if (++wBillCount == 200) { timeCur = timeEnd + tsOneDay。//退出第二層循環(huán), while(timeCur = timeEnd) break。 } 作上述修改后問題就不再出現(xiàn)了。 一些MML命令從完成的功能來講可能是沒什么問題的，但其執(zhí)行對系統(tǒng)性能的影響我們在測試時時往往給忽視了。在我們目前的BAM方案中，存在著多個終端協(xié)同工作，如果某個終端發(fā)出的命令在BAM中長時間獨占著大部分系統(tǒng)資源，造成的后果是嚴重的。這是在設(shè)計時要避免的，在測試中要注意的問題。【】【正 文】 在判斷模擬用戶端口是否反極性時有這樣一段程序： if ( ( bsn = g_wASL32StartPSN ) amp。amp。 ( ( ( bsn g_wASL32StartPSN ) % 32 ) == 15 || ( ( bsn g_wASL32StartPSN ) % 32 == 16 ) ) ) return TRUE。 if ( ( bsn % 16 ) == 7 || ( bsn % 16 ) == 8 ) return TRUE。 return FALSE。 作者的本意是如果是32路用戶板（藍色字體判斷），就看端口號是否是第15和16路，如果是，就是反極性端口，返回TRUE，否則就不是，應(yīng)該返回FALSE。但代碼表達的意思是：如果是32路用戶板并且端口號是15或16就返回真值，否則還要執(zhí)行下邊語句。 當端口在32路用戶板上，但端口號不是15或16時，不同的32路端口的起始地址g_wASL32StartPSN，會導致不同的非