培训管理华为软件编程规范培训案例和练习

《培训管理华为软件编程规范培训案例和练习》由会员分享，可在线阅读，更多相关《培训管理华为软件编程规范培训案例和练习（81页珍藏版）》请在金锄头文库上搜索。

1、培训管理华为软件编程规范培训 案例和练习 培训管理华为软件编程规范培训 案例和练习 软件编程规范培训 实例与练习实例与练习 第一版 深圳市华为技术有限公司深圳市华为技术有限公司 说明 本文分为两部分， 第一部分为中研 关于规范开发人员设计编码行为、 提高软件质量的通知文件，其中包含来自测试人员总结的大量的包 括逻辑类、接口类、维护类和可测试类四个方面的生动实例，是典型 的软件编程规范培训实例，亦可供我司员工自学；第二部分是一个练 习，作为软件编程规范教学使用。 案例与练习案例与练习 第一部分第一部分 深圳市华为技术有限公司深圳市华为技术有限公司 研发管理办公室文件研发管理办公室文件 关于规范开

2、发人员设计编码行为、提高软件质量的通知关于规范开发人员设计编码行为、提高软件质量的通知 为更有效地贯彻执行软件编码规范总则，强化开发人员规范意识，进一步规 范开发人员的设计、编码习惯（至少“犯过的错误，不能再犯”），为流程下游 部门（如测试部）提供高质量的输出，使下游部门避免低效、重复劳动，特此通 知，请各开发部门遵照执行。 以下问题由测试部的问题单、案例分类汇总而成，将常见设计、编码问题分为四 类：逻辑类、接口类、维护类和可测试性，问题级别为：逻辑类接口类维护类 可测试性。 本通知中罗列问题如再次出现，将进行通报批评并记入干部部关键事件库。 问题分类 逻辑类问题（A 类）指设计、编码中出现的

3、计算正确性和一致性、程序逻辑控 制等方面出现的问题，在系统中起关键作用，将导致软件死机、功能正常实现等 严重问题； 接口类问题（B 类） 指设计、编码中出现的函数和环境、其他函数、全局/局部 变量或数据变量之间的数据/控制传输不匹配的问题，在系统中起重要作用，将 导致模块间配合失效等严重问题； 维护类问题（C 类）指设计、编码中出现的对软件系统的维护方便程度造成影 响的问题，在系统中不起关键作用，但对系统后期维护造成不便或导致维护费用 上升； 可测试性问题（D 类）指设计、编码中因考虑不周而导致后期系统可测试性差 的问题。 处罚办法 问题发生率： P=D/S D=DA+0.5DB+0.25DC

4、 其中： P问题发生率 D1 个季度内错误总数 DA1 个季度内 A 类错误总数 DB1 个季度内 B 类错误总数 DC1 个季度内 C 类错误总数 S1 个季度内收到问题报告单总数 1）当 D3 时，如果 P3，将进行警告处理，并予以公告； 2）当 D5 时，如果 P5，将进行罚款处理，并予以公告。 目录目录 一、逻辑类代码问题一、逻辑类代码问题第 5 页第 5 页 1、变量/指针在使用前就必须初始化1、变量/指针在使用前就必须初始化第 5 页第 5 页 【案例 1.1.1】【案例 1.1.1】第 5 页第 5 页 2、防止指针/数组操作越界2、防止指针/数组操作越界第 5 页第 5 页 【

