Twitter Updates

    follow me on Twitter

    May 30, 2009

    Code Review, Debugging, Windows Internals, WDM小结 (一)

    学完Silverlight之后,最近两三个星期集中在了code review, debugging, 以及Windows Internals和WDM的学习上。现在是时候做个小结了。

    逛了一些关于debug,windows内核,驱动等的论坛,发现大家主要集中在了加密/解密,逆向,系统漏洞和反病毒等等专业领域,和我所学习他们的目的并不相同。所以,文章和我所关注的知识点也不很match。对于我来说,我学习他们的主要目的集中在了Debug和Security Test上。在学习的过程中有种知识零散的感觉,昨晚才把他们互相联系起来,因此也就有个立体的感觉(请看下图)。下面想简单地谈谈。

    首先,Debug是一项软件人员应该掌握的既基本,又高级的技能。它并不属于开发人员的专利,测试人员拥有这项技能也如虎添翼。说它基本是因为在你大学学习计算机语言的时候都会或多或少用到debug的技术,是编程中一项必用的技术。说它高级是因为很多疑难杂症都需要高超的debug能力才能去解决,debug的能力很大程度上体现了一个人的软件开发测试的水平。大家debug的目的各不相同,而对于测试人员来说就是在发现一个bug的时候能够通过debug找到root cause。在debug的学习与实践中,我认为以下知识非常重要:

    1. Debugging tools: 微软提供了一套tools,而我们最常用的就是windbg了。windbg使用起来还不算麻烦,学习起来也不难,但是各项命令实在是太多了,需要时间和经验去慢慢积累。
    2. Code review:或者你做专门的code review,或者你在debug的时候做code review。总之,你对代码不熟悉是很难进行debug的。因此,code review也是debug中非常重要的一个方面,你应该熟悉你所测试产品的代码。很多时候,你甚至不用去debug,想想代码流程,或者简单地review一下就能定位bug。而对于code review方面,你需要了解Win32 API (User mode code),以及WDM,WDF (driver)。
    3. Assembly: 如果你没有源代码的访问权利,你就需要逆向的能力了,这个就对汇编的要求很高了。但是,一般来说我们都是测试自己的产品,理所当然具有源代码的访问权利。但是,即使这样,我们仍然在某些时候需要汇编的知识去debug,比如有时windbg的命令不能正确显示结果,或者调试optimized code的时候。不过这些要求不会太高,一般来讲你学习几个小时的汇编就应该够用了。
    4. Windows internals:其实Windows internals是里边最难学的,但又是比较基础的东西。比如,windbg的很多命令的使用需要你了解内核的工作原理及数据结构。而你在调试driver的时候当然需要内核的很多知识。你如果把内核学通了,其他知识都不成什么问题了,所以对内核的掌握程度也直接决定了你的debug水平。这本书我从开始看断断续续的也快三年了,最近才有了立体的感觉,一想能知道这本书都说了些什么,虽然我不确定我到底看懂了多少,但是基本上在debug需要的时候我能够直接找到相应的章节去看,也应该可以短时间内看懂。由于先看了这本书,所以在看WDM的时候就感觉很简单了,虽然作者说话很罗嗦,但是不用太多的推敲都能很快理解。有种感觉,好象是精通了C/C++以后再去学习其他语言的时候的那种感觉。

    image

    May 28, 2009

    你是不是要找病(Bing) ?

    在Google和Yahoo中搜索Bing, 出现提示"你是不是要找病"。

    image

     

     

     

     

     

     

    image

    May 24, 2009

    《Windows Internals》学习心得(2)- Windows Architecture

    Windows

    • kernel32.dll, advapi32.dll: to provide Windows APIs
    • ntdll.dll: to switch from user mode to kernel mode
    • ntoskrnl.exe and drivers: major part of Windows OS
    • hal.dll: hardware abstraction layer

    Ntoskrnl.exe and drivers

    • executive
    • kernel: KeXXX

    Executive

    • system services: NTXXX, ZWXXX
    • executive support routines: ExXXX
    • executive components and relevant services

    Executive components and relevant services

    • Object manager: ObXXX
    • Configuration manager: CmXXX
    • Process and thread manager: PsXXX
    • Memory manager: MmXXX
    • IO manager: IoXXX
    • P&P manager: PpXXX
    • Power manager: PoXXX
    • Cache manager: CcXXX
    • Security reference monitor: SeXXX

    Drivers

    • ntfs.sys
    • volmgr.sys
    • ndis.sys

    May 23, 2009

    xikug谈黑盒,灰盒,白盒,逆向


    早就想写点什么,自己都不知道一天在瞎忙什么,一直到最近才开始动手。。。我想通过这个乱谈系列跟大家分享一些心得。我打算在这个系列文章中讲点方法与思路,当然,很多方法并不是我的原创,只是我用这些方法和思路解决了我的实际问题。由于本人水平有限,很多说法只是我个人的理解,然后用我自己的语言表达出来,可能并不专业,所以在这里不负责任的乱谈一下,欢迎大家拍砖。
    什么是代码逆向
    代码逆向即是在没有源代码的情况下,对目标程序的行为、数据流、及编译器生成的代码进行分析,通过分析我们可以了解、发现程序的功能、流程、规则、及技术实现细节等,通过分析我们能对其进行优化、功能增强、漏洞填补、甚至还原成源代码等。这个分析过程我们可以称作逆向分析或逆向工程,简称逆向。
    对我们个人而言或许我们能够从逆向分析的过程得到的最大好处就是学习到优秀程序的设计思想、及技术实现细节。
    当今,逆向分析技术在很多地方都得到了应用,典型应用包括恶意软件分析、漏洞挖掘、BUG定位、技术探秘等。
    有人可能会说逆向太无耻了,自己不会写就偷别人的代码。。。我就不相信说这话的人什么都会,我就不信他没有分析过别人的东西,学习过别人的东西,我只能说他是无知的。。。殊不知逆向是一个探索未知的方法,是一种学习态度,是代表不屈服于困难的精神。如果没有逆向当前的很多科学进步不了这么快,也可能不能取得进步,科学研究就是探索未知,把我们未知的东西进行分析研究变成已知,不光是软件领域有逆向工程的应用,其他领域如:基因重组、化工、制药、电子、建筑、航空、军事等领域也存在着他们各自的逆向工程应用,逆向工程帮助科研人员把未知的东西进行分解、研究、组合、改进等,甚至创造新的东西出来等,科学就是这样一点点进步的。
    通过逆向得到的好处是显而易见的,然而任何技术都是把双刃剑,逆向分析技术也不例外。可能被人用于学习、解决技术问题或做有益于软件安全的事,也可能被人用于搞破坏。
    逆向方法
    白盒分析
    白盒分析就是从代码级别上(可能是反汇编代码、反编译的伪代码或源代码),通过动态调试或静态反汇编分析和理解程序的功能、逻辑,找到程序的安全问题等。
    黑盒分析
    黑盒分析是指从程序的外部,通过观察程序运行时候的行为,规则等来猜测和断定程序可能的实现方法,是否有存在脆弱点等。
    灰盒分析
    灰盒分析通常需要借助一些专有工具(可能需要自己编写),如api监视工具,陷阱工具,内存比较工具,文件监视工具等对目标程序进行监控,看它发生了什么操作,调用了哪些api,产生了哪些结果,在系统哪些地方安插了HOOK或过滤等,以此来猜测和断定程序可能的实现细节。
    目前越来越多的程序加了VM或进行了代码扭曲,用白盒分析此类程序可能会花很大力气也找不到突破口,而黑盒和灰盒分析往往对这类程序可能有意想不到的效果。
    逆向手段
    动态调试
    通过调试器对目标程序进行追踪分析,能够清楚的了解到程序运行起来后内部的状态,运算结果等信息。
    静态反汇编/反编译分析
    使用反汇编器或反编译器把目标程序变为可读的汇编代码或伪代码,然后分析程序的结构,流程,逻辑等。
    如何学习
    逆向并不是想像中那么难,但也不是想像中的那么简单,真正困难的是如何有效的运行这些方法和手段来更快、更好的达到我们的目的,这需要累积大量的程序设计经验和逆向经验。
    通常我们进行逆向的时候希望达到的目的大致可分为以下几种:
    技术探秘/代码还原
    软件漏洞挖掘
    软件Bug定位
    软件行为/规则分析
    解除软件的使用限制
    进行辅助程序的开发
    我们要达到的目的不同,逆向时采用的方法和手段的“细腻”程度也不会相同,譬如我们对一个win32平台下的内核驱动进行“技术探秘/代码还原”的时候可能会把白盒、黑盒和灰盒所有的方法和手段都用上,每段汇编代码我们都必须看懂,代码实现了什么功能,跟另一段代码有什么关系,理解整个代码的架构和思想等;而我们在进行“软件行为/规则分析”的时候可能只需用上黑盒或灰盒分析法就够了,知道按下这个按钮后读写了哪些文件,哪些注册表项,调用了哪些api等等。分析过程中有时候我们只需静态反汇编看一下就可以了,有时候我们可能还需要动态调试一下,总之没有固定的套路,一切视情况而定。
    扎实的编程基础是学好逆向的关键,基础打好了学什么都快。程序的基础就是算法和数据结构,语言只是一个实现的工具,绝大多数语言都是相通的,我们只要掌握一门,以后如果需要学习其他语言的话上手就会很快了,基础知识我们重点需要掌握以下内容:
    1.至少一门高级程序设计语言,推荐C语言或Pascal
    2.x86汇编语言
    3.常用算法和数据结构
    软件一般都是在特定平台下运行的,如Windows平台,Linux平台,WinCE平台,Java平台,Symbian平台,Plam平台等等。。。针对特定平台下的软件逆向,需要掌握特定平台下程序设计的相关知识,包括其SDK,进程管理,内存管理,文件系统等。这些东西不必全部精通,但要有个大致的了解,常用Api要知道,有特定平台下的程序设计经验最佳,遇到问题知道在哪里能找到自己想要的资料就够了。逆向的过程本身就是一个学习的过程,因此我们可以在逆向的过程中补充自己相关的知识,这样学习的效果是最佳的。(由于本人所接触的面比较窄,接触得最多的就是x86 Windows平台下的原生程序逆向,因此本系列文章中的内容除非特别说明都是指x86的Windows平台下原生程序和代码)
    学习逆向的最好方式就是动手实践,在实践中有针对性的学习。通常来说我们逆向时所面临的东西对我们来说是未知的或者是可能知道但不确定的,如果是已知的就没必要再去逆向了。针对性的学习就是在自己逆向的时候缺什么知识就补什么知识,日积月累过后我们的收获是相当可观的,不光是经验值的增长,还有知识面的增长和知识深度的增长。
    编程的经验对于我们实践逆向时也很重要,例如进行“漏洞挖掘”的时候我们可能会以程序设计者的角色进行思考,程序在哪些地方需要进行防范,哪些地方可能会出现漏洞等等,如果我们有足够的经验的话,可以很快定位到相关的代码部分对其进行分析,看是否存在可能的漏洞。又如在进行“技术探秘/代码还原”的时候,由于现在的程序规模越来越大,我们不可能每条指令,每段代码都去看,都去逆向,假如一个1M的程序需要这样做的话,光时间成本上来说成本都是相当高的,因此我们需要快速定位关键代码段,而丰富的编程经验有助于我们做到这一点。拓宽自己的编程知识面、积累编程经验跟积累逆向经验同样重要。丰富的编程经验能让我们事半功倍。
    另外在进行代码还原时我们最好能用原始程序的实现语言进行还原,这是为了避免麻烦,因为现代的编程语言通常都有自己的Framework,提供各种各样的类库,他们功能各异,互不兼容,如一个VCL的程序我们硬要用MFC对其还原,VCL的某一非常复杂的机制或功能在MFC中可能没有,而自己如果在MFC中实现的话工作量是相当庞大的,这时的结果可能就会是事倍功半了。因此我建议在代码还原时最好使用原语言进行,原来是C的就用C,原来是Delphi的就用Delphi,原来是Python的就用Python。。。
    逆向工程时常具有“四两拔千斤”的功效,我也不太会表述,等你有足够的实践之后大概才能体会到,这个就只能意会不能言传了
    学习资源
    上面说了那么多,是时候介绍一些学习资源的时候了,这些资源都是比较基本的,可说是学习阶段必备的,希望在大家学习和实践的过程中能帮到大家。

    《Windows程序设计(第5版)》 – Windows平台下程序设计的经验教程。URL - http://www.china-pub.com/2382
    《Windows核心编程》 – 又是一本经验的书,可以帮助你把Windows下的编程技术提升一个层次。 URL - http://www.china-pub.com/131
    《深入解析Windows操作系统(第4版)》 – 这本书是关于Windows内部机理核心的权威之作。这本书对提高你的逆向水平也是大大有帮助的,当然,前提是在你看懂之后。 URL - http://www.china-pub.com/32775
    《加密与解密》 – 不错的入门书籍,快出第三版了,http://www.china-pub.com/12210
    网站
    www.rootkit.com – 很多关于系统安全,系统内核方面的资料和代码
    www.codeproject.com – 很多程序设计的代码和文章
    msdn.microsoft.com – 包含最新的微软平台下的开发资料
    论坛
    bbs.pediy.com - 看雪论坛,国内最大的加解密论坛,已经向软件安全转型,上面汇集了国内大批高手。
    www.unpack.cn - 一蓑烟雨,国内最专业的脱壳论坛,关注面也很广,除了脱壳外还有汉化、软件安全、木马病毒、编程、游戏、文学、音乐、艺术等,上面的高手也不少。
    bbs.driverdevelop.com - 驱网论坛,驱动开发的论坛,高手不少,但是发言的比较少,可以去逛逛。
    forum.sysinternals.com – Sysinternals,很多系统方面的资料,不少高手在上面发言。
    www.debugman.com - 第8个男人,在下创建的论坛,旨在为志趣相投的朋友提供一个交流平台,目前关注方向为程序设计、逆向、代码安全和系统底层等。
    工具
    这里列出的工具只是很少一部分,对工具的选用,我的观点是哪个随手就用哪个。
    OllyDbg – 调试器,ring3下的调试器,上手快,功能强大,有很多插件。
    SoftIce – 调试器,ring0级调试器,当然ring3程序也是可以调的,功能强大,但已经不更新了,不支持vista等较新的操作系统。
    WinDbg – 调试器,MS自家的调试器,就不多介绍了,两个字 - 推荐。
    IDA – 反汇编器,最强大的静态反汇编分析工具。
    LordPE – PE工具,可编辑PE文件等。
    PEiD – PE工具,可识别PE文件的格式信息,如用什么编译器编译的,是不是被什么壳处理过了等。
    FileMon – 文件监视工具,可监视系统或程序对哪些文件做了什么操作。
    RegMon – 注册表监视工具,可监视系统或程序对哪些注册表项做了什么操作。
    SSM – HIPS,这个工具有时候可以给逆向带来很多方便,如抓取某个文件,禁止访问某个注册表项,盒灰分析等。

    May 22, 2009

    《Windows Internals》学习心得(1)

    以前做开发的时候用VC, MFC, 对于Win32和Driver是一点也不感兴趣。后来乱七八糟混了好几年,IT业大变,自己碰巧就做上了测试。测试又做了快5年了,大部分时间是自我摸索,到了现在这情况变成了一定要学习Windows internals了。
    这本书从开始看也两年多了,我很难说我看懂了多少,只是最近才开始有点立体的感觉,当然这跟工作上接触到一些相关内容还是有关系的,否则只是硬看应该是看不懂才对。我想目前由于不精通Windows internals对于我的测试工作有以下几个障碍:
    1. 跟开发人员的沟通存在Gap。
    2. 不能更好地去设计测试用例,因此不能抓到更深入,复杂的bug。
    3. 对于一些复杂点的问题很难去debug。
    4. 对于code review, code coverage, security test等等都受到了很大的限制。
    5. 职业发展也有了bottleneck。
    因此,我觉得在今后的几年应该在Windows internals上下下功夫,争取能够达到精通。今天我就想谈谈自己以前比较混乱的一些概念,windows internals, windows kernel, SDK, DDK, Win32, driver。
    • Windows internals应该是讲Windows OS实现的一些细节,它并不局限在kernel mode的模块和知识,还涉及到了user mode的一些系统进程。因此,我说学习windows internals就应该包括了所有Windows OS的知识。
    • Windows kernel,我主要是按照在kernel mode运行的模块来理解的,因为Kernel mode里还有个kernel,容易造成概念的混淆。
    • Win32 API就是windows提供的在user mode的应用程序编程接口,它的工具包叫做SDK。但是涉及到系统服务,也就是内核上的服务的时候,他们是通过ntdll.dll转到kernel mode去实现的。也就是说,实现的细节还是在kernel mode。
    • Kernel里提供了一套接口叫DDK,是给driver的开发人员使用的。如果你想在Kernel mode运行你的程序,你应该只能通过编写driver来实现,正常来说。
    由于windows internals的大部分知识都是在kernel里,因此我也想主要集中在kernel mode里的模块和知识。
    1. 对user mode开放的服务都有哪些,实现细节如何?
    2. DDK里的函数都有哪些,实现细节如何?
    3. Executive层的模块都有哪些,实现细节如何?比如,memory manager, IO manager, cache manager等等。
    4. Windows里的driver都有哪些,实现细节如何?比如我认为最重要核心的ntfs。
    学习资料:
    《Windows Internals》
    《Programming the Microsoft Windows driver model》

    最后,HAL不想学,也不知道有没有用,Hardware不想学,WDF暂时不想学。现在是新手,能想到的也就这么多了。

    May 20, 2009

    Debugging Tools for Windows 学习使用心得

    其实我的主要工作一直是UI test, UI automation, manual test 等等。曾经跟领导提过想做些深入点的测试,领导则反问 “你Kernel debugging 怎样?”。这是一个非常有趣的问题,你因为不具备良好的kernel debugging的能力,所以不给你做深入的测试工作,而因为你没有做深入的测试使你也不可能具备kernel debugging的能力。很多时候事情就是如此矛盾的,而我也曾经说过,一切最终还得靠自己。
    前几天发现一个奇怪的bug,分给这里的一个seniro dev他也没太多的办法。我在一个高手的指导下自己debug and figure out了root cause。在和这个高手的交流中,也基本明确了一下步的学习目标。以前的我主要是靠自己摸索,我想多跟高手接触,交流还是非常非常有帮助的,当然机会也不是很多。那么我的下一步的目标就是“code review, debugging, windows internal and WDM”。Debugging可以说贯穿了其他的三个,因此我今天先谈谈我对debugging tools的感受。
    我们基本都是用微软提供的几个debuggers,ntsd, cdb, kd, windbg。ntsd和cbd是user mode debugger, kd是kernel mode debugger, 他们都是command line的,而windbg是UI的debugger, 可以调试both user and kernel mode。大多数情况,我都是用windbg,但是在一些特殊的情况下,我还是需要其他的tools。今天我主要是谈windbg,我想学习windbg大概分这么几个阶段:
    1. windbg的命令,共三种命令,普通命令,加'.'的命令和加'!'的命令。Debugging tools自带的那个教程学习一下就应该差不多了,以后就靠经验积累了。
    2. 如何开始debug, 这要根据你所debug的目标和要debug的问题来决定了。你应该决定是使用user debugger 还是 kernel debugger, 是 local debugging 还是 remote debugging, 是用windbg还是ntsd, 等等。通常都有几种方式去debug,你要能够准确选择一个最合适的。
    3. 怎样进行debug。对于一个需要debug的问题,你需要有你的策略。比如,在哪里设置断点,如何设置断点,等等技巧。
    4. 利用一些tools。有些情况下只有debugger还是很难debug,你需要使用其他的tools去辅助。比如,有的时候在问题显露的时候已经太晚了,你很难追踪问题发生时的情况。这里,你可以用一些tool使得在事情发生的时候跳到debugger上去。
    5. Code review非常重要。当你发现一个bug的时候,如果你代码熟悉,你可能直接就能想到问题出在哪里,或者你稍微读读代码就能发现问题所在,根本就不需要debugger。而在你debugging的时候,常常你也需要review相关的代码来理解这个问题。
    6. 汇编语言。当你在调试optimized code的时候,你常常不能通过dv, dt等命令正确地看参数,变量等等,或者变量根本就没得显示。这就需要你具备汇编语言的阅读能力,了解calling convention, 不同cpu的汇编,以及在disassembly模式去调试。
    7. Kernel debugging。如果你具备了以上的技能以后,user mode debugging应该不成什么问题了。但是对于调试kenrel mode还是需要一些附加的知识与技能。首先,kernel debugger的命令很多跟user mode的就不一样了,你需要学习。其次,你需要了解Windows internal的知识和数据结构,以及Windows driver model。这也是为什么我把Windows internal 和 WDM作为两个学习要点。
    最后引用高手的两句话,“debug一两年,你就没什么问题debug不了了”,“只要能repro,你总能找到办法去debug”。

    May 16, 2009

    我要反省自己

    一直觉得我的测试能力也算是很不错了,应该多在开发上下功夫,没想到是大错而特错。测试领域还是有很多东西可以做的其实。前天下午听了一个presentation,介绍一个tool。其实这个tool早知道,早就在用,只是有一个选项从来没用过,那人就介绍这个选项。当时就感觉不太对劲,回到office赶紧试了试。没想到的是在10分钟之内就发现了3个严重的security bug。这三个bug都可以造成远程的DOS攻击,使Server crash掉。产品发布在即领导也决定要马上fix。我告诉同事这个选项以后,结果几乎每一个人的模块都发现了或大或小,这样那样的问题。而我由于还没有继续进行我的测试,还不敢说最后到底能发现多少这么严重的bug。

    所以,测试其实真是有很多东西可以去开拓的。简单一个tool的某个option都可能让你的测试效果大不相同。

    May 12, 2009

    高级测试人才应该掌握的六类知识

    经常遇到测试人员不知道学什么,或者学一个东西不知道有没有用。其实我也经常会遇到类似的问题,因此我自己也想把我学到的知识归归类。我想只要是这几类的知识,你学习都没什么错,总是会有用的。

    1. 产品知识:对于你所测试的产品,你一定要非常熟悉。小到你所测试的模块,大到整个产品的架构,内部实现,代码,等等。
    2. 测试知识:黑盒测试,白盒测试,手工测试,自动化测试,性能测试,安全测试等等。
    3. 开发知识:编程,数据结构,算法,调试等等。
    4. 专业知识:以上2,3是基本的知识,你还应该精通一些你从事的更专的技术知识。比如,如果你的产品是基于.net的,你应该精通.net, 或者类似的J2ee等。(例如这方面我应该掌握的Win32系统编程,Windows内核,WDM等等)
    5. 领域知识:你应该精通你所工作的领域的知识,比如手机领域,数据库领域等等。
    6. 行业知识:你要对计算机行业的整体状态,新技术,动态,发展趋势有一个明确认识。(比如我除了自己从事的领域还关注Web2.0,云计算等等)

    要记住,你首先是一个计算机人才,其次是一个软件人才,再次是一个测试人才,最后你才是一个SQAA, SQAE, STE, SDET等等。要想做一个高级测试人才,这一条线的知识都需要掌握。

    May 10, 2009

    微软的混混们

    大公司总是会有这样那样的问题。这其中一个问题就是时间长了积攒了一些混日子的人,由于通常大公司都很稳定,不裁员,所以很多大公司被人们称为了养老院,比如微软。本人见过以下几类混混。

    1. A在微软已经工作了10年,典型的特点是神龙见首不见尾,长期Office的门紧闭,使人不知人是否在内。经常遇到他老板在门口敲门等待10分钟左右,最后确定人确实不在的场面。
    2. B在微软已经工作了9年,典型的特点是任何工作到了他那里就石沉大海。当你问他进展情况的时候,他的回答总是“I’m working on it”。本来几天就能搞定的事情,你总是会发现在他那里几个月以后还是active的状态。
    3. C在微软已经工作了5年,典型的特点是不回email,不参加discussion。一直奇怪分给他的任务他到底做了什么,做得如何。由于对他没有信心,老板只能叮嘱其他人尽量也要去cover他那一块。结果一年之后,他跟大家一讨论,发现他做的东西非常少,别人做的非常多,他还就顺势把这块任务推给了别人。
    4. D在微软是个新兵,工作刚满两年。可是不知为何从刚参加工作开始就混。第一年正赶上和以上某君交接工作,正好应了中国一句老话“一个和尚有水喝,两个和尚没水喝”的道理。任何事情到了他们那里总没人去care,两人互相推给对方。光工作交接就用了一年的时候。第二年终于算是全部负责了,可从来都是maintain 现有的工作,从没想过如何优化,扩展。Test failures从来不会主动去triage,一定要老板push几次才行。Test spec上明明有的test case就是发现不了bug。
    5. E在微软是个contractor,更是一个老油条。contract的工作一般一年。一年之后工作交接,你发现他几乎什么都没有做。Test spec, test code, automation job 等等几乎全部都是copy别人的。自己加上的test case自己都不明白为什么要有这个case和怎么去test。典型的回答是“This was written by XXX, I don’t know”, “I never run this test”, “This has been covered by XXX” (but they haven’t, if you ask XXX"), “Let me check and get back to you”, “All tests on this spec are manual”。从他口中能得到的信息量几乎为零,因此别人只能推到重来。

    以上几人已经有人由于长期坚持不得不离开公司了,剩下的在team里的比例还是达到了1/3, 也就是33%。这也是我为什么说微软裁人太少的原因,可惜的是微软裁人大多并不是按照Performance进行的,混得人还是在混,很多Performance好的却被裁。唉,这个世界总是不公平的。

    May 5, 2009

    微软又一波大裁员

    如果大家看过我以前的文章就会知道我对这次裁员的最终结果并不乐观。http://peking2toronto.spaces.live.com/blog/cns!A975CAF18FBB985B!1141.entry

    Twitter上我也发过相应的消息。

    image

    今天相信大家能够比上次睡个好觉,因为这次保密工作很到位,很少有渠道偷漏这次消息。而所偷漏的点点消息也信息量也非常少。但是,谣言总是会被事实证明。今天我们看到几点:

    1. 微软进行了加速裁员,把18个月的计划提前到了6个月。
    2. Steve松口,可能会进一步增加裁员的名额。
    3. 这次之前就有消息说Windows开发组已经被动,Let’s see。

    上个Quater, 微软的利润下滑32%,其中很重要的原因就是Windows销售不力和Netbook的兴起。Windows7是很不错,但是我个人认为计算机业现在已经过了OS驱动的时代了。

    image

    Good luck Microsoft! Good luck Everyone…