【正文】 //只輸出滿足條件的前200張?jiān)拞? if (++wBillCount == 200) { timeCur = timeEnd + tsOneDay。//退出第二層循環(huán), while(timeCur = timeEnd) break。 } 作上述修改后問(wèn)題就不再出現(xiàn)了。 一些MML命令從完成的功能來(lái)講可能是沒(méi)什么問(wèn)題的，但其執(zhí)行對(duì)系統(tǒng)性能的影響我們?cè)跍y(cè)試時(shí)時(shí)往往給忽視了。在我們目前的BAM方案中，存在著多個(gè)終端協(xié)同工作，如果某個(gè)終端發(fā)出的命令在BAM中長(zhǎng)時(shí)間獨(dú)占著大部分系統(tǒng)資源，造成的后果是嚴(yán)重的。這是在設(shè)計(jì)時(shí)要避免的，在測(cè)試中要注意的問(wèn)題。【】【正 文】 在判斷模擬用戶端口是否反極性時(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路用戶板（藍(lán)色字體判斷），就看端口號(hào)是否是第15和16路，如果是，就是反極性端口，返回TRUE，否則就不是，應(yīng)該返回FALSE。但代碼表達(dá)的意思是：如果是32路用戶板并且端口號(hào)是15或16就返回真值，否則還要執(zhí)行下邊語(yǔ)句。 當(dāng)端口在32路用戶板上，但端口號(hào)不是15或16時(shí)，不同的32路端口的起始地址g_wASL32StartPSN，會(huì)導(dǎo)致不同的非116端口被誤認(rèn)為是反極性端口。舉個(gè)例子，當(dāng)g_wASL32StartPSN的值為3000時(shí)，端口號(hào)為3000（第一塊板上的第0個(gè)端口）就被認(rèn)為是反極性端口，這與作者的意圖完全相悖。 可以將代碼修改如下： if ( ( bsn = g_wASL32StartPSN ) { if ( ( ( bsn g_wASL32StartPSN ) % 32 ) == 15 || ( ( bsn g_wASL32StartPSN ) % 32 == 16 ) ) ) return TRUE。 } else if ( ( bsn % 16 ) == 7 || ( bsn % 16 ) == 8 ) return TRUE。 return FALSE。 通過(guò)這個(gè)例子，我覺(jué)得在代碼審查時(shí)應(yīng)該留意在判斷條件較多的情況下，每個(gè)輸入是否都能正確輸出，在單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試時(shí)要針對(duì)邊界值設(shè)計(jì)相應(yīng)的測(cè)試用例。 判斷條件較多時(shí)開(kāi)發(fā)人員也應(yīng)該適當(dāng)分開(kāi)寫(xiě)，既使代碼更易讀，又不容易出錯(cuò)。條件分支處理是否有遺漏【】【現(xiàn) 象】 在接入網(wǎng)主機(jī)程序的代碼審查中，在數(shù)據(jù)異常的情況下，會(huì)產(chǎn)生較嚴(yán)重的問(wèn)題?！咎幚磉^(guò)程】 該錯(cuò)誤比較隱蔽，現(xiàn)在說(shuō)明如下： Max2B1QStatTime 最大統(tǒng)計(jì)時(shí)間 Max2B1QStatPortNum最大統(tǒng)計(jì)端口數(shù) MAX_2B1Q_STAT_PSN 最大統(tǒng)計(jì)內(nèi)存分配數(shù)量 其中：Max2B1QStatTime（最大統(tǒng)計(jì)時(shí)間）和Max2B1QStatPortNum（最大統(tǒng)計(jì) 端口數(shù)）的乘積不能大于MAX_2B1Q_STAT_PSN 程序如下： //查詢數(shù)據(jù)庫(kù)，獲得Max2B1QStatTime的值 = 10。 error_code = DB_Query( RID_OTHERS_PARA_INFO, 1, (LPDBCondition)amp。directQueryCond, (BYTE FAR *)amp。tempstruct0 )。 //查詢數(shù)據(jù)庫(kù)成功 if( error_code == DB_SUCCESS ) { // if ( MAX_2B1Q_STAT_PSN ) Max2B1QStatTime = MAX_2B1Q_STAT_PSN。 else if ( != 0 ) Max2B1QStatTime = 。 } //查詢數(shù)據(jù)庫(kù)，獲得Max2B1QStatPortNum的值 = 11。 error_code = DB_Query( RID_OTHERS_PARA_INFO, 1, (LPDBCondition)amp。directQueryCond, (BYTE FAR *)amp。tempstruct0 )。 //查詢數(shù)據(jù)庫(kù)成功 if( error_code == DB_SUCCESS ) { //，如果其缺省值和Max2B1QStatTime乘積值大于MAX_2B1Q_STAT_PSN的話： if ( ( * Max2B1QStatTime) MAX_2B1Q_STAT_PSN ) Max2B1QStatPortNum = MAX_2B1Q_STAT_PSN / Max2B1QStatTime。 //如果在合理范圍內(nèi)且不為0的話： else if ( != 0 ) Max2B1QStatPortNum = 。 } 此處ifelse if 分支沒(méi)有判斷 值為0的情況，即數(shù)據(jù)庫(kù)為Max2B1QStatPortNum配置的值為0： == 0，則Max2B1QStatPortNum就為缺省值32?！窘Y(jié) 論】 由于內(nèi)存限制，Max2B1QStatTime（最大統(tǒng)計(jì)時(shí)間）和Max2B1QStatPortNum（最大統(tǒng)計(jì)端口數(shù)）的乘積不能大于MAX_2B1Q_STAT_PSN， 如果從數(shù)據(jù)庫(kù)中得到Max2B1QStatTime為MAX_2B1Q_STAT_PSN，而數(shù)據(jù)庫(kù)中最大統(tǒng)計(jì)端口數(shù)恰好為0， == 0的情況進(jìn)行判斷，Max2B1QStatPortNum為缺省值32，這樣Max2B1QStatTime和Max2B1QStatPortNum乘積已經(jīng)是32倍MAX_2B1Q_STAT_PSN了，遠(yuǎn)遠(yuǎn)超過(guò)了設(shè)計(jì)內(nèi)存的限制。 造成這種錯(cuò)誤的原因是判斷語(yǔ)句對(duì)條件判斷不完整?！舅伎寂c啟示】 在代碼審查時(shí)，應(yīng)該十分注意條件判斷的的完備性。好多問(wèn)題就是因?yàn)闂l件判斷不完全造成的。引用已釋放的資源【】【正 文】 在計(jì)費(fèi)測(cè)試的過(guò)程中，用呼叫器進(jìn)行大話務(wù)量呼叫測(cè)試。30路話路通過(guò)TUP自環(huán)呼叫另外30路話路，計(jì)費(fèi)數(shù)據(jù)的設(shè)定是這樣的：通過(guò)計(jì)費(fèi)情況索引對(duì)主叫計(jì)費(fèi)，得到詳細(xì)話單。首先保證計(jì)費(fèi)數(shù)據(jù)設(shè)定的正確性，打了幾次自環(huán)電話后，查看話單正常，則開(kāi)始呼叫。呼叫幾萬(wàn)次后停止呼叫，取話單進(jìn)行觀察。發(fā)現(xiàn)這30路每次呼叫總會(huì)出現(xiàn)一張告警話單，其余話單正常，該告警話單相對(duì)于話路來(lái)說(shuō)是隨機(jī)出現(xiàn)的。 通知開(kāi)發(fā)人員后，首先我們?cè)俅螌?duì)計(jì)費(fèi)數(shù)據(jù)進(jìn)行了確認(rèn)。某個(gè)用戶在某次呼叫產(chǎn)生了告警話單，其上一次和下一次呼叫的計(jì)費(fèi)情況都正常，兩次呼叫之間的時(shí)間間隔只有幾秒鐘，排除了人為修改數(shù)據(jù)的可能。開(kāi)發(fā)人員認(rèn)為是CCB的問(wèn)題，后來(lái)一查果然如此。 當(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)測(cè)試過(guò)程中，對(duì)話單的觀察很重要，不應(yīng)該放過(guò)任何一個(gè)細(xì)小的疑點(diǎn)； 計(jì)費(fèi)測(cè)試僅僅打幾次電話往往達(dá)不到效果，越接近用戶實(shí)際使用的情況越可能發(fā)現(xiàn)問(wèn)題?！尽俊景咐枋觥? 在進(jìn)行128模塊V5用戶CENTREX新業(yè)務(wù)測(cè)試時(shí)，偶然遇到一個(gè)怪現(xiàn)象：對(duì)群內(nèi)一個(gè)V5ST用戶只開(kāi)放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í)程序出問(wèn)題了。為了重現(xiàn)，再次掛機(jī)，重新呼叫，應(yīng)用此新業(yè)務(wù)，但這個(gè)現(xiàn)象一直沒(méi)有出現(xiàn)。大約反復(fù)操作20遍，又出現(xiàn)了一次這樣的情況，顯然程序中可能存在某種問(wèn)題。 【處理過(guò)程】 出現(xiàn)這個(gè)問(wèn)題后，及時(shí)與開(kāi)發(fā)人員A取得了聯(lián)系，并一起試圖重現(xiàn)這個(gè)問(wèn)題，通過(guò)許多次的反復(fù)操作，又出現(xiàn)了一次這種情況。確認(rèn)問(wèn)題后，A表現(xiàn)出高度的責(zé)任心，馬上駕調(diào)試環(huán)境，反復(fù)調(diào)測(cè)，終于在當(dāng)天就逮住了狐貍尾巴： 當(dāng)用戶接聽(tīng)惡意呼叫者的電話, 并啟動(dòng)惡意呼叫追查業(yè)務(wù)后, 在V5_CR_VOICETONE狀態(tài)下, 只要聽(tīng)MCT音的用戶用脈沖方式撥任意一個(gè)數(shù)字, 則立即停止送MCT音, 而將用戶切換回與惡意呼叫者的通話. 但是程序中沒(méi)有對(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è)地方處理都有問(wèn)題, 沒(méi)有將MCT_HANDLE釋放掉, 對(duì)于V5用戶會(huì)聽(tīng)新業(yè)務(wù)失敗音, 對(duì)于ST用戶會(huì)聽(tīng)音樂(lè)。 當(dāng)不停的撥測(cè)V5用戶的MCT業(yè)務(wù)時(shí),