5、案例 1.2.1】【案例 1.2.1】第 5 页第 5 页 【案例 1.2.2】【案例 1.2.2】第 6 页第 6 页 【案例 1.2.3】【案例 1.2.3】第 7 页第 7 页 【案例 1.2.4】【案例 1.2.4】第 8 页第 8 页 3、避免指针的非法引用3、避免指针的非法引用第 9 页第 9 页 【案例 1.3.1】【案例 1.3.1】第 9 页第 9 页 4、变量类型定义错误4、变量类型定义错误第 10 页第 10 页 【案例 1.4.1】【案例 1.4.1】第 10 页第 10 页 5、正确使用逻辑与 . Get_Config_Table(AMP_CPM_CARD_CONFI

6、G_TABLE, . b_middle_data_ok=generate_trans_middle_data_from_original_data( puc_card_config_tab, Ul_card_config_num) . 其中红色部分巧妙的利用指向指针的指针为指针 puc_card_config_tab 赋值,而 在兰色部分使用该指针。但在 Get_Config_Table 函数中有可能失败返回而不给 该指针赋值。因此，以后使用的可能是一个非法指针。 指针的使用是非常灵活的，同时也存在危险性，必须小心使用。指针使用的危险 性举世共知。在新的编程思想中，指针基本上被禁止使用（JAV

7、A 中就是这样）， 至少也是被限制使用。而在我们交换机的程序中大量使用指针，并且有增无减。 2、防止指针/数组操作越界 【案例 1.2.1】【案例 1.2.1】 1 在香港项目测试中，发现 ISDN 话机拨新业务号码时，若一位一位的拨至 18 位， 不会有问题。但若先拨完号码再成组发送，会导致 MPU 死机。 处理过程： 查错过程很简单，按呼叫处理的过程检查代码，发现某一处的判断有误，本应为 小于 18 的判断，写成了小于等于 18。 结论： 代码编写有误。 思考与启示： 1、极限测试必须注意，测试前应对某项设计的极限做好充分测试规划。 2、测试极限时还要注意多种业务接入点，本例为 ISDN。

8、对于交换机来说，任何 一种业务都要分别在模拟话机、ISDN 话机、V5 话机、多种形式的话务台上做测 试。对于中继的业务，则要充分考虑各种信令：TUP、ISUP、PRA、NO1、V5 等等。 【案例 1.2.2】【案例 1.2.2】 对某交换类进行计费测试，字冠 011 对应 1 号路由、1 号子路由，有 4 个中继群 11,12,13,14(都属于 1#模块)，前后两个群分别构成自环。其中 11,13 群向为出 中继,12,14 群向为入中继，对这四个群分别进行计费设置，对出入中继都计费。 电话 60640001 拨打 01160010001 两次，使四个群都有机会被计费，取话单后浏 览话单

9、发现对 11 群计费计次表话单出中继群号不正确，其它群的计次表中出中 继群号正常。 处理过程： 与开发人员在测试组环境多次重复以上步骤，发现 11 群的计次表话单有时正常， 有时其出中继群号就为一个随机值，发生异常的频率比较高。为什么其它群的话 单正常，唯独 11 群不正常呢？11 群是四个群中最小的群，其中继计次表位于缓 冲区的首位，打完电话后查询内存发现出中继群号在内存中是正确的，取完话单 后再查就不正确了。 结论： 话单池的一个备份指针 Pool_head_1 和中继计次表的头指针重合，影响到第一个 中继计次表的计费。 思考与启示： 随机值的背后往往隐藏着指针问题， 两块内存缓冲区的交界

10、处比较容易出现问题， 在编程时是应该注意的地方。 【案例 1.2.3】【案例 1.2.3】 【正文】 在接入网产品 A 测试中，在内存数据库正常的情况下的各种数据库方面的操作都 是正常的。为了进行数据库异常测试，于是将数据库内容人为地破坏了。发现在 对数据库进行比较操作时，出现程序跑死了现象。 经过跟踪调试发现问题出现在如下一段代码中: 1for(i=0;idbf_count;i+) 2 3pDBFat=(_NM_DBFAT_STRUC*)(NVDB_BASE+DBFAT_OFFSET+i*DBFAT_LEN); 4if(fat_check(pDBFat)!=0) 5 6pSysHead-sy

11、stem_flag=0; 7head_sum(); 8continue; 9 10if(strlen(dbf-dbf_name)!=0 13filesize=pDBFat-dbf_fsize; 14break; 15 16 在测试时发现程序死在循环之中，得到的错误记录是BusError（总线出错）， 由此可以说明出现了内存操作异常。 经过跟踪变量值发现循环变量 i 的阀值 pSysHead-dbf_count 的数值为 0 xFFFFFFFF，该值是从被破坏的内存数据库中获取的，正常情况下该值小于 127。 而 pDBFat 是数据库的起始地址，如果 pSysHead-dbf_count 值异

12、常过大，将导 致 pDBFat 值超过最大内存地址值，随后进行的内存操作将导致内存操作越界错 误，因而在测试过程中数据库破坏后就出现了主机死机的现象。 上面的问题解决起来很容易，只需在第一行代码中增加一个判断条件即可，如下 ： for(i=0;idbf_coun 但由于得到 index 后，没有任何判断，导致若 MNT/MLT 端口没有做半永久，端口 激活后，执行此部分函数，(PortTable+index)-spcNo 有可能为 NULL_WORD，于 是，运算后，pSpcCB 可能为非法值。此时主机在取进行判断，就不知会导致什么 后果了。 其实，改起来很简单，只要在这两句前增加一个判断就行

13、了。于是，修改代码为 ： if(PortTable+index)-spcNo!=NULL_WORD) pSpcCB=SpcCB+(PortTable+index)-spcNo; if(SPC_STATE_OK=pSpcCB-bySpcState) 。 修改后，问题不再重现。 经过分析可以发现， 编译环境是有很大的容许空间的， 若主机没有做充分的保护， 很可能会有极严重的随即故障出现。所以编程时一定要考虑各种可能情况；而测 试中遇到此类死机问题，则要耐心的定位到具体是执行哪句代码时出现的，再进 行分析。因为问题很隐蔽，直接分析海一样的代码是很难发现的。 4、变量类型定义错误 【案例 1.4.1】

14、【案例 1.4.1】 【正文】 在 FRI 板上建几条 FRPVC，其 DLCI 类型分别为：10Bit/2bytes、10bit/3bytes、 16bit/3bytes、17bit/4bytes、23bit/4bytes。相应的 DLCI 值为：16、234、 991、126975、1234567，然后保存，重起 MUX，观察 PVC 的恢复情况，结果 DLCI 值为 16、234 和 991 的 PVC 正确恢复，而 DLCI=126975 的 PVC 恢复的数据错误为 61439，而 DLCI=1234567 的 PVC 完全没有恢复。 对于 17/4 类型，DLCI=126975 的

15、 PVC 在恢复时变成 61439，根据这条线索，查找 原因，发现 126975-61439=65535，转化二进制就是 10000000000000000，也就是 说在数据恢复或保存时把原数据的第一个 1 给忽略了。此时第一个想法是：在程 序处理中，把无符号长整型变量当作短整型变量处理了，为了证实这个判断，针 对 17bit/4bytes 类型又重新设计测试用例：（1）先建 PVC，DLCI=65535，然后 保存，重起 MUX，观察 PVC 的恢复情况，发现 PVC 能够正确恢复； （2）再建 PVC，DLCI=65536，然后保存，重起 MUX，观察 PVC 的恢复情况，此时 PVC 不

16、能正确恢复。 至此基本可以断定原因就是出在这里。带着这个目的查看原代码，发现在以下代 码中有问题： int_GetFrDlci(DWORD*dwDlci,char*str,DWORDdwDlciType,DWORDdwPortType,D WORDdwSlotID,DWORDdwPortID) DWORDtempDlci; charszArg80; 1charszLine80; IDLowPVCEP; DWORDdwDlciVal52= 16,1007,16,1007,1024,64511, 2048,129023,131072,4194303; typedefstructtagFrPppIntIWF WORDwHdlcPort; WORDwHdlcDlci; WORDwPeerHdlcDlci; WORDwPeerOldAtmPort; SFrPppIntIWFData; DWORDSaveFrNetIntIWFData(DWORD*pdwWritePoint) BYTEbSlotID,bPeerSlo