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