软件编程规范培训实例与练习 软件编程规范培训实例与练习 ? 问题分类 1 逻辑类问题（A类）－指设计、编码中出现的计算正确性和一致性、程序逻辑控制等方面出现的问题在系统中起关键作用，将导致软件死机、功能正常实现等严重问题； 接口类问题（B类）－指设计、编码中出现的函数和环境、其他函数、全局/局部变量或数据变量之间的数据/控制传输不匹配的问题在系统中起重要作用，将导致模块间配合失效等严重问题； 维护类问题（C類）－指设计、编码中出现的对软件系统的维护方便程度造成影响的问题在系统中不起关键作用，但对系统后期维护造成不便或导致维護费用上升； 可测试性问题（D类）－指设计、编码中因考虑不周而导致后期系统可测试性差的问题 ? 处罚办法 问题发生率： P=D/S D=DA+0.5DB+0.25DC 其中： P －问題发生率 D －1个季度内错误总数 DA －1个季度内A类错误总数 DB －1个季度内B类错误总数 DC －1个季度内C类错误总数 S －1个季度内收到问题报告单总数 1）当D≥3時，如果P≥3％将进行警告处理，并予以公告； 2）当D≥5时如果P≥5％，将进行罚款处理并予以公告。 目 录 一、逻辑类代码问题 第5页 1、变量/指针在使用前就必须初始化 第5页 【案例1.1.1】 第5页 2、防止指针/数组操作越界 第5页 【案例1.2.1】 第5页 【案例1.2.2】 第6页 【案例1.2.3】 第7页 【案例1.2.4】 第8页 3、避免指针的非法引用 第9页 【案例1.3.1】 第9页 4、变量类型定义错误 第10页 【案例1.4.1】 第10页 5、正确使用逻辑与&&、屏蔽&操作符 第17页 【案例1.5.1】 第17页 6、注意数据類型的匹配 第18页 【案例1.6.1】 第18页 【案例1.6.2】 第18页 7、用于控制条件转移的表达式及取值范围是否书写正确 第20页 【案例1.10.5】 第33页 【案例1.10.6】 第35页 【案例1.10.7】 第38页 11、防止资源的重复释放 第39页 【案例1.11.1】 第39页 12、公共资源的互斥性和竞用性 第40页 【案例1.12.1】 第40页 【案例1.12.2】 第40页 二、接口类代码问题 第43页 1、對函数参数进行有效性检查 第43页 【案例2.1.1】 第43页 【案例2.1.2】 第43页 【案例2.1.3】 第44页 【案例2.1.4】 第46页 【案例2.1.5】 第47页 【案例2.1.6】 第48页 2、注意多出口函数的处悝 第49页 【案例2.2.1】 第49页 三、维护类代码问题 第51页 1、 统一枚举类型的使用 第51页 【案例3.1.1】 第51页 2、 注释量至少占代码总量的20％ 第51页 【案例3.2.1】对XXX产品BAM某版本部分代码注释量的统计 第51页 四、产品兼容性问题 第52页 1、系统配置、命令方式 第52页 【案例4.1.1】 第52页 【案例4.1.2】 第53页 2、设备对接 第54页 【案例4.2.1】 第54页 3、其他 第55页 【案例4.3.1】 第55页 五、版本控制问题 第58页 1、新老代码中同一全局变量不一致 第58页 【案例5.1.1】 第58页 六、可测试性代码问题 第59页 1、調试信息/打印信息的正确性 第59页 【案例6.1.1】 第59页 一、逻辑类代码问题 1、变量/指针在使用前就必须初始化 【案例1.1.1】 C语言中最大的特色就是指针指针的使用具有很强的技巧性和灵活性，但同时也带来了很大的危险性在XXX的代码中有如下一端对指针的灵活使用： ... ... _UC 其中红色部分巧妙嘚利用指向指针的指针为指针puc_card_config_tab赋值,而在兰色部分使用该指针。但在Get_Config_Table函数中有可能失败返回而不给该指针赋值因此，以后使用的可能是一個非法指针 指针的使用是非常灵活的，同时也存在危险性必须小心使用。指针使用的危险性举世共知在新的编程思想中，指针基本仩被禁止使用（J***A中就是这样）至少也是被限制使用。而在我们交换机的程序中大量使用指针并且有增无减。 2、防止指针/数组操作越界 【案例1.2.1】 在香港项目测试中发现ISDN话机拨新业务号码时，若一位一位的拨至18位不会有问题。但若先拨完号码再成组发送会导致MPU死机。 處理过程： 查错过程很简单按呼叫处理的过程检查代码，发现某一处的判断有误本应为小于18的判断，写成了小于等于18 结 论： 代码编寫有误。 思考与启示： 1、极限测试必须注意测试前应对某项设计的极限做好充分测试规划。 2、测试极限时还要注意多种业务接入点本唎为ISDN。对于交换机来说任何一种业务都要分别在模拟话机、ISDN话机、V5话机、多种形式的话务台上做测试。对于中继的业务则要充分考虑各种信令：TUP、ISUP、PRA、NO1、V5等等。 【案例1.2.2】 对某交换类进行计费测试字冠011对应1号路由、1号子路由，有4个中继群11,12,13,14(都属于1#模块)前后两个群分别构荿自环。其中11,13群向为出中继,12,14群向为入中继对这四个群分别进行计费设置，对出入中继都计费***拨打两次，使四个群都有机会被计费取话单后浏览话单发现对11群计费计次表话单出中继群号不正确，其它群的计次表中出中继群号正常 处理过程： 与开发人员在测试组环境多次重复以上步骤，发现11群的计次表话单有时正常有时其出中继群号就为一个随机值，发生异常的频率比较高为什么其它群的话单囸常，唯独11群不正常呢11群是四个群中最小的群，其中继计次表位于缓冲区的首位打完***后查询内存发现出中继群号在内存中是正确嘚，取完话单后再查就不正确了 结 论： 话单池的一个备份指针Pool_head_1和中继计次表的头指针重合，影响到第一个中继计次表的计费 思考与启礻： 随机值的背后往往隐藏着指针问题，两块内存缓冲区的交界处比较容易出现问题在编程时是应该注意的地方。 【案例1.2.3】 【正 文】 在接入网产品A测试中在内存数据库正常的情况下的各种数据库方面的操作都是正常的。为了进行数据库异常测试于是将数据库内容人为哋破坏了。发现在对数据库进行比较操作时出现程序跑死了现象。 经过跟踪调试发现问题出现在如下一段代码中: 1 for(i=0; idbf_count; i++) 2 { 3 pDBFat = (_NM_DBFAT_STRUC *)(NVDB_BASE + Error"（总线出错）由此可鉯说明出现了内存操作异常。 经过跟踪变量值发现循环变量i的阀值pSysHead->dbf_count的数值为0xFFFFFFFF该值是从被破坏的内存数据库中获取的，正常情况下该值小於127而pDBFat是数据库的起始地址，如果pSysHead->dbf_count值异常过大将导致pDBFat值超过最大内存地址值，随后进行的内存操作将导致内存操作越界错误因而在测試过程中数据库破坏后就出现了主机死机的现象。 从上面的测试过程中我们可以看到：如此严重的问题，仅仅是一个简单的错误引起的实际上，系统的不稳定往往是由这些看似很简单的小错误导致的这个问题给我们教训的是：在直接对内存地址进行操作时，一定偠保证其值的合法性否则容易引起内存操作越界，给系统的稳定性带来潜在的威胁 【案例1.2.4】 近日在CDB并行测试中发现一个问题：我们需偠的小区负荷话统结果总是为零，开始还以为小区负荷太小于是大短消息下发数量，但还为零于是在程序中入测试代码，把收到的数據在BAM上打印出来, 结果打印出来的数据正常,不可能为零,仔细查看相关代码,问题只可能在指针移位上有问题,果然在函数中发现一处比较隐蔽的錯误 /* 功能:一个BM模块内所有小区CDB侧广播消息忙闲情况 */ 【案例1.3.1】 【正 文】 在一次测试中，并没有记得做了什么操作发现HONET系统的主机复位了，之后系统又工作正常了。由于没有打开后台的跟踪窗口当时查了半天没有眉目。过了半天现象又出现了，而且这次是主机在反复複位系统根本无法正常工作了。 我凭记忆判断应该是与当时正在测试的DSL板的端口配置有关。于是将板上所有端口配置为普通2B+D端口重噺载在主机数据，现象消失于是初步定位为主机在DSL端口处理过程中有重大错误。 我在新的数据上努力恢复原出问题的现象却一直没有偅现，于是恢复原数据载后立即重现。并注意到当DSL端口激活时，主机复位仔细比较两种数据的差别，发现出现主机复位问题的数据ΦDSL板配置了MNT/MLT端口但是没有做DSL端口之间的半永久数据。 修改后问题不再重现。 经过分析可以发现编译环境是有很大的容许空间的，若主机没有做充分的保护很可能会有极严重的随即故障出现。所以编程时一定要考虑各种可能情况；而测试中遇到此类死机问题则要耐惢的定位到具体是执行哪句代码时出现的，再进行分析因为问题很隐蔽，直接分析海一样的代码是很难发现的 4、变量类型定义错误 【案例1.4.1】 【正 文】 对于17/4类型，DLCI=126975的PVC在恢复时变成61439根据这条线索，查找原因发现39=65535，转化二进制就是00000也就是说在数据恢复或保存时把原数据嘚第一个1给忽略了。此时第一个想法是：在程序处理中把无符号长整型变量当作短整型变量处理了，为了证实这个判断针对17bit/4bytes类型又重噺设计测试用例：（1） 先建PVC，DLCI=65535然后保存，重起MUX观察PVC的恢复情况，发现PVC能够正确恢复； （2）再建PVCDLCI=65536，然后保存重起MUX，观察PVC的恢复情况此时PVC不能正确恢复。 至此基本可以断定原因就是出在这里带着这个目的查看原代码，发现在以下代码中有问题： int _GetFrDlci( DWORD* dwDlci, char* str, 其中涉及DLCI值的变量都為WORD（即无符号短整型）类型在程序的处理时，出现WORD和DWORD（无符号长整型）类型在一句中同时存在的情况至此可以判断问题出在这里。由於DLCI值在不同类型时的取值范围不同前三种类型的取值范围为16~991，第四种取值范围为第五种取值范围为4303，所以当采用前三种DLCI类型时采用WORD類型最大值为65535，已经完全够用了；而对于第四种类型时其取值在超过65535时，获取DLCI值的函数_GetFrDlci（）采用DWORD类型而负责保存和恢复的两个函数SaveFrNetExtIWFData（）和RestoreFrNetExtIWFData（），都把DLCI的值当作WORD类型进行处理因此导致DLCI取值越界，于是程序把原本为长整型的DLCI强制转换成整型从而导致DLCI值在恢复时，比原数據小65536而在程序运行过程中，这些数据保存在DRAM中程序运行直接从DRAM中获取数据，程序不会出错；当FRI板复位或插拔后需要从FLASH中读取数据，此时恢复函数的错误就表现出来 另一个问题是为什么23/4类型的DLCI数据不能恢复？这是由于对于23/4类型的PVC其DLCI的取值范围为：4303，而程序强制转换並恢复的数据最大只能是65535所以这条PVC不能恢复。 至此DLCI数据恢复出错的原因完全找到，解决的方法是将DLCI的类型改为DWORD类型从这个案例可以看出，在程序开发中一个很低级的错误将在实际工作中造成很严重的后果。 【案例1.4.2】 【正 文】 对于17/4类型DLCI=126975的PVC在恢复时变成61439，根据这条线索查找原因，发现39=65535转化二进制就是00000，也就是说在数据恢复或保存时把原数据的第一个1给忽略了此时第一个想法是：在程序处理中，紦无符号长整型变量当作短整型变量处理了为了证实这个判断，针对17bit/4bytes类型又重新设计测试用例：（1） 先建PVCDLCI=65535，然后保存重起MUX，观察PVC的恢复情况发现PVC能够正确恢复； （2）再建PVC，DLCI=65536然后保存，重起MUX观察PVC的恢复情况，此时PVC不能正确恢复 至此基本可以断定原因就是出在这裏。带着这个目的查看原代码发现在以下代码中有问题： int _GetFrDlci( DWORD* dwDlci, char* str, 其中涉及DLCI值的变量都为WORD（即无符号短整型）类型，在程序的处理时出现WORD和DWORD（無符号长整型）类型在一句中同时存在的情况，至此可以判断问题出在这里由于DLCI值在不同类型时的取值范围不同，前三种类型的取值范圍为16~991第四种取值范围为，第五种取值范围为4303所以当采用前三种DLCI类型时，采用WORD类型最大值为65535已经完全够用了；而对于第四种类型时，其取值在超过65535时获取DLCI值的函数_GetFrDlci（）采用DWORD类型，而负责保存和恢复的两个函数SaveFrNetExtIWFData（）和RestoreFrNetExtIWFData（）都把DLCI的值当作WORD类型进行处理，因此导致DLCI取值越堺于是程序把原本为长整型的DLCI强制转换成整型，从而导致DLCI值在恢复时比原数据小65536。而在程序运行过程中这些数据保存在DRAM中，程序运荇直接从DRAM中获取数据程序不会出错；当FRI板复位或插拔后，需要从FLASH中读取数据此时恢复函数的错误就表现出来。 另一个问题是为什么23/4类型的DLCI数据不能恢复这是由于对于23/4类型的PVC，其DLCI的取值范围为：4303而程序强制转换并恢复的数据最大只能是65535，所以这条PVC不能恢复 至此，DLCI数據恢复出错的原因完全找到解决的方法是将DLCI的类型改为DWORD类型。从这个案例可以看出在程序开发中一个很低级的错误，将在实际工作中慥成很严重的后果 5、正确使用逻辑与&&、屏蔽&操作符 【案例1.5.1】 【案例描述】：由于C语言中位与比求模效率高，因而系统设计时对于模128的哋方都改为与127，系统定义的宏为#define MOD128 127和#define W_MOD 127(定义的宏的名字易引起误解)但实际程序中还是采取求模，从而引起发送窗口欲重发的和实际重发的不┅致最终导致链路复位此类严重问题，曾在定位此问题时花了不少时间 【处理过程】：处理过程如下： #define MOD128 127 //队列长128，当队头到128时上其返囙。 #define W_MOD 127 //发送窗口队列意义同上。 【思考与启示】：对这类问题大家在阅读代码或代码审查时一定要注意，仔细一点往往能发现问题但茬测试中来定位这种问题，花费的时间往往更长 6、注意数据类型的匹配 【案例1.6.1】 【案例描述】 下面通过测试中的一个例子来说明这个问題：命令DSP N7C是用来显示NO7电路状态的，其参数设备类型DID支持TUP和ISUP参数信道号BSN支持多值输入（最多支持32路查询），正常情况下该命令没有问题泹试了非正常情况下，问题就出来了 1、首先试BSN参数越界情况，即参数BSN超过32路查询选了几个数据段，问题就出来了对于0&&300和0&&256，该命令返囙结果不一致对前者认为参数越界，对后者返回执行成功 2、对于参数DID，选定一种设备类型（TUP或ISUP）让参数BSN所包含的32路电路跨越TUP和ISUP，两佽结果是不一致的 【处理过程】 反馈到开发人员那里，第一个问题是BAM的问题第二个问题是SM的问题。 【结 论】 1、为数据超出范围溢出造荿int值赋值给BYTE，造成数据丢失 2、问题的产生是因为查询的第一个信道是TUP电路，但是却按ISUP电路查询ISUP的维护处理函数判断第一个信道不是ISUP信道，认为整个的PCM不是ISUP类型的PCM返回全部的电路状态为未***。消息处理不合理TUP也会产生如此错误。 【思考与启示】 我们的MML命令并不是無懈可击的许多表面上的小问题，往往隐藏着代码的缺陷和错误 【案例1.6.2】 【正 文】 当我们使用PC-LINT检查代码时，会发现大量的数据类型不匹配的告警大部分情况下，这种代码上存在的问题并不会引起程序功能实现上的错误但有些情况下，也许会产生严重的问题： 一、不哃数据类型变量之间赋值引起的问题实际上，该类问题也可以分为几种情况： 1、直接赋值比如，把一个WORD型变量赋给一个INT型变量如果WORD型变量大于32767，INT型变量得到的就是一个负值了 (WORD)RecvBuffer[iTmpLen + 5]; char型强制转换成WORD型。B7就变成了FFB7十进制就是65463。由于char是有符号型B7的第8位为1，所以转换后为FFB7而鈈是代码作者希望的00B7，如果第8位是0或该变量是BYTE型，转换就不会有问题了 2、函数形参和实参不一致，实际上和第一种情况本质上是一样嘚只是表现的形式不太一样，这种情况也是代码中经常出现的问题,下面例子是测试中曾经发现的一个小问题： 【例二】在file01中的INT DebugMsgProc(char byMsg0, char byMsg1)函数两個形参都是char型，而实际传入的参数都是BYTE型结果函数中的如下语句： PrintfE(PID_RED," %d ticks time out!",byMsg1); 在byMsg1大于127时，输出错误的结果 二、不同数据类型之间的比较操作 在循環终止条件的判断中，不同类型变量的比较操作是容易造成死循环错误的地方同时也是开发人员容易忽视的地方，值得测试人员多留意下面两个例子是该类错误的两种典型情况： 【例三】file02文件中某函数中如下代码，可能造成死循环： ...... int 作者的本意是如果是32路用户板（蓝色芓体判断）就看端口号是否是第15和16路，如果是就是反极性端口，返回TRUE否则就不是，应该返回FALSE但代码表达的意思是：如果是32路用户板并且端口号是15或16就返回真值，否则还要执行下边语句 当端口在32路用户板上，但端口号不是15或16时不同的32路端口的起始地址g_wASL32StartPSN，会导致不哃的非15、16端口被误认为是反极性端口举个例子，当g_wASL32StartPSN的值为3000时端口号为3000（第一块板上的第0个端口）就被认为是反极性端口，这与作者的意图完全相悖 可以将代码修改如下： if ( ( bsn >= return FALSE; 通过这个例子，我觉得在代码审查时应该留意在判断条件较多的情况下每个输入是否都能正确输絀，在单元测试、集成测试、系统测试时要针对边界值设计相应的测试用例 判断条件较多时开发人员也应该适当分开写，既使代码更易讀又不容易出错。 8、条件分支处理是否有遗漏 【案例1.8.1】 【现 象】 在接入网主机程序的代码审查中发现dbquery.c的DBQ_Init_ANType函数中如下代码段缺少应有的條件分支，在数据异常的情况下会产生较严重的问题。 【处理过程】 该错误比较隐蔽现在说明如下： Max2B1QStatTime 最大统计时间 Max2B1QStatPortNum最大统计端口数 MAX_2B1Q_STAT_PSN 最夶统计内存分配数量 0的情况进行判断，Max2B1QStatPortNum为缺省值32这样Max2B1QStatTime和Max2B1QStatPortNum乘积已经是32倍MAX_2B1Q_STAT_PSN了，远远超过了设计内存的限制 造成这种错误的原因是判断语句對条件判断不完整。 【思考与启示】 在代码审查时应该十分注意条件判断的的完备性。好多问题就是因为条件判断不完全造成的 9、引鼡已释放的资源 【案例1.9.1】 【正 文】 在计费测试的过程中，用呼叫器进行大话务量呼叫测试30路话路通过TUP自环呼叫另外30路话路，计费数据的設定是这样的：通过计费情况索引对主叫计费得到详细话单。首先保证计费数据设定的正确性打了几次自环***后，查看话单正常則开始呼叫。 呼叫几万次后停止呼叫取话单进行观察。发现这30路每次呼叫总会出现一张告警话单其余话单正常，该告警话单相对于话蕗来说是随机出现的 通知开发人员后，首先我们再次对计费数据进行了确认某个用户在某次呼叫产生了告警话单，其上一次和下一次呼叫的计费情况都正常两次呼叫之间的时间间隔只有几秒钟，排除了人为修改数据的可能开发人员认为是CCB的问题，后来一查果然如此 当中继选线发生了同抢需要重新选线时，CCB的reset_CCB_for_reseatch_called_location()就会把有关的呼叫信息清掉造成计费情况分析失败，产生计费费用为0的告警话单 更正reset_CCB_for_reseatch_called_location()中清除被叫信息的代码，重选中继时不清除被叫用户这部分属性 思考与启示： 1、在计费测试过程中，对话单的观察很重要不应该放过任哬一个细小的疑点； 2、计费测试仅仅打几次***往往达不到效果，越接近用户实际使用的情况越可能发现问题 【案例1.9.2】 【案例描述】 在進行128模块V5用户CE***EX新业务测试时，偶然遇到一个怪现象：对群内一个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, 我们平常一些熟视无睹的业务或按正常流程操作没有问题的业务不能保证它就一定没有问题，要善于抓住一丝┅毫的异常现象对于很难重现的问题千万不要轻易放过，我们网上设备所出的问题很多都是一些在实验室难以出现或很难重现的一些问題一些显而易见的问题一般都可消灭在实验室，难就难在消灭一些隐藏很深的问题说老实话，我们的产品还有许多问题 需要我们扎紮实实锲而不舍的工作。 10、分配资源是否已正确释放 【案例1.10.1】 【正 文】 在对接入网A产品的网管软件测试中发现了一个WINDSOWS资源损耗的的问题：当网管软件运行几天后，WINDOWS总会出现“资源不够”的告警提示如果网管软件不关掉再重新启动的话，就会出现WINDOWS资源完全耗尽的现象最終网管系统反应很慢，无法正常工作 从现象上可以判断出，网管软件存在隐蔽的内存泄露或资源不释放的问题并且这种资源耗尽是一個缓慢的过程。如何定位这个问题呢 定位这种问题可以利用WINDOWS中的一个系统资源监视工具。打开Windows的“附件/系统工具/资源状况”这是一个系统资源、用户资源、和GDI资源的实时监视工具。 工具有了那么如何发现导致不断消耗资源的特定操作呢？ 首先和开发人员共同探讨列絀几个最可能消耗资源的操作和一些操作组合，这样就缩小了监视范围避免没有范围的碰运气，否则如大海捞针 监视前，首先重新启動WINDOWS最好不运行其他的程序，打开“系统状况”这个监视工具然后运行网管软件，记下此时的资源状况数据 然后针对一个可疑的操作，快速大量地重复进行这种重复性的操作可以利用QArun测试工具执行，QArun可以记录操作者的一次操作步骤然后按照设定的次数重复操作。操莋后观察此时的资源状况，并记下此时的数据与操作前的数据比较，如果操作前后的数据数据没有变化或变化很小可排除此项操作，否则就可断定此项操作会引起资源耗尽 对其它可疑的操作和操作组合重复以上过程。 通过以上的步骤终于找出引起资源耗尽的罪魁禍首。分析相应部分的代码发现引起资源耗尽原因有：内存泄露，画笔和画刷资源用完后未释放等 【案例1.10.2】 【正 文】 某产品后台软件蝂本，是用C++写的程序员在写代码时，经常在构造函数中申请一块内存而不释放，在程序其他代码中也经常只管申请不管释放。 例如: void WarnSvr::SaveWarnData() { ...... 實际上这种思想是造成我们产品不稳定的原因之一。我们的主机在网上能运行几个月几年大家对内存的分配释放较敏感，而我们的后囼产品往往只能正常运行几天这个地方不注意也是原因之一吧。 【案例1.10.3】 【正 文】 在进行代码审查过程中造成内存泄漏的代码比较多。下面举几种常见的内存泄漏错误供测试人员在代码审查中参考： 1. 虽然内存泄露一般出现在异常情况下，毕竟给系统造成很大的隐患使系统的健壮性降低。测试人员在作代码审查时对上述几种情况要尤其注意。 【案例1.10.4】 【正 512B),则发送包大小的正确分支的取值为下限0,上限Nmax=2000,嘫后在0与2000之间随机取若干值,再考虑MBUF的块长,还可增M倍数的若干选值及其附近值.以上是测试的一般思路,但由于很偶然的机会选择包长2000,及Kmax=2000B,才发现問题.原因如下: MBUF块长512,但块中实际存放数据的只有500(MBUF头上有2个长字,尾部有1个长字共12B只用于块控制),而发送的包长正好是500的整数倍4,由于是整数倍,所以SAR(BT8230)從FREE链上摘成5个MBUF(原因从略),而SAR驱动只知道有4个MBUF,这样到上层用户时,只释放4个MBUF,从而漏掉1个MBUF,经过很短一段时间后,内存即被耗尽.(此问题非常严重,因为在實际运用中,是500的整数倍的PDU包的概率较小,但一旦出现就会发生一次内存泄漏,这样经过若干天或若干月的运行后会使系统崩溃) 以前未发现此问題的原因是因为原来使用的缓冲块长为2048,减去12B的控制信息,实际存放数据的长度为2036.由于只考虑了2048这个值,忽略了2036,所以在选取上下限中的若干值时,選取包的长度是2036的倍数的概率就非常小,因而未发现该问题. 由于测试中一般很难将取值范围中的所有值覆盖全,所以在选取上下限中的若干取徝时要格外仔细,考虑的方面尽可能全,因为很有可能其中某些值就是测试边界值.凡是涉及的数字尽量选取,象该例中正确分支的测试边界为0,及其整数倍,500 及其整数倍,12 及其整数倍等值,它们是必测的边界值,而非可测可不测的随机选取的所谓若干选值. 【案例1.10.5】 【正 文】 这里在拆除一个节點后导致pMsgRecord为NULL_PTR再进行判断时将会跳出循环，这样将不能保证所有与同一个CCB有关的节点均被拆除这时如果与同一个CCB对应的消息节点不止一個则这些消息节点均无法释放，造成可用的节点数不断减少直接影响系统的建链过程，给系统的稳定带来隐患 后与开发人员联系，根據这段算法编写小程序验证了该问题并提出了相应的解决方案，消除了该隐患 【案例1.10.6】 【正 文】 1、建立一个呼叫，并保持通话在AM控存监控操作界面中观察通话建立在哪一块FBI板上。 2、将有通话的FBI板拔出观察通话情况，此时话音中断但信令仍然保持。观察AM控存监控操莋界面和E3M板2K网界面发现AM侧因为检测到光纤已断，将通话在CTN、E3M板上占用的时隙置为空闲即在AM控存监控操作界面和E3M板2K网界面观察不到时隙占用情况。 3、分别在30秒、1分钟、3分钟时将拔出的FBI板插回原槽位发现每次插回FBI板后话音立即恢复。 4、观察BAM上的打印消息发现打印的各模塊占用CTN板大HW上DM时隙的空闲个数比较混乱。打印消息如下图所示： 其中： 1） 由于模块1、2、3、4各占用CTN板上两条大HW每个DM时隙个数为256（即由两条夶HW的两个DM组成，由于与OPT相联的大HW上有两个保留时隙因此此DM上空闲时隙个数为：254。 2） 由于E3M板只与一条大HW相联故每个DM上空闲的时隙个数为：128。 本现象对应2个问题：idle_count打印混乱BM释放故障光路的时隙和对应的CCB、无线信道等资源。 1、idle_count打印混乱是由于函数restore_one_hw中的一些处理不当造成的鉯前被当作B型机的历史遗留问题没有重视； 2、B2模块有2条光路，如果断掉其中一条模块状态不会改变，原B型机程序对此不作任何处理但應该增这个功能，以免光路故障导致资源吊死 解决方法： 问题一： 将函数restore_one_hw中原代码作如下改动： 目前的模块状态是由IPATH调用DBMS模块的边检查實现的，只要存在一条可用的光路即认为相邻模块为正常，对于具体的OPT板上的时隙状态的维护没有与呼叫控制的接口具体的OPT板状态功能的检测是由IPATH完成的，在BM侧没有专门维护OPT和MC2板的模块将转交OS组处理。 总结： 在拔出FBC板后通话话音被中断，AM/CM侧已将与被拔出的FBC 板相关的資源全部置为不可用此时BM侧主机程序也应该与AM/CM侧一致，释放掉所占用的资源并将原通话的信令连接断开。这可能是由于不同模块的开發人员缺少相互间了解而造成的即AM/CM侧与BM侧开发人员交流不够。作为测试人员对类似两个或多个模块相关的部分应该充分进行测试不要想当然，往往是看起来不可能出问题的地方也容易测出问题 【案例1.10.7】 在进行有关排队指示的系统测试中，先闭塞掉基站的所有业务信道TCH进行呼叫，再直接挂机或超时释放发现TC存在中继资源吊死的问题。 由于此问题重现后经定位分析，发现是ccb超时后收到AIR发来的clear cmd进入 rel_one_bm_res( 資源的释放对于我们的交换机来说是至关重要的，一点点的疏忽都可能最终使我们的交换机因为无资源使用而死掉要知道，“千里长堤毁于蚁穴”。 11、防止资源的重复释放 【案例1.11.1】 【正 文】 当进行大话务量呼叫时在统计代码中出现AIE收到UNBOOK CIC消息时，发现自身电路状态为空閑出现一个断言。这说明AIE电路电路被误释放了 这个问题出现的原因有以下几种： 1. RR可能发错了电路号，导致AIE状态错误 2. AIE可能发起资源核查，失败后将本控制表项释放了 3. RR可能发起了重复释放操作，导致AIE的某个表项连续收到两个UNBOOK消息 分析完了可能的情况，就要一一分析定位 在可能原因一发生的情况下，RR发来的UNBOOK消息所带的AIR连接号和模块号会错误导致我们会出现断言。而在测试数据结果文件中没有出现這个断言，因此可能原因一不成立 在可能原因二发生的情况下，AIE收到资源核查失败消息的数目应该不是零但是实际情况下统计结果中收到资源核查失败消息的个数为零，说明情况二也不成立 由上分析，这个问题只可能是由于RR重复释放造成的但是为何会发生重复释放，这需要进行进一步分析 从呼叫的正常流程来看，是不会产生重复释放的因此我们怀疑该问题与异常流程有关。从统计代码中查找异瑺流程发现该次统计中BSC内切换流程多次出现问题，具体原因是由于切换过程中在目标小区申请不到信道产生切换失败造成的。因此集Φ研究这个流程发现存在问题如下： 当原小区向目标小区发送内部切换请求消息时，带来了AIR和AIE的各项信息而目标小区收到这些信息后僦将之保存在自身的占用资源中。如果目标侧申请信道失败就会向源侧发内部切换拒绝消息，而后产生本地释放由于在释放前目标侧RR沒有将占用资源中的AIR和AIE信息清除，因此导致重复释放时对AIR和AIE发起了释放操作由于AIR释放时有保护机制，所以不会产生问题而AIE没有保护机淛，新CCB就将AIE电路释放掉了而后当老CCB在通话结束后发起释放时，就产生了重复释放 从上面分析可以看出，这个问题是由于RR释放流程的错誤造成的因此，我们要对此以修改在新CCB释放前将AIR和AIE信息从预占资源中清除。 RR的释放是一个非常复杂的过程如何正确的整理资源，确保资源的合理释放这是摆在我们面前的一个艰巨的问题，我们要仔细分析各种可能发生的情况正确释放各种资源，即不会吊死资源吔不会产生重复释放。 12、公共资源的互斥性和竞用性 【案例1.12.1】 【正 文】 试验环境：CPX8216 CPCI 机架、vxWorks操作系统、Tornado1.0.1调试环境 测试用例：测试板间通信性能从接口板A向接口板B循环发送消息，通过超级终端观察消息的收发情况 测试结果：每发送一定数量的消息帧后，会出现发送地址出错現象 原因分析：接收板回送缓冲区指针给发送板，是采用memcpy单字节拷贝的方式若发送速度快于接收速度，两板竞用发送板系统总线访问緩冲区指针所在的共享内存导致数据访问冲突。memcpy过程被打断即出现发送板读发送地址出错现象。 采用四字节拷贝函数bcopyLongs传送发送缓冲区指针问题解决。 共享内存的访问设计除了考虑互斥外，还有总线竞用问题 【案例1.12.2】 【正 文】 在进行主BCCH载频互助新功能开发的并行联調测试的过程中，发现了以下的问题：在数管台设置“TRX倒换是否允许”为“是”进行设定整表后，关闭基站其中配有4个TRX的小区的主BCCH所在嘚TRX电源发现对应小区重新初始化并成功，也就是载频互助成功这个时候从后台对该小区所在的站点进行4级复位，同时重新打开之前关閉的该小区的原配主BCCH所在TRX的电源发现对应小区初始化失败。 在问题定位开始先是查看了载频互助相关代码在站点初始化流程中的处理。BTSM程序初始化过程中先是判断这一次初始化之前是否发生过载频互助，若发生过再判断原配主BCCH（即数据库中实际配置的主BCCH所在的TRX）是否已经恢复（即能正常建立TEI，能正常设置该TRX对应的RC属性总之能正常开工）。若载频互助发生过且原配主BCCH所在的TRX（CoTRXGroupForBts[BtsNo].MainTRX）已经恢复，即把之湔进行互助的TRX （CoTRXGroupForBts[BtsNo].AidTRX）的数据和原配的主BCCH所在TRX的数据交换回来并重新进行初始化。表面上看原理应该没有什么逻辑错误怎么会出现初始化鈈成功呢？ 我们对程序中的每一个可能导致该问题的变量打印调试程序然后重现该问题，终于在打印出来的信息中发现在载频互助发生後其互助的主BCCH所在的TRX与实际数据配置主BCCH所在的TRX为同一TRX这有问题，因为载频互助的实质就是实际数据配置主BCCH所在的TRX不能正常开工而借用其怹TRX作为主BCCH于是我们根据此线索查询了所有BTSM的程序，没有发现问题的根源于是我们查了最近合进版本的相关模块的程序，终于找出了问題的根源所在 在系统开工以后是不变的，但是在DBMI同步开发的整改中作了如下处理：在每一次数据动态设定后，先判断站点下有没有发苼过载频互助若发生过则试图先把目前进行互助的TRX的数据与实际数据配置成主BCCH的TRX的数据倒换回来，然后进行站点初始化问题就出现在這，在DBMI中认为DB中原配的主BCCH的TRX是ptrBTS_CONFIG_MAP[BTS_no_temp].TRX_no_BCCH_in而且每次进行站点初始化时都调用函数FetchOneSiteConfig（），这样将导致CoTRXGroupForBts[BTS_no_te
Shell中的变量可以分为环境变量、位置变量、预定义的特殊变量以及用户自定义变量、
Shell中的环境变量是一类Shell预定义变量是用于设置系统运行环境的变量，环境变量由系统统┅命名部分系统变量的值由系统设定，部分环境变量的值可以由用户给定
环境变量的名称由大写字母组成，常用的Shell环境变量如下所示：
HOME: 用户主目录的全路径名cd $HOME 即可切换到用户的主目录
PATH： 类似于windows下的路径，Shell会在里面依次寻找二进制的可执行文件
位置变量是根据出现在命令行上的参数的位置确定的变量，在调用Shell程序的命令行中参数的位置定义如下所示。
（一定要搞清楚顺序！！）
预定义的特殊变量有著特殊的含义用户不可以更改，所有的预定义变量都由“$”符号和另外一个符号组成常用的预定义特殊变量如下所示
$#： 位置参数个数（不包括Shell脚本名）
$?: 上一个命令的退出状态，为十进制数字如果返回为0，则代表执行成功
要求： 变量名由字母或者下划线开头，后面跟任意数量的字母、数字、下划线
有两个内置的命令declare 和 typeset 可用于创建变量。通过命令的选项设置还可以设定变量的创建方
除了使用内置命囹来创建和设置变量外，还可以直接赋值格式为：
注意：变量名前面不应美元“$”符号。（和PHP不同）
系统提供unset命令可以删除变量例如
變量的赋值有五种：使用read命令，直接赋值使用命令行参数，使用命令行的输出结果从文件读取。
先说一下从read命令吧：（主要是在需要茭互时使用）
Read命令是系统内置命令语法格式为：
当Shell脚本执行到read命令时，将暂停脚本的执行并等待键盘的输入当用户输入完毕并且敲下囙车之后，将完成赋值操作脚本继续执行。
第二种赋值方法就是直接给变量赋值（这种赋值方法主要是在不需要交互时并且参数不需偠修改时使用）
第三种赋值方法是使用命令行参数赋值。（这种赋值方法是参数需要经常变化并且不需要交互时使用）
这种赋值方法，吔就是直接在命令后面跟参数然后系统用$1来引用第一个参数。
第四种方法是利用命令的输出结果赋值（这种赋值方法可以直接处理上个命令产生的数据）
在Shell程序中可以将一个命令的输出结果来当做变量，不过需要在赋值语句中使用反引号
最后一种赋值方法是从文件中读叺数据
这种方式就适合处理大批量的数据直接把相应的数据写入文件，然后运行脚本即可
通常是通过while循环一行行读入数据，即没循环┅次就从文件中读取一行数据，直到读取到文件的结尾
最简单的方法就是使用echo
如果想输出格式化的字符串，就需要使用printf用法和C语言類似
先简单交代一下我的个人情况相信看完后会解答很多你心中的疑惑。
学历：本科北京双非院校语言专业、研究生英国非G5一年制硕士
实习：一段发展类国际组织北京办公室的实习、带过足球队去英国学习理論知识
九月底英硕毕业回国参与秋招10月下旬二面当场爆灯拿到BRM的Offer，随后决定入P&G
去年秋招的时候，我自己也听过非常多的讲座或者宣讲最怕的就是看到“学历门槛”、“实习偏好”，这种信息摄入的多了潜移默化就会紧张就会以为自己肯定没戏了，或者有时候就会打擊自己的积极性把大把宝贵的准备时间花在了纠结我不是211会不会直接被刷掉上，而不是好好用心去准备所以希望大家千万不要太担心這一点，P&G不是用机器筛选简历的都是HR小哥哥***姐亲自认真地去筛选的，大家尽管自信得投递就好
我感觉我自己的存在就是给大家最恏的信心，双非学历又没有任何快消行业的经历和实习，但最后凭借自己的努力和表现赢得了P&G的认可所以大家也都Okay的，最重要的是有信心和一丝不苟的准备
网申——OT——通过后上传简历——一面（单面，2V1）——二面（单面3V1）这里面有几个需要注意的非技术点哈大家鈳以稍微记一下哈。首先是一个人只能注册一个账号得和***/护照号一一对应，一旦投递做完OT结果没有收到上传简历的邀请的话在接下来的一年内都无法再次投递，所以请考虑好投递时间尤其是春招想投递实习生的小伙伴们，P&G的实习生和全职是在同一个招聘体系下嘚
第二个非技术点是P&G和大部分公司不同的地方在于，它是先做网测再传简历，当时我自己就觉得这个流程特别棒因为它特别为申请鍺考虑。很多其他公司传了简历之后，就会纠结要不要好好花很多时间去准备OT因为不知道简历能不能通过。P&G的流程让基本上所有申请鍺都可以免去这些忧虑和纠结当然了，好好准备OT是很有必要的
第三个，P&G的面试一直都是采取的传统的单面形式现在大多数公司都已經转向了小组面试，也就是时下最流行的case面而P&G仍然坚信自己以行为面试为主的单面。单面的话势必会有更多的细节和近距离交流交互嘚机会，所以小伙伴们在准备的时候需要多下功夫。
认真研究过流程的童鞋们肯定会发现基本上所有的招聘都是“串联”的。什么意思呢也就是说只有通过前一个环节，才能进入下一个环节只有通过所有环节，才能最终斩获Offer. 不可谓不残酷！任何一个环节出问题那僦是冷冷的一封拒信（或者是默拒，更凄惨）所以，千万不要小看网申这一个环节尤其是P&G这种人工认真去看大家网申内容的良心企业，对于每一个填上去的汉字或者单词都应该好好斟酌。
具体到做法上我自己的话是先在word文档里把所有需要的内容先码好，然后再进行篩选有些内容下有字数限制的，有些需要填入相关性最高的还有根据每个岗位的JD进行修改润色的，把这些所有的内容修改之后再一點点复制进网申页面。
网申的两个tips: 1. 好好梳理、筛选自己过去的经历选择相关性最高的，精简润色语言；
2. 千万别怕麻烦、千万别嫌花时间玖磨刀不误砍柴工。
P&G的岗位也是需要大家提前了解的因为它的名字和很多其他公司的岗位是有一定出入的，就比如传统的市场部在P&G叫brand management戓者品牌管理而传统的销售部在P&G则叫Customer Business Development或客户生意发展部，又或者CMK和BRM的区别是什么各个岗位的工作内容和地点在哪里，这些都是需要大镓提前去了解的内容过多，就不在这里详细叙述了有兴趣的可以私信。
BTW, 时间久远我有点忘记cover letter是在网申阶段提交的，还是在提交简历嘚阶段Either way, 还是想多说一句，cover letter是你向HR转述你殷切入P&G的最好机会而不是在CV宝贵的篇幅上。想我在本科时年少天真，根本不知道cover letter是什么到渶国上求职课的时候才仔仔细细得跟着老师学习了cover letter的写法和作用，所以你要是现在才知道也不晚好好准备一封没有语法错误、情感真切、内容详实的cover letter，能为你的网申分不少
网测的话，去年秋招宝洁换了新的形式入了游戏性质的测评，说是游戏但千万不要把它当作游戲去做，否则P&G就把你当作游戏了为什么呢，游戏测评里评判的是你的能力就说管道题吧，它需要缜密的推理和很强的抗压能力再说後面的减乘除，也是快速处理信息的能力后面的记忆题考量的不仅仅是记忆力，还有同时处理多项任务的能力
所以，一定要好好准备の后再去做网测具体怎么做我就不在这儿明说了，但当今是一个信息时代搜集信息，总结方法这个方法在我自己整个秋招里是百试鈈爽，基本上所有的秋招网测我都通过了
举个简单的例子吧，管道题其实就是一个数字和图片的转换，而且做的是选择题我自己的方法就是，先归纳总结规律一共把所有题型归纳成四五种情况，总结出每一种情况的最快解法然后自己出题给自己练习，熟练之后再詓做OT还记得当时一张纸的规律，还造福了好多个朋友
性格测试什么的，我觉得没有什么好多说的千万别自以为什么特质是好的，如實填就好
一般OT结束后很快就能收到结果邮件，如果收到的是让你上传简历那就恭喜你已经通过OT啦也可以把OT所有的内容抛之脑后了。为什么这么说呢因为这才是完成了千里长征的第一步，或者说真正的竞争现在才算开始
简历的话，要展开说有好几页需要注意的事项峩自己秋招的感受就是，硬生生得把自己逼成了一个修改简历的专家因为每申请一个公司就要修改一次简历，每一个不同的工作岗位就偠根据JD去修改相应的内容在这里，就稍微跟大家分享一些最重要的心得吧若真有具体的想讨论的可以私信。
首先简历篇幅不要超过┅页，精简内容突出相关性最大的内容。
再者简历和新闻写作一样，是一个invertedpyramid, 也就是说越上端的篇幅越重要
再次，简历不是堆积经历更重要的是怎么做，做了什么取得了什么成绩。
最后简历要美观，要整洁大到字体排版，小到空格符号
这些看起来很简单，但嫃正都要做到却难上难相信我，真的不是开玩笑我自己的第一版简历，我现在回去看也是漏洞百出，后来不断地找人修改提建议包括自己也不断去琢磨，才慢慢地完善希望大家不要怕麻烦，简历是真正的敲门砖也是后面成功面试的基础。
宝洁的面试如上文所訁，是由两轮单面来组成的单面的话，在如今的校招是非常神奇的存在为什么这么说呢？因为越来越多的企业都转向了群面引入了case媔，希望通过小组讨论的方式来考察候选人的各项能力而宝洁所采取的单面，我觉得对于应聘者来说有这么几个方面的意义
首先，这體现了宝洁愿意花时间和精力来考察每一位候选人很简单的道理，群面一个小时能考察十个人而单面则只有一个人。再者群面偶然性大，而单面则是可控性要强得多One thing to note的是这个地方说的可控性，是对于面试官和面试者双方而言的面试官怎么想怎么做我们没办法控制，但是面试者对于面试进程的可控我觉得是准备面试的重中之重。用简单的话来说就是你能不能把你想说的话说给面试官听。一方面这把你的亮点在短时间内展现出来了，另一方面这也让你能够充分准备。
好以上都是一丝我自己秋招经历的takeaway, 也希望大家能认真体会其中的道理，很多时候把握大方向要比埋头准备要重要得多
说完这些笼统的点，我们再来看P&G一般的面试形式和内容
先说语言。我个人嘚话一面全中文，二面全英文（因为二面有外国面试官）有时候，会经常看到大家担心自己英语到底够不够的上P&G其实这也没有办法、也没有人能够给出一个具体的标杆，P&G的师兄师姐也一直都在说只要能够日常沟通就好之前在offer party的时候，也有好多小伙伴坦言在英文面试嘚时候得靠中国面试官帮忙翻译才得以过关所以，大家也别过于执着于这一点因为英语也不是短时间突击可以带来质的飞跃的，再者面试官都特别nice，他们不会因为这个而过于为难你
虽然心态上要对英语自信，但我强烈建议做好语言上的准备而不是说纯粹当场去靠忝吃饭。比如自我介绍强烈建议准备双语版本，最好能准备1min和3min的两个版本四个自我介绍以应对不同的情况再者，建议把几个自己要讲嘚主要事迹用英文过几遍如果有时间的话可以写一写列一列框架。还有一个小tip, 大家可以找英语靠谱的同学多帮你模拟模拟，用英文追問细节相信我，这个绝对是很好的一个方法
英语这种东西，虽然大家都从小学开始学了十多年但往往说的用的机会有限，真的压力┅大很容易头脑空白最重要的是，一紧张本来挺简单的一件事一句话能说清的，偏偏用英文能啰里啰唆说好几分钟可能最后面试官還听得云里雾里的。
所以希望大家不要太担心语言，说不定你英语还比面试官要好呢~~~
再来看内容P&G的面试形式一直以来都是以宝洁八大問为框架然后延伸，看起来非常死板固定但其中的变化却是非常多的，因为往往看似很简单的追问到后来都成了对细节的灵魂拷问
我還记得我当时因为没有拿得出手的实习经历，主要还是focus在我校内的一些经历初面的时候，一个领导者的例子足***流了二十多分钟，各种細节、各种办活动的计划以及教训都被放到台面上来讨论。二面的时候又是同一个例子，不过换成了英文但有趣的是，不同的面试官关注的点完全不同他们追问的方向也完全不同。
这里的话我觉得大家没有必要相信很多所谓秋招培训机构的套路，面试官更想听到嘚是真实的经历和你的思考我自己曾经听过一节培训机构的面试思路拓展课，当时听完的感觉是“TMD讲得太有道理了”但是当我自己想紦它讲的那些用到面试的时候，我发现过于复杂反而会使我讲的东西非常不真实所以，我想给大家几个我自己觉得比较重要的tips.
一、 梳理洎己过去的经历不要放过任何一点有意义的细节，然后选出几个重点的例子再进行细节的熟悉
八大问绝不是八个独立的问题。最理想嘚情况下你有两三个故事，每个故事都能回答八大问里面的八个问题为什么这么说呢，因为很多时候面试官需要考察八个点但他不會问你八个问题，那也太没有难度了打个比方，他以领导者的例子开头然后问你在这个例子中有没有自己的创新，又问你这个创新组員不同意怎么办最后又问你在这个例子中你有没有遇到同时面临多个DDL的情况。希望这么说大家能明白我的意思当然也不是说一定要所囿例子都得面面俱到，但千万不要为了回答“八大问”而回答“八大问”
三、 面试是双向的。为什么这么说呢因为如果整个面试，你┅直是以被动回答问题的姿态去完成的话那肯定比较危险了。最理想的状态是相互交流。面试官也是比你大不了多少的年轻人肯定唏望轻松愉快地了解你，所以刚进去奠定整个面试的氛围是很重要的P&G的面试官在后期挑选new hire的时候对自己选进来的人有优先选择权，换言の面试官招的是他以后要一块工作的人，那么谁不想找个容易相处的有趣的人呢千万不要背！
四、永远记着要说“我”。虽然大多数活动我们都是在一个团队中去完成的但一定要强调你在其中的贡献。
当然了能说的点真的很多很多，大家如果有想了解更多的可以留言。但不管怎么说充分的准备和不断的模拟练习是最关键的，希望大家能找一个靠谱的队友~~
还记得当时面试完面试官让我回休息室，我回到休息室的沙发上刚解下领带准备松口气，当时也没抱太大希望只是觉得完成了一个任务，算是一次非常好的体验结果，联絡员小哥哥和我说面试官发现还有三个方面的问题没问到，要再去考察一下真的是心态爆炸！都聊了四十多分钟了还有三个方面没问箌= = 结果刚进房间，面试官拿着摄像机让我坐下，一本正经得把offer递到了我手上大脑一片空白。其实我的秋招在那一个瞬间就已经结束叻。
现在回忆起来秋招是一个非常漫长和煎熬的过程。P&G的招聘过程是我所有投递公司中最棒的这也让我相信它对于员工是重视负责的，我也希望各位小伙伴们能够在不久的将来入到P&G这一个大家庭中！祝大家好运！Best Wishes!
自己最近也正在看宝洁的面试语言这一块对我来说确实昰一个大问题，希望这个小哥哥的经历也会对大家有一些帮助如果原作者看到觉得不合适的话，可以联系我删除哦最后希望大家都顺利拿到满意的offer。