大公司处理问题的流程.ppt_第1页
大公司处理问题的流程.ppt_第2页
大公司处理问题的流程.ppt_第3页
大公司处理问题的流程.ppt_第4页
大公司处理问题的流程.ppt_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

Issue Debug Process Training,Prepared by Oliver,Is it a real issue?,你有没有耐心吃药? -避免不必要的手术 是不是一个真的犯罪? -避免虚假的指控 对执行的任何测试,期待的结果应该是明确的 -对这个component哪些行为是需要写明的? 这个chipset 支持到多大的物理内存? 这个显卡driver支持到多大的分辨率? 这个软件支持到哪些localize的语言? -我们怎么定义它是pass 或fail?,用于测试目的的第三方Items应该是被完全理解的Item,清晰明确的行为 -包含非HP发布(生产)的硬件和软件 -这个设备在其他的要出货的系统上表现怎么样? 在一个参考系统上建立一条“基线” -这个软件在其他的板子和不同的系统(image)上是不是给出同样的error message? 是不是第三方的问题一直都有?,Is it a real issue? -third party items,Is it a known issue?,知道病例很重要 -以前是不是也有这个问题? 对任何的怀疑都要做个背景调查 -这种反常的行为是不是过去有过类似的历史 是不是其他的工程师已经发现了这个issue? -是不是已经log到了内部的数据库? -是不是已经log到了HP OTS system? -在以前测试cycle里这一项测试是不是打的pass? 这个issue有没有被第三方的vendor发现过? -在Microsoft Knowledge Base article? -这个问题在vendor的support网站上有没有被描述过? .有没有新的driver/firmware/patch available fix 这个issue? -在技术交流时有没有讨论过这个issue?,Isolate the system,隔离病人 -防止进一步的传染、伤害 封闭犯罪现场 -确保没有人弄污证据 如果可能的话,捕获这个failing的系统 -对已经failed系统容易调查 可能在另外一个system去duplicate这个问题很困难 -防止对硬件或软件的改变 任何的改变可能会混淆这个issue 工程师可能会不小心破坏了有价值的证据 确定所有的证据都收集到了之后,再做下一步的测试,Gather the evidence,ISSUE发生时系统的状态,硬件和firmware的issue -系统是不是“死机”了还是应用程序hang住了 -在这个操作系统里面?BIOS splash screen? -Video on monitor? Video LED green or amber? -屏幕上到底有什么? POST error messages? 是OS的error messages? -系统风扇还转不转? -电源和硬盘的灯是不是活跃的? 任何的诊断声、闪现的代码 -keyboard LED有没有锁定(NUM lock, caps lock,etc.) -Debug signals asserted?(IERR#) -系统对四秒关机有没有反应,Gather the evidence,对于软件的issue -任何的error messages 或者 屏幕现象的变坏?截图 -任何的生成log?把它们抓下来 -任何的memory crash dumps, “minidumps“, 或着生成的应用程序的dump files?比如:C:WindowsMemory.DMP .C:WindowsMinidumpMini120804-01.dmp .C:Documents and SettingsLocal SettingsTempsomeapp.exe.mdmp -在事件管理器里任何的errors? -对那些设备driver和application 安装的issue看C:Windowssetupapi.log -对哪些preinstall issue,抓preinstall log files: .C:system.savutilinstall.log .C:system.savutilcia.ini .C:system.savcto.txt .C:ctoerror.flg .C:devtoolsdevcheck.log,Analyze the evidence,failure是在什么时候发生的? -从error messages或failure 事件搜集的证据里面找出跟时间有关的信息. -当系统failed时候发生了什么事? -询问“目击者”可能会有帮住 -工程师做了什么? 2. 分析log file 或者 error messages -log files 告诉我们一些什么? -它们是不是指向了哪一个的设备或者driver? .如果它指向了一个component,那你需要得到关于这个component的更详细的信息 ,如硬件,firmware/driver versions -它有没有指给我们另一个线索? 3. 分析crash dump files 4.从多个failing系统收集的数据 -共同的硬件或软件(在failing的系统间)? -共同的软件component?,Duplicate the issue,1. 这是个孤立的问题吗? 2. 问题又发生了没? 3. 问题只发生一此很难复制吗? 4. 当同样的步骤被操作以后,failure有没有再此发生? -如果这样,有多经常?是不是100%? -failure是不是有几率的? 5. failure 是不是以同样的方式发生? -同样的外在的现象(征兆) -同样的error message出现? -在log file里面有同样的条目出现 -“类似的”crash dumps? 6. failure是否在不止一个系统上发生? -在类似的configure system上有没有fail? -在一个不同的系统上有没有fail?(比如说当前出货的其他板子上?) 7. failure是不是间歇性的,如果是,能找出一种自动测试的方法对复制这种issue会有帮助 -花少量的时间手动复制 -为了获取更一致的debug结果,Isolate the problem,1. 确定出issue不包含的东西 2. 确定出怀疑的对象 3. 在同一款platform上,以前的这项测试是pass的吗? 4. 这项测试有没有在类似的系统上fail? 5. 这项测试在一个已知的好的参考系统上测得是不是pass的? 6. 做了改变之后fail还会不会在原来的系统上发生 7. 在尽可能简单的配置上试着去复制这个issue 8. 从不同类的failure里面找出共同东西,Issue occur,Reproduce on fail unit ?,Can reproduce on other same MBs platform?,Can reproduce on other different MBs platform?,Compare with each Component (OS? Driver? BIOS? Module?),Single ?,Send to vendor for FA,IMS Submit,Verify fail component,1. Can reproduce with another same component on fail unit ? 2. Can reproduce with another same component on other different MBs platform? 3. Can reproduce with another same component on other same MBs platform?,NO,YES,Record fail rate and submit ITT,100% fail issue,Can reproduce on fail unit Single unit fail issue,Intermittent issue,According to the issue fail symptom to decision if add more times or add test units to reproduce . Then get the fail rate,Verify in another same HW config if can repro?,NO,YES,Debug to component level,Issue Debug Process,Debug to component level,MB Module (HW+ Driver+ BIOS),HDD Module (HW + FW),ODD Module (HW + FW),GFX Module (HW + Driver + VBIOS),CPU Module,Memory Module,TV Module (HW + Driver ),Card Reader Memory cards,Modem & WLAN,APP+QFE,Debug to component level rule: 1. Based on the fail symptom to decision use which strategy about issue debugging 2. Daily issue review meeting in MIST internal with all troubleshooters and IA(Issue Analyzer) 3. Dont have next action item and dont have to nar

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论