问题描述（故障现象）
组网环境
问题原因分析
名建立
成功
率
（%）立成
功率
（%）
率
（%）
率
（%）
重建
比率
（%）
换成
功率
（%）
换成
功率
（%）
率
（%）
1 N M -火车站候车
厅L D B -C H -1 199.9
7
99.9
7
99.9
3
0.190.5899.8
2
99.5
1
99.8
1 N M -火车站候
车厅L D B -C H -199.899.8
6
99.6
6
0.050.7798.2
6
97.398.2
3
从上表中可以看到我们可以看到这两个小区的LTE 重要KPI 指标全部正常，可以判断出现CSFB 失败的原因不在于LTE 网络，应该是在4G 与2G 的互操作过程中或者2G 网络呼叫中。
我们使用测试终端+2G 终端+CXT 测试软件在现场进行测试。通过现场测试，使用2G 终端作为主叫，CSFB 终端作为被叫进行测试，一共呼叫50次，其中被叫失败11次，与我们在后台指标反映的指标一致。从空口信令中可以发现，失败的CSFB 业务基本都有个共同的问题：回落之后UE 发起位置区更新请求，然后核心网拒绝位置区更新，CSFB 业务失败，可以简单判断，CSFB 失败的主要原因是GSM 侧出现问题。业务失败的信令截图如下所示：
详细分析
目前现网的LTE 站点基本与周边GSM 站点的LAC 保持一致，以保持寻呼的连续性，由于出现失败时伴随位置区更新，我们对1NM-火车站候车厅LDB-CH-10和1NM-火车站候车厅LDB-CH-11的TAC 和周边GSM 站点的LAC 进行核查，全部都为34051，正常情况下不应该存在位置区更新。带着这个疑问，我们对失败信令进行详细的分析，从测试LOG 的数据中导出一次完整的失败信令，并将GSM 小区收到的System Information Type 3中携带的小区数据标注在后面，详细信息如下：
N o
Di r
Stan dard
L
a y e r Message
PCTime
携带小区信息
1
↓
TDLT E
R
R C
DLInformationTransfer
16:29:20:948
2
↑
TDLT E
E M
Extended service request
16:29:20:950
M
3↑TDLT
E R
R
C
ULInformationTransfer
16:29:2
0:951
4↓TDLT
E R
R
C
RRCConnectionRelease
16:29:2
1:008
5↓
GSM R
R System Information Type 4
16:29:2
1:317
6↓
GSM R
R System Information Type 3
16:29:2
1:562
11075-2
341
7↓
GSM R
R System Information Type 2
16:29:2
1:788
8↓
GSM R
R System Information Type 3
16:29:2
2:023
11075-2
341
9↓
GSM R
R System Information Type 4
16:29:2
2:258
1 0↓
GSM
R
R System Information Type 1
16:29:2
2:495
1 1↑
GSM
M
M Location Updating Request
16:29:2
2:501
1 2↓
GSM
R
R System Information Type 2
16:29:2
2:738
1 3↓
GSM
R
R Immediate Assignment
16:29:2
2:757
1 4↑
GSM
R
R Measurement Report
16:29:2
3:005
1↓GSM R System Information Type 516:29:2
5R3:137
1 6↓
GSM
M
M Identity Request
16:29:2
3:225
1 7↑
GSM
M
M Identity Response
16:29:2
3:225
1 8↓
GSM
M
M Identity Request
16:29:2
3:461
1 9↑
GSM
M
M Identity Response
16:29:2
3:461
2 0↑
GSM
R
R Measurement Report
16:29:2
3:475
2 1↓
GSM
M
M Location Updating Reject
16:29:2
3:696
2 2↓
GSM
R
R Channel Release
16:29:2
3:931
2 3↓
GSM
R
R System Information Type 4
16:29:2
5:001
2 4↓
GSM
R
R System Information Type 3
16:29:2
5:088
11075-2
341
2 5↓
GSM
R
R System Information Type 13
16:29:2
5:243
2 6↓
GSM
R
R System Information Type 2ter
16:29:2
5:478
2 7↓
GSM
R
R System Information Type 3
16:29:2
5:715
34051-3
572
2 8↓
GSM
R
R System Information Type 4
16:29:2
5:940
2 9↓
GSM
R
R System Information Type 1
16:29:2
6:176
3 0↓
GSM
R
R System Information Type 2
16:29:2
6:411
3 1↑
GSM
M
M Location Updating Request
16:29:2
6:417
3 2↓
GSM
R
R Immediate Assignment
16:29:2
6:606
3 3↓
GSM
R
R System Information Type 5
16:29:2
6:818
3 4↑
GSM
R
R Classmark Change
16:29:2
6:906
3 5↑
GSM
R
R GPRS Suspension Request
16:29:2
6:907
3 6↑
GSM
R
R Measurement Report
16:29:2
7:157
3 7↓
GSM
R
R System Information Type 5ter
16:29:2
7:290
3 8↓
GSM
M
M Authentication Request
16:29:2
7:377
3 9↑
GSM
M
M Authentication Response
16:29:2
7:495
4 0↑
GSM
R
R Measurement Report
16:29:2
7:628
4 1↓
GSM
R
R System Information Type 6
16:29:2
7:760
4 2↓
GSM
M
M
Location Updating Accept
16:29:2
7:847
4 3↑
GSM
M
M TMSI Reallocation Complete
16:29:2
7:851
4 4↑
GSM
R
R Measurement Report
16:29:2
8:098
4 5↓
GSM
R
R Channel Release
16:29:2
8:318
4 6↑
GSM
G
M
M
Routing Area Update Request
16:29:2
8:582
4 7↓
GSM
R
R Immediate Assignment
16:29:2
8:696
4 8↓
GSM
R
R System Information Type 2quater
16:29:2
9:022
4 9↓
GSM
R
R System Information Type 2quater
16:29:2
9:041
5 0↓
GSM
G
M
M
Authentication and Ciphering Requ
est
16:29:2
9:803
5 1↑
GSM
G
M
M
Authentication and Ciphering Resp
onse
16:29:2
9:952
5 2↓
GSM
R
R System Information Type 3
16:29:3
0:047
34051-9
932
5 3↑
GSM
G
M
M
Routing Area Update Complete
16:29:3
0:445
5 4↓
GSM
G
M
M
Routing Area Update Accept
16:29:3
0:447
5 5↓
GSM
G
S
M
M
Modify PDP Context Request
16:29:3
0:447
5 6↑
GSM
G
S
M
M
Modify PDP Context Accept
16:29:3
0:451
5 7↓
GSM
R
R System Information Type 3
16:29:3
1:626
11075-2
341
5 8↓
GSM
R
R System Information Type 13
16:29:3
2:710
5 9↓
GSM
R
R System Information Type 2ter
16:29:3
2:946
6 0↓
GSM
R
R System Information Type 2quater
16:29:3
4:593
6 1↓
GSM
R
R System Information Type 13
16:29:3
6:272
6 2↓
GSM
R
R System Information Type 2ter
16:29:3
6:508
6 3↓
GSM
R
R System Information Type 2quater
16:29:3
8:156
6 4↓
GSM
R
R System Information Type 3
16:29:3
9:567
34051-3
571
6 5↓
GSM
R
R System Information Type 3
16:29:4
0:197
34051-9
931
6 6↓
GSM
R
R System Information Type 3
16:29:4
1:378
34051-9
937
6 7↓
GSM
R
R System Information Type 3
16:29:4
2:320
34051-9
936
6 8↓
GSM
R
R System Information Type 3
16:29:4
3:533
34051-1
1110
6 9↓TDSC
DMA
R
R
C
systemInformationBlockType3
16:29:4
9:832
7 0↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:4
9:872
7 1↓TDSC
DMA
R
R
C
schedulingBlock1
16:29:4
9:892
7 2↓TDSC
DMA
R
R
C
systemInformationBlockType5
16:29:4
9:932
7 3↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:4
9:952
7 4↓TDSC
DMA
R
R
C
systemInformationBlockType7
16:29:4
9:972
7 5↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:5
0:032
7 6↓TDSC
DMA
R
R
C
schedulingBlock1
16:29:5
0:052
7 7↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:5
0:112
7 8↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:5
0:192
7 9↓TDSC
DMA
R
R
C
schedulingBlock1
16:29:5
0:212
8 0↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:5
0:272
8 1↓TDSC
DMA
R
R
C
systemInformationBlockType11
16:29:5
0:292
8 2
↓TDSC
DMA
R
R
C
masterInformationBlock
16:29:5
0:352
从第2条信令开始，Extended Service request 的详细原因值为service type：Mobile temi
nating CS fallback or 1xCS fallback，这标识这是一次CSFB-MTC，截图如下：第4条信令RRCConnectionRelease中携带回落的GSM频点，截图如下：
第6和8条信令均为System Information Type 3，里面携带的小区为cellid和LAC信息已经标注在上表的最后一列，均为11075-2341，通过查询GSM小区的工参，11075不是正常的LAC号，由于回落后的小区LAC与LTE小区1NM-火车站候车厅LDB-CH-11的TAC=34051不一致，UE发起位置区更新请求，见第11条信令。
在第21条信令中，UE收到核心网下发的Location Updating Reject，原因值为：No Suitable Cells In Location Area(在此LAC区内无合适的小区)，如下图所示：
随后信道释放，本次CSFB被叫寻呼失败，主叫UE的界面直接显示呼叫失败。从后续的系统消息来看UE重选回正常小区之后，按照正常流程通过重选至3G桥接返回4G。
通过与市公司2G侧人员沟通，本次失败回落的异常小区（11075-2341）很有可能是非法基站导致，我们的现场测试人员在现场有收到诈骗广告短信，也增大了非法基站存在的可能性。
通过测试软件GSM小区信息窗口可以看出，在占用该非法基站时显示信息如下图所示：
从图示信息来看，该小区BCCH为33，BSIC为24，Rvlex为-52和Rxqual为0。非法小区BC CH频点为33，我们从之前信令分析中可以看出，RRCConnectionRelease中携带回落的GSM频点包含33，通过查询最新的邻区信息表与GSM工参，1NM-火车站候车厅LDB-CH-11的GSM邻区1NM_明珠饭店-3小区频点也为33，由于非法基站的Rxlev达到-52，所以UE很容易就回落到这个小区上，并会发生LAU，进而导致CSFB业务失败。
问题解决方案
由于1NM_明珠饭店-3距离火车站候车厅的距离非常近，删除邻区可能会导致出现新的问题，建议将1N M_明珠饭店-3小区的BCCH改为41，同时将1NM-火车站候车厅LDB-CH-11 GSM邻小区中的频点3 3删除，保证不让UE回落至非法基站。
通过1NM_明珠饭店-3小区的BCCH改为41，同时将1NM-火车站候车厅LDB-CH-11 GSM邻小区中的频点33删除调整，火车站的两个室分小区1NM-火车站候车厅LDB-CH-10和1NM-火车站候车厅LDB-CH-11的CSFB被叫接通率指标明显改善。1月24日修改前后两天的指标如下表所示：
开始时间S1AP EC
I
小区名
被
叫
总
次
数
被
叫
成
功
次
数
被
叫
失
败
次
数
被
叫
成
功
率
2015/1/
231415772
26
1NM-火车站候车厅LDB-CH-10
445344101
77.
30%
2015/1/
231415772
27
1NM-火车站候车厅LDB-CH-11
306234
72
76.
47%
2015/1/
241415772
26
1NM-火车站候车厅LDB-CH-10
308222
86
72.
08%
2015/1/
241415772
27
1NM-火车站候车厅LDB-CH-11
223178
45
79.
82%
2015/1/
251415772
26
1NM-火车站候车厅LDB-CH-10
446423
23
94.
84%
2015/1/
251415772
27
1NM-火车站候车厅LDB-CH-11
355339
16
95.
49%
2015/1/
261415772
27
1NM-火车站候车厅LDB-CH-10
575539
36
93.
74%
2015/1/
261415772
26
1NM-火车站候车厅LDB-CH-11
574552
22
96.
17%
2015/1/
271415772
27
1NM-火车站候车厅LDB-CH-10
239225
14
94.
14%
2015/1/
271415772
26
1NM-火车站候车厅LDB-CH-11
274258
16
94.
16%
总结及注意事项
非法基站在现网中比较常见，本例中调整网络中的参数只是一种规避手段，后续还应该上报局方，通过其他手段再对非法基站的问题进行进一步的打击和取缔，以尽量降低非法基站对现网的影响。
知识评价
目录 第1章CT工具的基本知识 (4) 1.1CT工具的配置 (4) 1.1.1服务器端配置 (4) 1.1.2客户端配置 (4) 1.1.3单机版使用 (6) 第2章信令分析说明 (7) 2.1 基本知识准备 (7) 2.1.1如何看业务信令 (7) 2.1.2流程中的几个重要概念 (9) 2.2 RRC建立过程的信令分析 (10) 2.2.1 RRC Connection Request信令综述 (10) 2.2.2 RRC Connection Request信令 (11) 2.2.3 Radio Link Setup信令 (13) 2.2.4 Radio Link Setup Response信令 (26) 2.2.5 Radio Link Setup Failure信令 (27) 2.2.6 RRC Connection Setup信令 (28) 2.2.7 Radio Link Restore Indication信令 (37) 2.2.8 RRC Connection SetupComplete信令 (37) 2.2.8 RRC建立过程中常见问题 (38) 2.3初始直传信令分析 (39) 2.3.1 InitialDirectTransfer信令分析 (41) 2.3.2 InitialUEMessage信令分析 (42) 2.3.2 CommonID信令分析 (42) 2.4鉴权过程（可选）信令分析 (43) 2.4.1 DirectTransfer信令分析（图中1） (46) 2.4.2 DownLinkDirectTransfer信令分析（图中2） (46) 2.4.3 UpLinkDirectTransfer信令分析（图中3） (47) 2.4.4 DirectTransfer信令分析（图中4） (47) 2.4.5 鉴权过程中常见问题 (48) 2.5安全模式信令分析 (48) 2.5.1 SecurityModeCommand（Iu口上，CN到RNC） (49) 2.5.2 SecurityModeCommand（Uu口上，RNC到UE） (53)
信令跟踪在维护工作中的运用目前移动通信竞争激烈,客户对移动运营商的要求越来越高。运营商对我们的要求也就更高。优质的网络是我们公司发展的基础,确保网络的正常运行是我们公司的立足之本。在这里简要谈谈信令跟踪在网络维护工作中的运用。 所谓信令跟踪分析是指用仪表收集跟踪移动通信的无线链路上的信令数据并加以整理,从中查找出异常的指标数据;利用软件进行分析,找出故障所在,并有效地解决排除,最终达到提高网络运行质量的目的。 信令跟踪在网络优化工作中也是比较重要的一步,它主要用来查找硬件的隐性故障和干扰频点等问题;无线链路上的信令提供了较全面的质量数据。用阿尔卡特公司的DAFNE软件分析的数据中可以看到各频点的上下行接收电平、上下信道质量、上下行信道质量差、上下行路径损耗、上下行路径差、信道质量分布表、时间提前量分布、信令统计等信息。 那么我们怎么通过这些数据来分析网络中的隐藏的故障呢?下面通过对网络中平常的一些隐性故障的处理来介绍一下信令跟踪分析数据的运用。 由于无线环境的恶劣性,移动通信的无线信道无时不经受着来自外界或本身的干扰。我们怎么从信令数据中查找受干扰的频点呢?一般说来,干扰直接影响信道质量的下降,但对信道的电平则没有多大的影响。所以我们可以查看上下行信道的quality值和上下行的路径损耗值(一般要求上下行信道的quality值在0.5以下,假设某个频点的质量较差,而它的上下行路径损耗与其它频点相差不大,那么这个频点受干扰的可能性比较大。 网络设备的硬件隐性故障问题一直是我们维护人员最头痛的,比如说某基站的 无线原因掉话一直很多,我们可以在分析报告中查看路径损耗值及路径损耗差与信道质量。一般路径损耗差在-10至1dB之间(当然也可以将目标定得高一点,信道质量在0.5以下,如果上行损耗过大或下行损耗过大都很容易引起掉话,所以要更换相应频点的硬件。比如义乌小商品市场的一个基站,每天均有10多次的信道掉话,
X2IPPATH配置问题导致切换不成功 关键字：X2IPPATH 切换 【现象描述】 切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。 【原因分析】 对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种： （1）传输资源不够用； （2）没有配置IPPATH； （3）IPPATH中的邻居节点配置错误。 由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。 【处理过程】 每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。从该次切换的切换命令 （RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。 先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。在webLMT上的命令如下： LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。 DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
保育员实操测验案例分 析题 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
案例分析题1、分析下面案例，回答问题(10分) 二班刘某小朋友随父母到澳洲探亲有32天，正好赶上今天回来参加“六一儿童节”庆祝活动。保育员小李在幼儿园门口一见刘某，就热情地拉着他的手回班化妆，准备参加活动。 ?（1）分析上述案例，说明你的看法。 ?（2）如果是你，该如何处理这种问题 ?保育员小李的做法是错的。婴幼儿如果离开幼儿园一个月以上或到外地，在返回幼儿园时，医务保健人员应向家长询问婴幼儿有无传染病接触史，同时，对该幼儿进行必要的健康检查。对未接触传染病的幼儿要观察两周，有传染病接触史的婴幼儿，应进行个人临时隔离，待检疫期满以后方可回班。 ?应该带刘小朋友到幼儿园医生处对家长进行询问并对刘进行健康检查，看情况决定入班时间。 2、结合案例回答问题 ?入托第二周，保育员小王想：孩子们的情绪基本上安定了，该学学自己洗脸了。于是取来了毛巾和大塑娃娃“瞧，谁来了(出示娃娃)我们都很想跟它做好朋友，可是她的脸脏了，我们先帮它洗干净好吗”边说边做示范：拧干水，擦眼睛、鼻子、嘴巴，在擦额头、脸、下巴，最后擦脖子、耳朵。“好，娃娃讲卫生了，我们一起玩吧！” ?分析上述案例中保育员做法，并阐明原因。 参考答案： 1、保育员用游戏方式引导幼儿学习洗脸，做得好。 2、保育员示范的洗脸顺序是错误的。 3、正确的洗脸顺序是：拧干毛巾→眼睛→额头、脸→鼻子、嘴巴→下巴、脖子、耳朵。
分析下面案例： 3、小二班刘某小朋友下楼梯时滑倒了，啼哭。保育员林某看了看，见刘某额头微肿无出血，就轻轻地给他揉了揉，说：“没关系，勇敢些，不要哭。”餐后，刘某出现了呕吐，林某问：“肚子不舒服吗喝点水，漱漱口就好”。随后清扫了呕吐物。 ?（1）试述保育员的做法正确吗 ?（2）运用相关知识、结合自身的实践谈谈如何正确处理幼儿头摔伤。 答案及评分标准： 指出保育员的错误： （1）不重视头摔伤没有按照正确程序进行观察。（1分） （2）把呕吐物作消化道疾病处理。（1分） 正确处理方法：（1）对于头部摔伤未见出血的情况，要密切观察24小时。（2分）（2）观察中有下列症状，应急送医院救治：恶心、呕吐、剧烈头痛、眼耳鼻出血、抽风、麻痹、语言障碍、意识丧失等。（6分） 4．分析下面案例： 小一班杨某小朋友体温℃，突然眼球凝视、双手握拳、唇青紫、意识丧失，保育员王某估计可能是高热抽搐，马上把孩子平放在床上，然后用手指压其人中沟下三分之一这穴位，并用力撬开其紧闭的牙关，把毛巾塞进口腔内，随后即送医生处理。 ?上述保育员的做法正确吗 ?说说如何正确处理小儿惊厥。 ?答案及评分标准 ?（1）保育员判断是幼儿高热抽搐是正确的。（1分） ?（2）指出错误：1平卧2按压位置3用牙撬开牙关（3分） ?（3）正确的做法：
武 夷 学 院 课程设计报告 数学与计算机学院 课程名称： 软交换与NGN 设计题目： NGN 网络信令跟踪与分析（SIP ）协议 学生班级： 13通信工程（1）班 学生姓名： 张骞文 何凯翔 曾德彪 陈永荣 指导教师： 石贵民 完成日期： 2016-06-17
课程设计项目研究报告 目录 第 1 章项目简介 (1) 1.1 项目名称 (1) 1.2 开发人员 (1) 1.3 指导教师 (1) 第 2 章项目研究意义 (1) 2.1 课程设计概述 (1) 2.2 需求分析及研究意义 (1) 2.3 项目内容 (1) 第 3 章采用的技术 (1) 3.1 SOFTX3000实验脚本 (3) 3.2 IAD实验脚本 (5) 第 4 章课程设计项目进度表 (7) 第 5 章课程设计任务分配表 (7) 第 6 章达到的效果 (8) 6．1程序设计思想 (8) 6．2 程序最终结果 (8) 第 7 章设计心得 (21) 第 8 章参考文献 (22)
第 1 章项目简介 1.1 项目名称 NGN网络信令跟踪与分析（SIP）协议 1.2 开发人员 张骞文（组长）、何凯翔、陈永荣、曾德彪 1.3 指导教师 石贵民 第 2 章项目研究意义 2.1 课程设计概述 通过本次实验，让学生加深对语音分组交换的理解并初步掌握SIP协议的各种消息流程以及分组交换消息抓包解析方法。 2.2 需求分析及研究意义 1、SoftX3000 1台； 2、IAD若干台； 3、实验终端电脑若干台； 4、电话机若干部； 2.3 项目内容 SIP协议 会话启动协议SIP（Session Initiation Protocol ）是由 IETF 提出并主持研究的一个在IP 网络上进行多媒体通信的应用层控制协议，它被用来创建、修改、和终结一个或多个参加者参加的会话进程。这些会话包括Internet 多媒体会议、Internet 电话、远程教育以及远程医疗等。即所有的因特网上交互式两方或多方多媒体通信活动，统称为多媒体会话。参加会话的成员可以通过组播方式、单播联网方式或者两者结合的方式进行通信。
作者：旧在几 作品编号：2254487796631145587263GF24000022 时间：2020.12.13 患者跌倒不良事件 一、跌倒时间：2014年11月5日14：30 二、地点：内三科9号病房 三、事件发生经过：患者：符莲花，性别：女，年龄：39岁，诊断：低钾血症。 患者因全身乏力3天，于10:00轮椅入科，入科时患者意识呈清醒状态，聋哑病人，入院时生命体征在正常范围内，Bp110/62mmHg p92次/分R 20次/分T36.0℃跌倒评分18分，压疮评分14分，ADL评分55分，予上左边床栏，宣教入院知识和防跌倒，并于床头放防跌倒警示牌，并嘱咐患者家属陪护。 11月5日14:30 时，我（万智伦）在29床病人（林玉磷）床边换针水，听到9号病房传来呼叫声“护士有人跌倒了”，当我和学生媛颖同学跑到病房时，看见患者已经跌掉躺在地板上，同时罗秋红主管护师也来到病房帮忙，我们一起把患者扶到病床上，并叫罗秋红主管护师告知值班的李珍医生查体并电话告知护士长，我便给患者测生命体征，Bp128/62mmHg p 80次/分R 20次/分T36.3℃，全身查体无异常，无外伤。从新给患者评估跌倒评分为28分，压疮评分14分，ADL评分55分，又再次给患者右边上床栏，当时患者家属不在病房，予通过电话联系患者家属回病房后，再次给病号家属宣教，家属表示理解和配合，当时患者血钾浓度1.3mmol/L 遵医嘱予氯化钾缓释片1000mg口服，氯化钾20mL 加温开水一日三次口服，并密切观察病情。 四、根本原因： 针对以上事件分析： 1、对患者家属的安全宣教不到位，未能引起患者和家属对预防跌倒的重视，为患者提 供预防跌倒措施，未得到落实，巡视病房不够，不能及时协助患者。 2、患者低钾血症，是跌倒高危病人，主要与其疾病有关，患者是聋哑病人，沟通困难， 对疾病的缺乏，不愿麻烦护士和家属，本组情况案例为患者独自一人活动时发生。 五、预防措施： 1、护理人员提高安全防范意识，对新入院患者进行全面的评估，对跌倒高风险患者采取针对性的干预措施，向患者和家属详细交代注意事项和预防措施，悬挂“防跌倒”警示牌，做好用药指导，特别是当患者服用镇静、催眠、抗焦虑、抗抑郁、降血压以及任何影响人体平衡的药物时[2]，为站立不稳和步行缓慢的患者提供拐杖或助行器等辅助工具；对安全宣教和预防措施落实效果进行评价和反馈；落实基础护理，加强巡视。 2、护理管理者应加强安全监管，及时发现病区基础设施、环境和日常护理工作中存在的安全隐患，为患者提供安全的住院环境；制定相关护理安全管理制度，定期培训、考核护理人员对安全防范措施的掌握情况；对已发生的不良事件及时分析原因，制定并落实整改措
软件测试案例分析 Document number【980KGB-6898YT-769T8CB-246UT-18GG08】
对软件测试理解 软件测试作为软件质量保证的一种重要方法，近些年来, 软件测试越来越受到产业界、教育界和学术界的重视。软件测试，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 1软件测试的方法 黑盒测试 在黑盒测试(或称功能测试)中，不考虑程序的内部结构和表现，其目的是确定程序的输入与输出是否与其规格一致，力图发现以下几类错误：是否有不正确或遗漏了的功能在接口上，输入能否正确地接受能否正确地输出结果 是否有数据结构错误或外部信息(例如数据文件)访问错误性能上是否能满足要求 是否有初始化或终止性错误 黑盒测试的主要缺点是依赖于规格的正确性(实际情况并非如此)和需要采用所有可能的输入作为测试用例才能保证模块的正确性。 白盒测试 在该方法对软件的过程性细节做细致检查，对程序所有逻辑进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。测试用例从程序的逻辑中产生。确定程序逻辑覆盖有几条原则，其中之一是语句覆盖，要求程序中的每条语句至少执行一次。这条原则是必要的，但不充分，因为部分错误并不能检测出来。
从上至下测试 从上至下测试从程序的顶点模块开始，然后逐步对较低级的模块进行测试。为了模仿被测试模块的低级模块，需要哑模块或桩子模块。从上至下测试的主要好处就是排除了系统测试和集成，它可以让人们看见系统的早期版本并证明系统的正确性。它的效果之一可以提高程序员的士气。从上至下测试的主要缺点是需要桩子模块，并且在桩子模块中的测试数据直到输入输出模块加入之前不能确定。某些模块的测试数据难以创建，因为桩子模块不能模拟数据流使得模块之间的数据流不能组织成有向无环图。 从下至上测试 从下至上测试策略从程序的最低级模块(不调用别的模块)开始。为了模拟高一级的模块需要驱动模块。当对所有的低一级模块测试完毕才对高一级模块进行测试。从下至上测试方法的优点之一是测试数据的建立不存在困难。尽管数据流不在有向无环图中，但驱动模块模拟所有的调用参数，如果关键模块位于调用模块的底部，则从上至下测试方法更优。从下至上测试的主要缺点是系统的早期版本直到最后模块测试完毕才产生，并且设计和测试一个系统不能重叠进行，因为不可在低级模块设计之前进行测试。 测试用例一般描述
目录 1高掉话高分配失败案例 (2) 1.1小区高掉话案例1 (2) 1.2小区高掉话案例2 (2) 1.3小区高掉话案例2 (2) 2信令分析案例 (4) 3区域性掉话案例 (6) 3.1区域性掉话案例1 (6) 3.2区域性掉话案例2 (6) 4切换失败案例 (8) 4.1INTER BSC切换失败高小区检查 (8) 4.2INTRA BSC切换失败高小区检查 (8) 5全网优化案例 (11) 6答案 (13) 6.1高掉话高分配失败案例答案 (13) 6.1.1高掉话高分配失败案例答案1 (13) 6.1.2高掉话高分配失败案例答案2 (13) 6.1.3高掉话高分配失败案例答案2 (13) 6.2信令分析案例答案 (14) 6.3区域性掉话案例分析答案 (14) 6.3.1区域性掉话案例答案1 (14) 6.3.2区域性掉话案例答案2 (14) 6.4切换失败案例答案 (15) 6.4.1INTER BSC切换失败高小区答案 (15) 6.4.2INTRA BSC切换失败高小区检查 (15) 6.5全网优化案例答案 (16)
1高掉话高分配失败案例 1.1小区高掉话案例1 以下是某个小区Abis信令统计数据， 所用频率平均上行 接收电平 平均下行 接收电平 平均上行 接收质量 平均下行 接收质量 平均上行 路径损耗 平均下行 路径损耗 上下行路径 损耗差值 上下行质 量差值 手机平 均发射 功率 基站平 均发射 功率 采样数呼叫 次数 1 -88.84 -73.79 1.0 2 0.32 120.44 112.79 7.65 -0.7 31.61 39 4369 85 91 -85.79 -77.3 3 0.06 0.18 115.7 4 116.33 -0.59 -0.11 29.9 5 34. 6 3023 41 82 -80.64 -76.62 0.15 0.29 106.79 111.59 -4.8 -0.14 26.15 34.9 7 633 19 49 -79.53 -76.71 0.31 1.12 106.46 113.46 -7 -0.81 26.94 36.5 3406 81 TA分布： TA 0 1 2 3 4 5 6 7 百分比11.8% 55.6% 29.4% 0.4% 0.4% 0.0% 0.4% 0.2% 问题1：判断导致该小区高掉话率、TCH高分配失败率的可能原因。 问题2：该小区BCCH是占用哪个频点。 问题3：该小区上下行路径损耗是否正常，路径损耗与哪些因素有关，写出相关的计算公式。 问题4：在空间损耗中，主要损耗原因有哪些？当这些因素扩大一倍，损耗相差几个db? 1.2小区高掉话案例2 现象：某小区的TCH分配失败率及掉话率很高；根据统计报告观察，均为MC736和MC746B掉话和分配失败，且集中在各个TRX上。 问题1：请列出在几种掉话种类及计数器。 问题2：发生此类问题有几种可能。 问题3：碰到此类问题，请列出优化思路及处理方法。 1.3小区高掉话案例2 瓦口1在几个忙时均为坏小区，掉话组成为MC14C，看告警，仅有LOSS-OF-SDCCH，推断为某频点硬件有问题，关跳频、创报告、观察每个频点的占
ATU指标保障信令跟踪 1.提前远程登录到当次所跑网格范围内的所有BSC服务器 以衡阳网格2为例，所需登录的BSC有281，282，283，284，285，286这6台服务器。中兴信令跟踪的命令为： telnet ip地址 gomcr gomcr123 ls cd ums-svr cd tools ls cd zxgomcr-sigtrace ls cd server ls ./server.sh 运行结果如下图： 出现connected则连接成功。
2.登录信令跟踪 用户名、密码不变，服务器地址为所要登录的BSC服务器IP地址，端口号不变。 登陆界面 登录后界面如下： 点击齿轮状图标进入跟踪设置界面，如下图
选择BSC然后更新配置，勾选MS选项进入IMSI号设置界面 添加所要跟踪的ATU主被叫IMSI号，完成设置。 当ATU设备开始测试时，信令会自动刷新，这时要过滤出我们所需要用的6条信令：信道请求，DTAP消息，切换执行，切换命令，清除命令和释放完成。 在出现信令时右键单击选择过滤，如下图。
单击过滤后出现过滤器，选中所需要的信令如下图。
从信道请求，DTAP消息，清除命令，释放完成这四条信令中我们可以看到一次通话的完整过程，若挂机时在DTAP消息中的拆链未出现而直接出现清除命令和释放完成，则是非正常挂机，即掉话。若在DTAP消息中出现连接后直接出现清除命令和释放完成则是未接通。 从切换执行中，我们可以看到每次ms切换时的当前小区和目的小区以及切换理由，如下图 从切换命令中，可看到BSC间的切换，这时就需要切换到另一个BSC进行跟踪。
1.简要场景描述： 被测项目的数据库服务采用ORACLE 10g，测试功能点选择的是一个新建录入保存业务。当并发20用户时，数据库资源占用正常，处理业务响应时间正常，当并发40用户时，数据库服务器CPU占用率突增到100％，系统几乎不响应。 2.对ORACLE 10g进行监控： 2.1首先打开监控开关: exec dbms_monitor.serv_mod_act_trace_enable (service_name=>'
1.1 在eNodeB下进行实时性能监控和测试 在“信令跟踪管理”界面下，还可以进行eNodeB传输性能、小区性能、用户性能和RRU性能的监控和测试。 图 1 eNodeB性能监控和测试功能 1.1.1监控小区性能 小区性能监控功能主要监控项有业务满意率监控、总吞吐量监控、业务数/用户数监控、RB使用情况监控、RSSI统计监控、ICIC监控、虚拟MIMO监控、干扰检测监控等，DBR统计和被调度用户统计。 小区性能监控任务登记，需要设置被监控小区的Local Cell ID，可以设置监控周期和文件保存的路径，文件保存的格式有“csv”和“mmf”两种。 图 2 小区性能监控
常用小区性能监控项有总吞吐量监控、用户数监控、RB使用情况监控和RSSI统计监控。 1.1.2监控扇区性能 扇区监控主要监控上行宽频扫描功能 图 1 扇区监控性能 1.1.3传输监控性能 传输性能监控主要包括IP链路监控、IP PATH性能监控、IP性能监控、SCTP性能监控、UDP 灌包测试监控、本地流过路流监控和资源组监控。 图 2 传输监控性能 1.1.4用户监控性能 用户性能测试功能主要监控项有下行RSRP/RSRQ监控、误码率监控、Power Headroom监控、信道质量监控、调度监控、RLC业务量监控、吞吐量监控、AQM监控、上行功控监控、下行功
控监控、上行ICIC监控和按MCS阶数统计监控。 图 3 用户性能测试 用户性能测试功能任务登记，需要选择被测量的基站（站点数目最多可以选择30个），设置跟踪用户的信息，监控周期和文件保存的路径，文件保存的格式有“csv”和“mmf”两种。 1.1.5R RU监控性能 该任务用于监测RRU输出功率和温度的性能状况，每个RRU最多能启动的监测任务为：●一个输出功率监测任务（注：SPC310之前的版本该项监控不准） ●一个温度监测任务 图 4 RRU监控性能
一例跌倒病人案例分析 时间：2014.7.24 地点：会议室主持人：记录人：参加人员： （护士长）： 昨天晚上我们科室发生了一例患者跌倒事件，患者住院期间发生跌倒是比较常见的不良事件，也是我们需要特别注意的地方，我觉得如何避免患者跌倒是对于护士来讲非常重要的事情，因此今天大家聚集在此一起来讨论患者跌倒的原因，并提出有效的防范措施很有必要。下面让当时的值班护士将患者的基本情况及事情发生的经过向大家汇报一下。（护师）： 患者，男，67岁，系“头晕、头痛一年加重半月伴纳差乏力一周”入院，拟“颈动脉硬化”收住我科。入院后患者给予营养神经、扩血管等支持治疗。患者予7. 23 06：30分洗澡后在卫生间门口发生跌倒，护士听到呼叫后立即奔赴事发地点，协助将患者安置予病房，查看患者神智清楚，无明显外伤存在，测生命体征正常，立即通知医生，告知生命体征情况，协助医生给予患者体格检查，无明显异常。安抚患者情绪，告知安全事项。（护士长）： 将患者的基本病史及事情的发生经过向大家汇报完了，下面大家就该患者跌倒的原因开始讨论，分析可能存在的危险因素，这样能够有效的避免该类时间的发生。（主管护师）： 我来讲一下该患者首先存在的一个护理问题就是躯体移动障碍，大家在平时的工作中也都知道，所以这属于一个高危人群，是我们日常工作中需要重点护理和监护的对象，像该类患者，一定需要我们加强巡视和安全知识的宣教。在思想上，我们也要有安全意识，切记不可掉以轻心。我觉得该患者发生跌倒的原因之
一就是患者的安全告知和护理是欠缺的，需要加强。（护师）： 我同意，我想补充的就是该患者发生跌倒的另一方面是自身的原因，就是患者对自身的评估是欠缺的，该患者自己认为自己可以到卫生间，所以他在入厕的时候没有告知家人也没有通知护士来协助。我不知道该患者是害怕麻烦别人，还是自己相信自己的缘故，总之，他对自己的自身情况的评估是欠缺的。（护士）： 患有糖尿病，此类疾病是易致机体平衡失调的慢性疾病，还有像高血压、糖尿病、脑梗塞后遗症、冠心病等，常常需同时服用多种药物。如降压药，降血糖药，安眠药，镇静药等，特别是镇静催眠药、抗精神病药和麻醉镇痛药，被公认为是跌倒的显著危险因素。因此我认为从患者的疾病因素考虑这也是一个重要的跌倒因素。（护士）： 我从环境因素来考虑，患者发生跌打的原因还包括：患者入住病房后，对环境不熟悉，时有地面潮湿、光滑，光线不足，卫生间、走廊等未加扶手，病床两旁未加床旁栏，床尾摇手柄外露，座椅松动等，这些都是导致患者意外跌倒的因素。其中，因床尾摇手柄使用后未及时归位而导致患者跌倒的情况也是存在的。（护士长）： 大家就该患者发生跌打的原因从几个方面入手分析的很全面，下面就如何预防跌倒现在开始提出你们的意见。（护师）： 我来回答一下，做好患者入院危险因素评估，对于年龄较大、老年女性、心脑血管疾病患者等在入院时护士要做好患者安全评估，从各方面判断是否属于易跌倒高危人群，并标示黄色“防跌倒”醒目标志在床头，以有效提醒护士、患者及陪人提高警惕，预防跌倒。向入院患者介绍病区环境及安全设施，病房规章制
Layer 3信令分析及流程详解汇编Layer 3信令是看网络运行情况的信息层，从第三层可以看到网络的各种动作：如：呼叫流程、拥塞、用户忙、位置更新等，并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型，分别是1、2、3、4、5、6、7、8，Type 1～4只出现在待机状态下，Type 5～6只出现在通话状态下，明白这点，对以后的分析至关重要。其中2中含有：2、2bis、2ter， 5中含有5、5bis、5ter，所以总共有12种系统信息，系统信息1仅用于跳频，所以称为选择项。其中1、2、3、4、 2bis、 2ter 、7、8都在BCCH上发送，由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送，由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完，如下图示： 上图中的TC表示复帧序列号，可以看出，当TC=4、5时，发送的内容是可选的，其它是固定的。 TC=0固定发送跳频信息，当出现上图示的1（3）时，表示跳频时发类型1，不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时，由类型7、8补充。且在TC=7、3时发送（上图示） 对于类型5、6在下行的SACCH上发送，并没有复帧规范，除非切换完成后要立即发送类型5、6。 1、System Information Type1
说明：系统信息类型 1 （频率信息） 此类型仅用于跳频时，发送内容为： 第一、小区信道描述。用于通知移动，小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900： 有一个BIT MAP 0（比特位图）用于描述两方面信息，分别为： CA-NO，取值分别为：0、1、2，代表，GSM900、GSM1800、GSM1900。 CA-ARFCN，采用的有效射频频点，当为GSM900，将有一个相应于124个频点的124位图，当某个频点被采用时，相应的比特位被置为1，否则将被置为0. 对于GSM1800情况点不同。由于频点太多，不用位图，而用别的编码方式，FORMAD-IND=？来描述编码方式，后面跟一串编码比特来表示。 第二、RACH控制参数，描述的两个数据为；ACC、EC，ACC称为接入控制等级，分为0-9与 11-15，0-9表示普通级，所有移动台被定义为0-9，11-15为优先级，10表示EC，如果此位取0，表示所有移动台允许进行紧急呼叫，取1时，只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志，用一个比特表示。
1覆盖类 1.1 概述 覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等。 在TD-LTE中一般认为RSRP<-110dBm，认为是弱覆盖。 越区覆盖：由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远，从而越区覆盖到其他站点覆盖的区域，并且在该区域终端接收到的信号电平较好。 过覆盖：指网络中存在过度的覆盖重叠，容易引起干扰和乒乓切换； 无主导小区：指某一片区域内服务小区和邻区的接收电平相差不大，不同小区之间的下行信号在小区重选门限附近的区域，并且无主导覆盖的区域接收电平一般或者较差，在这种情况下由于网络频率复用的原因，导致服务小区的SINR不稳定，可能发生空闲态主导小区频繁重选、连接态频繁切换，无主导覆盖也可认为是弱覆盖的一种。 导频污染：指在某一点存在过多（一般认为大于等于3个）的强导频，但却没有一个足够强的主导频； 1.2弱覆盖 1.2.1弱覆盖分析 造成弱覆盖的原因有： 1、规划的站点由于种种原因如物业等没有开起来； 2、天线方位角、下倾角不合理，如下倾角过低； 3、在站建起来后，由于新建楼宇的遮挡，导致部分区域RSRP很差； 4、站点过高，如四十多米或更高，会造成塔下黑 5、下倾角、方位角由于条件所限，无法调整，如：美化邓杆站点不方便调整天线的方位角（3个天线方位要一起转，因为外面有罩子盖住下倾角无法调整，如科技园四、海德三路等；深大校园里站点天线都是放在美化罩子（长方体的箱子）里面，对天线的下倾角和方位角调整范围也有影响（如：深大、深大南校等））。 针对以上原因建议的方案有：
1、推动客户将规划站点尽快开起来； 2、调整天线方位角、下倾角到合理位置； 1.2.2天线方位角不合理导致弱覆盖 现象：科技园三的102和104小区由于天线被住宅楼遮挡,导致覆盖区域内部分道路信号较弱,存在弱覆盖，科技园三站点周围的地物如图： 图表 1科技园三周围地物 调整前道路的电平值如下图： 图表 2优化前科技园三覆盖 措施：将104小区的方位角由20度调整为40度；将102的方位角由150度调整到100度；调整后弱覆盖得到改善,如下图：
TD-SCDMA RAN 系统 RNC 信令跟踪分析工具操作手册 1 信令跟踪分析工具操作手册声明 TD-SCDMA RAN 系统 RNC 信令跟踪分析工具操作手册 声明 产品类别:□ TDR2000 ■ TDR3000 □ TDB03C □ TDB09A □ TDB144A □ OMC-R □ 其他 产品版本: 资料版本:V1.0.1 文档编号:DTM4.387.401SM 大唐移动通信设备有限公司为客户提供全方位的技术支持,用户可与当地的大唐移动办事处联系,也可直接与公司总部客服中心联系。 大唐移动通信设备有限公司 地址:北京市海淀区学院路 29号邮编:100083 网址:https://www.doczj.com/doc/3c12711569.html,
客户服务电话:800-990-8800 客户服务邮箱:support@https://www.doczj.com/doc/3c12711569.html, 大唐移动通信设备有限公司 版权所有,保留一切权利。 本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动所有, 受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。 由于产品版本升级或其它原因,本手册内容会不定期进行更新。除非另有约定,本手册仅作为使用指导,本手册中的所有陈述、信息和建议不构成任何明示或暗示的担保。 声明信令跟踪分析工具操作手册 为了我们能更好地为您服务,请填写您对我们资料的意见,并传真至: 010-********大唐移动通信设备有限公司客服中心,或通过邮箱 support@https://www.doczj.com/doc/3c12711569.html,反馈,我们将对好的建议给予奖励。 1. 请您对以下表格中各项进行评价, 并将评价结果填写在相应单元。 (打“ ?”
Layer 3信令分析及流程详解汇编
Layer 3信令是看网络运行情况的信息层，从第三层可以看到网络的各种动作：如：呼叫流程、拥塞、用户忙、位置更新等，并且可以对路测中的各种问题如掉话、切换失败等网络事件的原因进行准确的分析。 系统信息一般有8个类型，分别是1、2、3、4、5、6、7、8，Type 1～4只出现在待机状态下，Type 5～6只出现在通话状态下，明白这点，对以后的分析至关重要。其中2中含有：2、2bis、2ter，5中含有5、5bis、5ter，所以总共有12种系统信息，系统信息1仅用于跳频，所以称为选择项。其中1、2、3、4、2bis、2ter 、7、8都在BCCH上发送，由IDLE模式下的移动台接收。5、5bis、5ter、6在SACCH上发送，由ACTIVE模式下的移动台接收。一般来说所有系统信息在连续的8个51复帧中发送完，如下图示： 上图中的TC表示复帧序列号，可以看出，当TC=4、5时，发送的内容是可选的，其它是固定的。 TC=0固定发送跳频信息，当出现上图示的1（3）时，表示跳频时发类型1，不跳频时发类型3 当类型4中发送的关于小区重选信息不够完整时，由类型7、8补充。且在TC=7、3时发送（上图示） 对于类型5、6在下行的SACCH上发送，并没有复帧规范，除非切换完成后要立即发送类型5、6。 1、System Information Type1
说明：系统信息类型1 （频率信息） 此类型仅用于跳频时，发送内容为： 第一、小区信道描述。用于通知移动，小区采用的频带与可以供跳频用的频点。对于GSM900与GSM1800采用的格式是不同的。对于GSM900： 有一个BIT MAP 0（比特位图）用于描述两方面信息，分别为： CA-NO，取值分别为：0、1、2，代表，GSM900、GSM1800、GSM1900。 CA-ARFCN，采用的有效射频频点，当为GSM900，将有一个相应于124个频点的124位图，当某个频点被采用时，相应的比特位被置为1，否则将被置为0. 对于GSM1800情况点不同。由于频点太多，不用位图，而用别的编码方式，FORMAD-IND=？来描述编码方式，后面跟一串编码比特来表示。 第二、RACH控制参数，描述的两个数据为；ACC、EC，ACC称为接入控制等级，分为0-9与11-15，0-9表示普通级，所有移动台被定义为0-9，11-15为优先级，10表示EC，如果此位取0，表示所有移动台允许进行紧急呼叫，取1时，只有11-15优先级的移动台可以进行紧急呼叫。 CB——小区禁止标志，用一个比特表示。
场景分析法 一、以答题业务为例： 1.答对题目增加题目积分，积分达到设定值时奖励一个礼包； 2.取题规则为随机不重复; 3.答错题目后答新题. 开始答题 是否存在 有效题目 提供题目及备选答案 答案是否 正确 增加题目积分 积分大于或等于设定值？给予无有效题目提示 结束奖励一个礼包
1.确定基本流与备选流 基本流: 步骤1. 开始答题 步骤2. 判断是否存在有效题目，存在有效题目，处理:提供题目及备选答案 步骤3. 用户答题并答对题目，增加用户相应积分。 步骤4. 判断积分是否达到设定值，达到，获取一个礼包，流程结束。 备选流1: 不存在有效题目 基本流步骤2时，题库不存在未答题目，处理：给予无有效题目提示，流程结束。备选流2: 答错题目 基本流步骤3时，答错题目，处理：提示用户答错题目，回到基本流步骤2 备选流3：答题后积分达不到设定值 基本流步骤4时，答对题后积分仍达不到设定值，处理：回到基本流步骤2 2.确定以下用例场景： 3.通过从确定执行用例场景所需的数据元素入手构建矩阵
4.设计数据，把数据填入上面的用例表中 二、下图所示是ATM例子的流程示意图。
2.场景设计：下表所示是生成的场景。 3.用例设计
4.测试用例表
三、用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。 第一步：确定基本流和备选流 基本流：登录在线网站→选择物品→登录账号→付款→生成订单； 备选流1：账户不存在； 备选流2：账户密码错误； 备选流3：用户账户余额不足； 备选流4：用户账户没钱。 第二步：根据基本流和备选流确定场景 场景1成功购物：备选流； 场景2账号不存在：基本流，备选流1； 场景3账号密码错误：基本流，备选流2； 场景4账户余额不足：基本流，备选流3； 场景5账户没钱：基本流，备选流4。 第三步：对每一个场景生成相应的测试用例 测试用例 ID 场景/条件账号密码 用户账 号余额 预期结果 1 场景1：成功购物V V V 成功购物 2 场景2：账号不存在 1 n/a n/a 提示账号不存在 3 场景3：账号密码错误 （账号正确，密码错误）V 1 n/a 提示账号密码错误，返 回基本流步骤3 4 场景4：用户账号余额不 足V V 1 提示用户账号余额不 足，请充值 5 场景5：用户账号没钱V V 1 提示用户账号没有钱， 请充值 第四步：设计测试数据 测试用例ID 场景/条件账号密码 用户账 号余额 预期结果 1 场景1：成功购物Test 123456 800 成功购物，账号余额减少 100元 2 场景2：账号不存在aa n/a n/a 提示账号不存在 3 场景3：账号密码错误 （账号正确，密码错误）Test 111111 n/a 提示账号密码错误，返回 基本流步骤3 4 场景4：用户账号余额不 足Test 123456 50 提示用户账号余额不足， 请充值 5 场景5：用户账号没钱Test 12345 6 0 提示用户账号没有钱，请 充值
LTE核心网常见投诉案例分析 案例一：临时方案用户预换卡不能使用2、3G业务 【故障现象】 临时方案的用户，在更换USIM卡但未开通4G业务的情况下，在4G网络的覆盖下，用4G手机终端可能无法正常使用2,3G业务。只能在4G手机上设置“2,3G only”，才能恢复正常使用。 【故障分析】 临时方案的用户，在更换USIM卡但未开通4G业务的情况下，当前BOSS系统只是将用户的IMSI鉴权信息通过BOSS指令存储到HSS，并未建立IMSI和MSISDN的关联，即未放号为签约用户的任何2、3G的分组域、电路域和4G 业务的签约信息。这种场景下HSS给MME返回 DIAMETER_ERROR_USER_UNKNOWN的错误码，MME收到HSS的DIAMETER_ERROR_USER_UNKNOWN码后，给终端返回#8 “EPS services and non-EPS services not allowed”的NAS原因值。终端收到“EPS services and non-EPS services not allowed”的NAS值后，不再尝试重新选网。【故障解决】 针对这种临时方案的用户，如果只更换USIM卡不签约4G业务，根据测试，MME给终端返回#7 “EPS services not allowed”的NAS值能够使终端较快地重选到2、3G网络。根据协议中定义的映射规则，HSS需要给MME返回DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) with Error Diagnostic of NO_GPRS_DATA_SUBSCRIBED的错误原因值，对应到HSS上，