【導(dǎo)讀】用，將導(dǎo)致模塊間配合失效等嚴重問題；2）當(dāng)D≥5時，如果P≥5％，將進行罰款處理，并予以公告。C語言中最大的特色就是指針。但同時也帶來了很大的危險性。在蘭色部分使用該指針。但在Get_Config_Table函數(shù)中有可能失敗返回而不給。因此，以后使用的可能是一個非法指針。危險性舉世共知。在新的編程思想中，指針基本上被禁止使用（JAVA中就是。這樣），至少也是被限制使用。至18位，不會有問題。查錯過程很簡單，按呼叫處理的過程檢查代碼，發(fā)現(xiàn)某一處的判斷有誤，本應(yīng)為小于18的判斷，寫成了小于等于18。對于中繼的業(yè)務(wù)，則要充分考慮各種信令：TUP、ISUP、PRA、其中11,13群向為出中。繼,12,14群向為入中繼，對這四個群分別進行計費設(shè)置，對出入中繼都計費。常，有時其出中繼群號就為一個隨機值，發(fā)生異常的頻率比較高。11群是四個群中最小的群，其中繼計次表位于。問題，在編程時是應(yīng)該注意的地方。

　　

【正文】 述的原因 , 會聽到新業(yè)務(wù)失敗音 , 此次失敗后 , 無論 MCT_HANDLE分配成功與否 , 該用戶的 MCT標志都被置為 1, 所以在用戶掛機時 , 會將該模塊唯一的 MCT_HANDLE資源釋放掉 . 則以后該功能又可以正常實現(xiàn)。 在追查這個問題時，開發(fā)人員 A又發(fā)現(xiàn)了一個可能導(dǎo)致死機的嚴重問題：在用戶啟動 MCT服務(wù) , 正在聽報追查號碼的 MCT音時 , 若惡意用戶此時掛機 , CCB的處理中 , 只針對 ST用戶送 DISCONNECT, 而對 V5ST用戶送的是RELEASE消息 , 這導(dǎo)致 V5X收到此消息后 , 將該 V5ST用戶的 cr2清除掉 , V5_USER_TALBE[ ]. cr2變?yōu)?0xFFFF, 這樣在 V5_CR_VOICETONE超時后 , 程序中會檢查 cr2的 狀態(tài)是否為 HOLD, 當(dāng)取 cr2的內(nèi)容時 , 由于 cr2已被清除 , 會發(fā)生指針越界的 GP錯誤。 【結(jié) 論】 通過調(diào)測發(fā)現(xiàn)、定位并解決問題。 【思考與啟示】 我們平常一些熟視無睹的業(yè)務(wù)或按正常流程操作沒有問題的業(yè)務(wù)，不能保證它就一定沒有問題，要善于抓住一絲一毫的異常現(xiàn)象。對于很難重現(xiàn)的問題千萬不要輕易放過，我們網(wǎng)上設(shè)備所出的問題很多都是一些在實驗室難以出現(xiàn)或很難重現(xiàn)的一些問題，一些顯而易見的問題一般都可消滅在實驗室，難就難在消滅一些隱藏很深的問題。說老實話，我們的產(chǎn)品還有 許多問題 ，需要我們扎扎實實鍥而不舍的工作。 分配資源是否已正確釋放 【案例 】 【正 文】 在對接入網(wǎng) A產(chǎn)品的網(wǎng)管軟件測試中，發(fā)現(xiàn)了一個 WINDSOWS資源損耗的的問題：當(dāng)網(wǎng)管軟件運行幾天后， WINDOWS總會出現(xiàn)“資源不夠”的告警提示。如果網(wǎng)管軟件不關(guān)掉再重新啟動的話，就會出現(xiàn) WINDOWS資源完全耗盡的現(xiàn)象，最終網(wǎng)管系統(tǒng)反應(yīng)很慢，無法正常工作。 從現(xiàn)象上可以判斷出，網(wǎng)管軟件存在隱蔽的內(nèi)存泄露或資源不釋放的問題，并且這種資源耗盡是一個緩慢的過 程。如何定位這個問題呢？ 定位這種問題可以利用 WINDOWS中的一個系統(tǒng)資源監(jiān)視工具。打開Windows的“附件 /系統(tǒng)工具 /資源狀況”，這是一個系統(tǒng)資源、用戶資源、和 GDI資源的實時監(jiān)視工具。 工具有了，那么如何發(fā)現(xiàn)導(dǎo)致不斷消耗資源的特定操作呢？ 首先和開發(fā)人員共同探討，列出幾個最可能消耗資源的操作和一些操作組合，這樣就縮小了監(jiān)視范圍，避免沒有范圍的碰運氣，否則如大海撈針。 監(jiān)視前，首先重新啟動 WINDOWS，最好不運行其他的程序，打開“系統(tǒng)狀況”這個監(jiān)視工具，然后運行網(wǎng)管軟件，記 下此時的資源狀況數(shù)據(jù)。 然后針對一個可疑的操作，快速大量地重復(fù)進行。這種重復(fù)性的操作可以利用 QArun測試工具執(zhí)行， QArun可以記錄操作者的一次操作步驟，然后按照設(shè)定的次數(shù)重復(fù)操作。操作后，觀察此時的資源狀況，并記下此時的數(shù)據(jù)，與操作前的數(shù)據(jù)比較，如果操作前后的數(shù)據(jù)數(shù)據(jù)沒有變化或變化很小，可排除此項操作，否則就可斷定此項操作會引起資源耗盡。 對其它可疑的操作和操作組合重復(fù)以上過程。 通過以上的步驟，終于找出引起資源耗盡的罪魁禍首。分析相應(yīng)部分的代碼，發(fā)現(xiàn)引起資源耗盡原因有：內(nèi)存泄露，畫筆和畫刷資源用 完后未釋放等。 【案例 】 【正 文】 某產(chǎn)品后臺軟件版本，是用 C++寫的，程序員在寫代碼時，經(jīng)常在構(gòu)造函數(shù)中申請一塊內(nèi)存，而不釋放，在程序其他代碼中也經(jīng)常只管申請，不管釋放。 例如 : void WarnSvr::SaveWarnData() { ...... for(int m=0。mRecordsInBuffer[EVENT_ALARM]。m++) { HISTORY_FILTER_INDEX* item= new HISTORY_FILTER_INDEX。 itemCsn=Buffer[EVENT_ALARM][m].Csn。 itemPosition=m +(RecordsInHistoryFileRecordsInBuffer[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=()。 BOOL find_flag=false。 for(int k=0。kitem_total。k++) if(EventFilterIndex[k]Csn==itemCsn) { find_flag=true。 break。 } if(find_flag) { (item)。 if(()) ClearIndexEntry()。 } //建議在此處加上 : // else // delete item。 }。 有的程序員認為，后臺運行的環(huán)境有大量內(nèi)存，幾個字節(jié)的浪費不會造成死機等重大事故。然而，長時間累計起來，必然會造成資源緊張而出現(xiàn)故障。 實際上，這種思想是造成我們產(chǎn)品不穩(wěn)定的原因之一。我們的主機在網(wǎng)上能運行幾個月幾年，大家對內(nèi)存的分配釋放較敏感，而我們的后臺產(chǎn)品往往只能正常運行幾天。這個地方不注意也是原因之一吧。 【案例 】 【正 文】 在進行代碼審查過程中，造成內(nèi)存泄漏的代碼比較多。下面舉幾種常見的內(nèi)存泄漏錯誤，供測試人員在代 碼審查中參考： 1. 函數(shù)有多個出口時，沒有在每個出口處對動態(tài)申請的內(nèi)存進行釋放。一般在異常處理時容易出現(xiàn)這種錯誤。下面的代碼段就是這樣的例子： ..... pRecord = new char[pTableGetRecordLength()]。 assert(pRecord != NULL)。 if (pTableGoTop(FALSE) != DBIERR_NONE) return。 // 如果從這里返回， pRecord將得不到釋放 ..... pTableClose()。 delete[] pRecord。 } 2. 給指針賦值時，沒有檢查指針是否為空，如果指針不為空，那么指針原來指向的內(nèi)存將丟失。請看如下代碼段： .... struct FileInfo * pdbffile = new struct FileInfo。 pdbffilepfileinfo = new struct ffblk。 pdbffilesrame = srcRootPath。 pdbffiledesname = desRootPath。 pdbffileprev = NULL。 pfile = pdbffile。 //賦值之前沒有檢查一下 pfile是否為空，如果不為空，會造成 pfile指向的內(nèi)存丟失。 dbf_start_needed = FALSE。 dbf_Finish = FALSE。 flag_begined = TRUE。 if(FALSE == Copy(TRUE)) { dbf_start_needed = TRUE。 WarnMsgOut(Error occurs while copying files in directory dbf,trying again.)。 } } 3. 連續(xù)二次內(nèi)存動態(tài)分配，在第二次分配失敗時，忘記釋放第一次已經(jīng)申請到的內(nèi)存。 .... pMsgDB_DEV = (PDBDevMsg)GetBuff( sizeof( DBDevMsg ), __LINE__)。 if( pMsgDB_DEV == NULL ) return。 pMsgDBApp_To_Logic = (LPDBSelfMsg)GetBuff( sizeof(DBSelfMsg), __LINE__ )。 if( pMsgDBApp_To_Logic == NULL ) return。//此處返回造成 pMsgDB_DEV指向的內(nèi)存丟失 .... ，導(dǎo)致程序未執(zhí)行任何操作而退出時，也可能沒有釋放應(yīng)釋放的內(nèi)存，這種情況一般是缺少應(yīng)有的 else分支，或 switch語句的 default分支沒有應(yīng)有的處理。 static void OncePowerCmdHandle( struct HT_Appmsg * msg ) { ... ... pPower_test_answer =(struct _oncepower_test_answer *)GetBuff(sizeof(struct _oncepower_test_answer),__LINE__)。 if( pPower_test_answer == NULL_PTR ) 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)存泄漏的情況很多，以上是幾種典型的情況。 雖然內(nèi)存泄露一般出現(xiàn)在異常情況下，畢竟給系統(tǒng)造成很大的隱患，使系統(tǒng)的健壯性降低。測試人員在作代碼審查時，對上述幾種情況要尤其注意。 【案例 】 【正 文】在進行 SAR的 PDU包發(fā)收的測試過程中要同時考慮幾個邊界值 ,即發(fā)送包大小范圍 [0Nmax],SAR的 PDU包接收的最大值 Kmax,MBUF塊的大小 ,將 SAR的 PDU包接收的最 大值設(shè)為 20xx(Kmax=20xxB), MBUF的塊長設(shè)為 512(M = 512B),則發(fā)送包大小的正確分支的取值為下限 0,上限Nmax=20xx,然后在 0與 20xx之間隨機取若干值 ,再考慮 MBUF的塊長 ,還可增加 M倍數(shù)的若干選值及其附近值 .以上是測試的一般思路 ,但由于很偶然的機會選擇包長 20xx,及 Kmax=20xxB,才發(fā)現(xiàn)問題 .原因如下 : MBUF塊長 512,但塊中實際存放數(shù)據(jù)的只有 500(MBUF頭上有 2個長字 ,尾部有 1個長字共 12B只用于塊控制 ),而發(fā)送的包長正好是 500的整數(shù)倍 4,由于是整數(shù) 倍 ,所以 SAR(BT8230)從 FREE鏈上摘成 5個 MBUF(原因從略 ),而 SAR驅(qū)動只知道有 4個MBUF,這樣到上層用戶時 ,只釋放 4個 MBUF,從而漏掉 1個 MBUF,經(jīng)過很短一段時間后 ,內(nèi)存即被耗盡 .(此問題非常嚴重 ,因為在實際運用中 ,是 500的整數(shù)倍的 PDU包的概率較小 ,但一旦出現(xiàn)就會發(fā)生一次內(nèi)存泄漏 ,這樣經(jīng)過若干天或若干月的運行后會使系統(tǒng)崩潰 ) 以前未發(fā)現(xiàn)此問題的原因是因為原來使用的緩沖塊長為 2048,減去 12B的控制信息 ,實際存放數(shù)據(jù)的長度為 2048這個值 ,忽略了 2036,所以 在選取上下限中的若干值時 ,選取包的長度是 2036的倍數(shù)的概率就非常小 ,因而未發(fā)現(xiàn)該問題 . 由于測試中一般很難將取值范圍中的所有值覆蓋全 ,所以在選取上下限中的若干取值時要格外仔細 ,考慮的方面盡可能全 ,因為很有可能其中某些值就是測試邊界值 .凡是涉及的數(shù)字盡量選取 ,象該例中正確分支的測試邊界為 0,20xx,512及其整數(shù)倍 ,500 及其整數(shù)倍 ,12 及其整數(shù)倍等值 ,它們是必測的邊界值 ,而非可測可不測的隨機選取的所謂若干選值 . 【案例 】 【正 文】 rel_ABIS_CCB_conn( )中，在進行消息鏈表 Msg_Queue[ces]的拆鏈操作時，對于相應(yīng)的 CCB只進行了一次拆鏈操作，即只拆除了一個節(jié)點，如果出現(xiàn)該 CCB對應(yīng)的消息節(jié)點不止一個的情況就會出現(xiàn)大量節(jié)點不能釋放的問題。 if( Msg_Queue[ces].msghead != NULL_PTR )//message buffer notempty { //get first message record pMsgRecord = Msg_Queue[ces].msghead