2008-11-13
案例 1
在计费测试的过程中，用呼叫器进行大话务量呼叫测试。30路话路通过TUP自环呼叫另外30路话路，计费数据的设定是这样的：通过计费情况索引对主叫计费，得到详细话单。首先保证计费数据设定的正确性，打了几次自环电话后，查看话单正常，则开始呼叫。
呼叫几万次后停止呼叫，取话单进行观察。发现这30路每次呼叫总会出现一张告警话单，其余话单正常，该告警话单相对于话路来说是随机出现的。
通知开发人员后，首先我们再次对计费数据进行了确认。某个用户在某次呼叫产生了告警话单，其上一次和下一次呼叫的计费情况都正常，两次呼叫之间的时间间隔只有几秒钟，排除了人为修改数据的可能。开发人员认为是CCB的问题，后来一查果然如此。
当中继选线发生了同抢需要重新选线时，CCB的reset_CCB_for_reseatch_called_location()就会把有关的呼叫信息清掉，造成计费情况分析失败，产生计费费用为0的告警话单。
更正reset_CCB_for_reseatch_called_location()中清除被叫信息的代码，重选中继时不清除被叫用户这部分属性。
思考与启示：
1、在计费测试过程中，对话单的观察很重要，不应该放过任何一个细小的疑点；
2、计费测试仅仅打几次电话往往达不到效果，越接近用户实际使用的情况越可能发现问题。
评论3
楼主 2008/11/6 12:57:17
案例 2
【案例描述】
在进行128模块V5用户CENTREX新业务测试时，偶然遇到一个怪现象：对群内一个V5ST用户只开放MCT权限，在进行恶意呼叫追查时，有一次报恶意呼叫追查成功音只报了一半，当正要报出恶意呼叫的号码时，业务中断重新回到通话态，随即重新追查一次，报“已申请其它新业务，本次申请不成功”。恶意呼叫追查与任何新业务都不会冲突，而且此用户也只有恶意呼叫追查有权，可以肯定此时程序出问题了。为了重现，再次挂机，重新呼叫，应用此新业务，但这个现象一直没有出现。大约反复操作20遍，又出现了一次这样的情况，显然程序中可能存在某种问题。
【处理过程】
出现这个问题后，及时与开发人员A取得了联系，并一起试图重现这个问题，通过许多次的反复操作，又出现了一次这种情况。确认问题后，A表现出高度的责任心，马上驾调试环境，反复调测，终于在当天就逮住了狐狸尾巴：
1、当用户接听恶意呼叫者的电话, 并启动恶意呼叫追查业务后, 在V5_CR_VOICETONE状态下, 只要听MCT音的用户用脉冲方式拨任意一个数字, 则立即停止送MCT音, 而将用户切换回与恶意呼叫者的通话. 但是程序中没有对拨号类型作判断, 导致用户若用音频拨号也会作同样的处理。
2、除了取消此次MCT服务, 将用户切换回与恶意呼叫者的通话外, 如果不释放MCT_HANDLE, 由于每个模块只有一个这样的资源, 则下一次使用MCT业务的用户不能成功, 因为会在申请MCT_HANDLE时失败, V5模块和ST模块在这个地方处理都有问题, 没有将MCT_HANDLE释放掉, 对于V5用户会听新业务失败音, 对于ST用户会听音乐。
当不停的拨测V5用户的MCT业务时, 有时在听音时, 可能由于网板有杂音等原因(或用户碰了话机的按键), 导致DTR收到一位号, 则会立即停止此次MCT服务, 用户会听到MCT送音突然中断, 然后恢复了与恶意呼叫者的通话. 而下次再用MCT时, 由于上面所述的原因, 会听到新业务失败音, 此次失败后, 无论MCT_HANDLE分配成功与否, 该用户的MCT标志都被置为1, 所以在用户挂机时, 会将该模块唯一的MCT_HANDLE资源释放掉. 则以后该功能又可以正常实现。
在追查这个问题时，开发人员A又发现了一个可能导致死机的严重问题：在用户启动MCT服务, 正在听报追查号码的MCT音时, 若恶意用户此时挂机, CCB的处理中, 只针对ST用户送DISCONNECT, 而对V5ST用户送的是RELEASE消息, 这导致V5X收到此消息后, 将该V5ST用户的cr2清除掉, V5_USER_TALBE[ ]. cr2变为0xFFFF, 这样在V5_CR_VOICETONE超时后, 程序中会检查cr2的状态是否为HOLD, 当取cr2的内容时, 由于cr2已被清除, 会发生指针越界的GP错误。
【结 论】
通过调测发现、定位并解决问题。
【思考与启示】
我们平常一些熟视无睹的业务或按正常流程操作没有问题的业务，不能保证它就一定没有问题，要善于抓住一丝一毫的异常现象。对于很难重现的问题千万不要轻易放过，我们网上设备所出的问题很多都是一些在实验室难以出现或很难重现的一些问题，一些显而易见的问题一般都可消灭在实验室，难就难在消灭一些隐藏很深的问题。说老实话，我们的产品还有许多问题 ，需要我们扎扎实实锲而不舍的工作。
楼主 2008/11/13 18:41:55
