-
-
手机阅读
案例 1
【案例描述】：
在测试主机MPU板倒换功能时，如果MPU备份充分，倒换前后对处于激活状态的电路应无影响，即不影响通话。但近期测试发现，如果两局通过DT板进行一号对接，MPU备份倒换却发生断话。具体现象为：如果DT板的第1个PCM系统电路为故障，则MPU倒换时复位该DT板，如果DT板的第2个PCM系统电路为故障，则MPU倒换时复位下一块DT。
【处理过程】：
据查，MPU倒换时会自动复位处于“故障”态的电路，但由于计算错误（多加了32），错复位了下一个PCM系统32路电路。
【结 论】：
如此严重问题为什么到今天才发现？因为我们在实验室中一般采用同一单板的2个PCM系统自环进行测试，则不会在某单板上有故障和空闲电路共存，自环屏蔽了错误。
【思考与启示】：
自环是在测试环境下常用的一种提高效率的手段，但一旦条件允许，我们的测试工作应尽量模拟网上的实际环境进行。
-
-
-
xilinxue 发表于 2008/11/6 12:55:24
2楼 回复本楼
案例 2
平时对计费功能进行测试的时候，浏览详细话单都是比较注意话单本身的正确性，并没有注意该命令对系统的影响。所以当浏览少量话单的时候，并没有发现该命令的异常。但是当时间的跨度较大时，详细话单数量较多，问题就出现了。执行如下命令：
LST AMA: TP="NRM", SD="1999"&7&1, SA="YES";
当浏览了大约10万张详细话单后，终端与BAM的连接关闭。重建连接后，发现话单台的命令不能执行。观察BAM的性能，发现话单台仍占有CPU50%以上的利用率，说明原来的任务仍在执行。需要关一下话单台才能恢复正常。
重复上述步骤，当终端与BAM的连接尚未关闭时主动断开此次连接，结果同上。
反馈到开发人员那里，发现该现象与设计的初衷是相违背的。本来话单台控制最多输出200张话单，这是为了防止过多话单的输出显示会增加BAM的开销，从而降低BAM的性能。查看一下源代码，问题就发现了。
话单台控制最多输出200张话单
程序如下
while(timeCur <= timeEnd)
{
timeCur += tsOneDay;//加一天while(fileBill.Read(&rpt, sizeof(CBillReport)) ==
sizeof(CBillReport))
{
.....................
//只输出满足条件的前200张话单
if (++wBillCount == 200)
{
break;
}
}//一个文件查询结束
}//所有文件查询结束在话单输出200张之后，程序只退出一层循环，仍然会从下一天话单继续输出，导致向MML发帧过多，造成MML和话单台都被堵死。
修改ProcessQueryBill()函数
//只输出满足条件的前200张话单
if (++wBillCount == 200)
{
timeCur = timeEnd + tsOneDay;//退出第二层循环,
while(timeCur <= timeEnd)
break;
}
作上述修改后问题就不再出现了。
一些MML命令从完成的功能来讲可能是没什么问题的，但其执行对系统性能的影响我们在测试时时往往给忽视了。在我们目前的BAM方案中，存在着多个终端协同工作，如果某个终端发出的命令在BAM中长时间独占着大部分系统资源，造成的后果是严重的。这是在设计时要避免的，在测试中要注意的问题。
引用 xilinxue 2008/11/6 12:55:24 发表于2楼的内容
-
-
-
-
xilinxue 发表于 2008/11/6 12:55:42
3楼 回复本楼在判断模拟用户端口是否反极性时有这样一段程序：
if ( ( bsn >= g_wASL32StartPSN ) &&
( ( ( bsn - g_wASL32StartPSN ) % 32 ) == 15 || ( ( bsn - g_wASL32StartPSN ) % 32 == 16 ) ) )
return TRUE;
if ( ( bsn % 16 ) == 7 || ( bsn % 16 ) == 8 )
return TRUE;
return FALSE;作者的本意是如果是32路用户板（蓝色字体判断），就看端口号是否是第15和16路，如果是，就是反极性端口，返回TRUE，否则就不是，应该返回FALSE。但代码表达的意思是：如果是32路用户板并且端口号是15或16就返回真值，否则还要执行下边语句。
当端口在32路用户板上，但端口号不是15或16时，不同的32路端口的起始地址g_wASL32StartPSN，会导致不同的非15、16端口被误认为是反极性端口。举个例子，当g_wASL32StartPSN的值为3000时，端口号为3000（第一块板上的第0个端口）就被认为是反极性端口，这与作者的意图完全相悖。
可以将代码修改如下：
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;
通过这个例子，我觉得在代码审查时应该留意在判断条件较多的情况下，每个输入是否都能正确输出，在单元测试、集成测试、系统测试时要针对边界值设计相应的测试用例。
判断条件较多时开发人员也应该适当分开写，既使代码更易读，又不容易出错。
引用 xilinxue 2008/11/6 12:55:42 发表于3楼的内容
-