【正文】 QStatPortNum就為缺省值 32。 【結 論】 由于內(nèi)存限制， Max2B1QStatTime（最大統(tǒng)計時間）和Max2B1QStatPortNum（最大統(tǒng)計端口數(shù)）的乘積不能大于MAX_2B1Q_STAT_PSN， 如果從數(shù)據(jù)庫中得到 Max2B1QStatTime為 MAX_2B1Q_STAT_PSN，而數(shù)據(jù)庫中最大統(tǒng)計端口數(shù)恰好為 0，由于上述代碼沒有對 == 0的情況進行判斷， Max2B1QStatPortNum為缺省值 32，這樣 Max2B1QStatTime和Max2B1QStatPortNum乘積已經(jīng)是 32倍 MAX_2B1Q_STAT_PSN了，遠遠超過了設計內(nèi)存的限制。 造成這種錯誤的原因是判斷語句對條件判斷不完整。 【思考與啟示】 在代碼審查時，應該十分注意條件判斷的的完備性。好多問題就是因為條件判斷不完全造成的。 引用已釋放的資源 【案例 】 【正 文】 在計費測試的過程中，用呼叫器進行大話務量呼叫測試。 30路話路通過 TUP自環(huán)呼叫另外 30路話路，計費數(shù)據(jù)的設定是這樣的：通過計費情況索引對主叫計費，得到詳細話單。首先保證計費數(shù)據(jù)設定的正確性，打了幾次自環(huán)電話后，查看話單正常，則開始呼叫。 呼叫幾萬次后停止呼叫，取話單進行觀察。發(fā)現(xiàn)這 30路每次呼叫總會出現(xiàn)一張告警話單，其余話單正常，該告警話單相對于話路來說是隨機出現(xiàn)的。 通知開發(fā)人員后，首先我們再次對計費數(shù)據(jù)進行了確認。某個用戶在某次呼叫產(chǎn)生了告警話單，其上一次和下一次呼叫的計費情況都正常， 兩次呼叫之間的時間間隔只有幾秒鐘，排除了人為修改數(shù)據(jù)的可能。開發(fā)人員認為是 CCB的問題，后來一查果然如此。 當中繼選線發(fā)生了同搶需要重新選線時， CCB的reset_CCB_for_reseatch_called_location()就會把有關的呼叫信息清掉，造成計費情況分析失敗，產(chǎn)生計費費用為 0的告警話單。 更正 reset_CCB_for_reseatch_called_location()中清除被叫信息的代碼，重選中繼時不清除被叫用戶這部分屬性。 思考與啟示： 在計費測試過程中，對話單的觀察很 重要，不應該放過任何一個細小的疑點； 計費測試僅僅打幾次電話往往達不到效果，越接近用戶實際使用的情況越可能發(fā)現(xiàn)問題。 【案例 】 【案例描述】 在進行 128模塊 V5用戶 CENTREX新業(yè)務測試時，偶然遇到一個怪現(xiàn)象：對群內(nèi)一個 V5ST用戶只開放 MCT權限，在進行惡意呼叫追查時，有一次報惡意呼叫追查成功音只報了一半，當正要報出惡意呼叫的號碼時，業(yè)務中斷重新回到通話態(tài)，隨即重新追查一次，報“已申請其它新業(yè)務，本次申請不成功”。惡意呼叫追查與任何新業(yè)務都不會沖突，而且此用戶也只有惡 意呼叫追查有權，可以 肯定此時程序出問題了。為了重現(xiàn)，再次掛機，重新呼叫，應用此新業(yè)務，但這個現(xiàn)象一直沒有出現(xiàn)。大約反復操作 20遍，又出現(xiàn)了一次這樣的情況，顯然程序中可能存在某種問題。 【處理過程】 出現(xiàn)這個問題后，及時與開發(fā)人員 A取得了聯(lián)系，并一起試圖重現(xiàn)這個問題，通過許多次的反復操作，又出現(xiàn)了一次這種情況。確認問題后， A表現(xiàn)出高度的責任心，馬上駕調(diào)試環(huán)境，反復調(diào)測，終于在當天就逮住了狐貍尾巴： 當用戶接聽惡意呼叫者的電話 , 并啟動惡意呼叫追查業(yè)務后 , 在V5_CR_VOICETONE狀態(tài)下 , 只要聽 MCT音的用戶用脈沖方式撥任意一個數(shù)字 , 則立即停止送 MCT音 , 而將用戶切換回與惡意呼叫者的通話 . 但是程序中沒有對撥號類型作判斷 , 導致用戶若用音頻撥號也會作同樣的處理。 除了取消此次 MCT服務 , 將用戶切換回與惡意呼叫者的通話外 , 如果不釋放 MCT_HANDLE, 由于每個模塊只有一個這樣的資源 , 則下一次使用MCT業(yè)務的用戶不能成功 , 因為會在申請 MCT_HANDLE時失敗 , V5模塊和 ST模塊在這個地方處理都有問題 , 沒有將 MCT_HANDLE釋放掉 , 對于 V5用戶會聽新業(yè)務失敗音 , 對于 ST用戶會聽音樂。 當不停的撥測 V5用戶的 MCT業(yè)務時 , 有時在聽音時 , 可能由于網(wǎng)板有雜音等原因 (或用戶碰了話機的按鍵 ), 導致 DTR收到一位號 , 則會立即停止此次 MCT服務 , 用戶會聽到 MCT送音突然中斷 , 然后恢復了與惡意呼叫者的通話 . 而下次再用 MCT時 , 由于上面所述的原因 , 會聽到新業(yè)務失敗音 , 此次失敗后 , 無論 MCT_HANDLE分配成功與否 , 該用戶的 MCT標志都被置為 1, 所以在用戶掛機時 , 會將該模塊唯一的 MCT_HANDLE資源釋放掉 . 則以后該功能又可以正常實現(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錯誤。 【結 論】 通過調(diào)測發(fā)現(xiàn)、定位并解決問題。 【思考與啟示】 我們平常一些熟視無睹的業(yè)務或按正常流程操作沒有問題的業(yè)務，不能保證它就一定沒有問題，要善于抓住一絲一毫的異?，F(xiàn)象。對于很難重現(xiàn)的問題千萬不要輕易放過，我們網(wǎng)上設備所出的問題很多都是一些在實驗室難以出現(xiàn)或很難重現(xiàn)的一些問題，一些顯而易見的問題一般都可消滅在實驗室，難就難在消滅一些隱藏很深的問題。說老實話，我們的產(chǎn)品還有 許多問題 ，需要我們扎扎實實鍥而不舍的工作。 分配資源是否已正確釋放 【案例 】 【正 文】 在對接入網(wǎng) A產(chǎn)品的網(wǎng)管軟件測試中，發(fā)現(xiàn)了一個 WINDSOWS資源損耗的的問題：當網(wǎng)管軟件運行幾天后， WINDOWS總會出現(xiàn)“資源不夠”的告警提示。如果網(wǎng)管軟件不關掉再重新啟動的話，就會出現(xiàn) WINDOWS資源完全耗盡的現(xiàn)象，最終網(wǎng)管系統(tǒng)反應很慢，無法正常工作。 從現(xiàn)象上可以判斷出，網(wǎng)管軟件存在隱蔽的內(nèi)存泄露或資源不釋放的問題，并且這種資源耗盡是一個緩慢的過 程。如何定位這個問題呢？ 定位這種問題可以利用 WINDOWS中的一個系統(tǒng)資源監(jiān)視工具。打開Windows的“附件 /系統(tǒng)工具 /資源狀況”，這是一個系統(tǒng)資源、用戶資源、和 GDI資源的實時監(jiān)視工具。 工具有了，那么如何發(fā)現(xiàn)導致不斷消耗資源的特定操作呢？ 首先和開發(fā)人員共同探討，列出幾個最可能消耗資源的操作和一些操作組合，這樣就縮小了監(jiān)視范圍，避免沒有范圍的碰運氣，否則如大海撈針。 監(jiān)視前，首先重新啟動 WINDOWS，最好不運行其他的程序，打開“系統(tǒng)狀況”這個監(jiān)視工具，然后運行網(wǎng)管軟件，記 下此時的資源狀況數(shù)據(jù)。 然后針對一個可疑的操作，快速大量地重復進行。這種重復性的操作可以利用 QArun測試工具執(zhí)行， QArun可以記錄操作者的一次操作步驟，然后按照設定的次數(shù)重復操作。操作后，觀察此時的資源狀況，并記下此時的數(shù)據(jù)，與操作前的數(shù)據(jù)比較，如果操作前后的數(shù)據(jù)數(shù)據(jù)沒有變化或變化很小，可排除此項操作，否則就可斷定此項操作會引起資源耗盡。 對其它可疑的操作和操作組合重復以上過程。 通過以上的步驟，終于找出引起資源耗盡的罪魁禍首。分析相應部分的代碼，發(fā)現(xiàn)引起資源耗盡原因有：內(nèi)存泄露，畫筆和畫刷資源用 完后未釋放等。 【案例 】 【正 文】 某產(chǎn)品后臺軟件版本，是用 C++寫的，程序員在寫代碼時，經(jīng)常在構造函數(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。 pdbffiled