2007年，以2年的工作经验去一家小公司去面试。当时笔试完，对方对我很认可。但当时他说：“我需要招一个，在大公司待过的，最好知道硬件开发流程和规范的。虽然你题答得不错，但是我们需要一个有丰富经验的，最好在华为待过的。”

当时，我就在想“华为的规范和流程是啥样的”。后来我去了华为，我把能想到的华为硬件开发的几个不一样的点，跟大家分享一下。

当时刚入职时，三个人做一个电路板。虽然电路复杂一些，还是有一些人力过剩的。所以，我就被安排去写一个PCI转UART的逻辑。

我当时是新员工，也急于表现自己，利用周末的时间，估计用了一周的时间，就写完代码，开始仿真了。我以为我的导师兼主管会表扬一下，结果没有，他说：“你为什么没有召集大家讨论？然后再写方案，评审？然后再动手写代码？”我当时是不理解的，觉得我一个人就搞定的事情，为啥要这样劳师动众？

后来反思过后发现了以下问题：

第一、 从主管的角度，不知道新员工的个人能力，你能把做的事情讲清楚了，他才放心。

第二、 从公司的角度，有一套流程来保证项目的交付。那么则不再太依赖某个人的个人能力，任何一个人的离职，都不会影响项目的交付。这也是华为最了不起的地方，把复杂的项目拆得非常细碎，这样不需要特别牛的人来交付项目。这是为什么华为的工程师的收入是思科的N分之一。

第三、 从效果角度，毕竟一个人的想法是有限的，把想法文档化的过程，就是整理思路的过程；讨论的过程，就是收集你自己没有想到的过程。正式的评审，是大家达成意见的过程。提前讨论，让相关的人都参与到你的设计中，总比你设计完了，被别人指出一个致命的问题要强得多。

就是因为华为把一项工作拆散了，所以沟通，文档，评审，讨论，变得非常重要。这个工作模式的缺点，也是显而易见，沟通成本高，工作效率低。

在华为内部里面，人员角色非常多。硬件的人是对产品开发阶段，端到端负责的。做单板硬件工程师，可以涉猎最多的领域，同时也是工作内容最杂，接触人最多，扯皮的最多的工种。

但是也因为有人专门负责画PCB、EMC、电源、逻辑，原本硬件工程师应该做的领域。那么硬件工程师就武功尽废，变成“连连线”。

其实不然，正是由于每个人都是一个小的领域，没有人统领，所以一个好的硬件经理的作用非常的重要，是贯穿所有领域和全部流程的关键角色。正如原来华为内部论坛上有一个人比喻的，硬件工程师更像是处理器里面的“Cache”，是所有环节的中转站。大公司把人的分工分的这么细，也是防止某一拨掌握了太多公司的核心技术，出去单搞了。

其实华为的流程，很多人都知道IPD流程是从IBM来的，我个人理解：IPD流程已经在华为变种，结合了中国人的特点，华为的企业特点进行了变通和优化。如果华为僵硬的套用IBM的这套流程，也必定不会这么成功。

那么概括一下华为的硬件开发流程：

需求分析→总体设计→专题分析→详细设计→逻辑详设→原理图→PCB→检视→粘合逻辑→投板→生产试制→回板调试→单元测试→专业实验→系统联调→小批量试制→硬件稳定→维护。

流程的根本在于，这个环节做好了，再进入下一个环节。所有的环节其实跟其他公司并没有太大的区别，只不过严格把握了进入下一个环节的考核条件。令硬件工程师最纠结的是“没有个节点跟’投板’对应”。

华为支撑IPD流程的系统是PDM（又名爬的慢）

PDM的中文名称为产品数据管理（Product DataManagement）。PDM是一门用来管理所有与产品相关信息（包括零件信息、配置、文档、CAD文件、结构、权限信息等）和所有与产品相关过程（包括过程定义和管理）的技术。华为所有的器件资料，产品部件，工具，文档，原理图，PCB，逻辑代码等都存在这个系统上。但是系统过于庞杂，其实比较难使用，跟服务器归档、SVN归档、也容易搞混淆。

硬件工程师一般都能够理解，在一个板子上面的，尽可能的选择成本更低的器件，选择更少种类的器件，便于集中采购，同时也便于加工。但是其他公司可能没有对器件归一化的工作做得那么细致和严格。

第一， 由于华为整个公司使用的器件种类非常的多，所以如果减小一个器件编码，带来的收益是十万人民币到几百万，而其他公司可能达不到这个高的收益。所以如果能减少一个编码，宁愿选择可能成本更高的器件。但是这个也需要按照每年的器件直接成本收益*器件发货数量，与编码成本+加工成本差异，进行对比的。不过器件归一化之后，器件的价格又可以跟供应商重新谈价格，这个收益是迭代的。所以，有时即使是成本占优，也会倾向去器件归一化的结论。例如，逐步去除了5%精度的电阻，归一化到1%。

第二， 器件归一化，都是需要进行专题分析的。因为也有工程师为了归一化，对电路原理没有充分分析，导致的归一化带来“问题引入”。所以，当时我的部门当时有一个表格，“器件归一化分析.xls”的excel表格，把每个器件，原来选型，归一化的选型，更改的原因，都做好记录和原因分析。一是让每个做归一化的员工都充分考虑分析，二是问题都有记录，便于评审，三是出了问题，好打板子。

除了器件归一化，更高一个层次的归一化，就是单板归一化。（单板这个概念，我稍微澄清一下，我刚到华为的时候，也觉得这个词很奇怪。因为通信设备，都是机框，背板，加各个功能模块的电路板，各个功能模块的电路就叫做“单板”，硬件工程师，一般也叫做“单板硬件”）

单板归一化带来的好处，首先是电路的种类少，电路的种类少的好处有三个：

一是生产成本降低；

二是硬件维护成本降低；

三是软件开发和维护的成本降低。

第一、单板归一化的先决条件首先是处理器归一化。其实，华为的有的产品这点做得其实不好，X86、MIPS、ARM、PPC全部都用个遍，所以一个硬件平台，需要配备各种软件人员，操作系统搞N套，VxWorks和Linux，BIOS各种配套。

第二、单板的归一化，要注意产品的衍生。第一个版本的机框上的单板所实现的功能，如果后续的产品可以使用，应该直接可以用，不需要再开发。如果不注意这点，第一个版本的单板，到第二版本时，发现不能相互借用。反过来，再修改第一个版本的电路板，来适应新版本。有时问题更糟糕，就是完全不能兼容，只好重新开发。单板的规划显得非常重要。

第三、单板归一化时，虽然电路部分兼容了，但是结构件不兼容。对于市场人员的配置来说，仍然是两种配置。一样是失败的。

那么如果发现不同的硬件平台的架构雷同，功能类似。那么机框也可以归一化。只需要制作不同的电路功能模块，就可以实现不同的功能需求。

但是不同的硬件形态都是有他存在的意义的，如果强行归一，市场未必会接受这种事情的发生。例如用一个运营商的平台去归一一个企业应用或者家庭应用的产品，可能就未必能够成功。

这个说法是我自己想的，早在08年的时候，华为就在讨论“云管端战略”了，当时不是很理解。当我们一个运营商平台部门，跟“服务器”的部门合并的时候，似乎理解了点什么。

当X86处理器足够强大的时候，所有的运算，不管是否性价比最高，都送到云端进行处理，那么所有中间的存储和计算都显得不重要了。那么整个网络的结构，就是终端+管道+云存储和云计算。

     

     

     

     

     

     

我觉得很多硬件工程师有个误区，觉得自己的核心竞争力是在于会使用几个软件（cadence、Protel），画画原理图，画画PCB。我早期的一份工作就这样，最大的本事就是照葫芦画瓢，抄Demo板，抄以前成熟的电路，如果碰到了新的电路设计，一般是按照参考电路先画出电路，再通过调试，去尝试，碰到问题，再去解决问题。

那么我现在的观念是，硬件工程师最值钱的地方是在于懂硬件原理，懂得电路分析，模电数电原理，电磁场理论，而不是会使用画图软件。

那么华为是怎样做电路设计的呢？为什么会有专题分析的说法呢？为什么电路设计的时候要做专题分析？

     

     

     

     

     

     

第二、当电路设计过程中，碰到一些新的问题，之前团队中没有接触过的问题，或者认为是重点，难点的内容，会专门做这个问题点的专题分析：例如我们做过的一些双BIOS启动，摄像头的红外LED的驱动，主备倒换啊，之类的，就会把一个问题点分析透，然后再动手做画原理图。

第三、那么在开发硬件的时候，Demo只是作为参考，每一个依据都是来自于datasheet，除了看芯片的数据手册之外，还要仔细查看数据手册的勘误表errata，核对datasheet与Demo的差一点，如果器件有checklist还得核对checklist。曾经开发AMD的时候，datasheet、Demo、checklist，三个文档对不上的情况。也出现过，一个比较难复现的问题，后来查看了Errata，发现是厂家芯片升级了，修正了bug，而我们还在采购老版本的芯片。

第四、由于项目本身有交付时间要求，那么在有限时间内其实不可能做到每个问题点都做得深入透彻。那么问题来了：

是怎么做到的呢？首先，每个项目都有《问题跟踪表》，而硬件团队由于事情非常的杂，所以把这个表要用的非常好，不然丢东拉西很正常。我曾经把这个表应用到家里装修。这个表的原理很简单，就是记录，问题内容，责任人，完成状态，完成时间。但是只要你坚持用，你会发现，你问题不会跟踪丢，做事情会比较有条理，而且会有成就感。用了这个表以后，发现问题之后，先记录下来，即使现在不解决，那么也会识别他要不要解决，什么时候解决。其次、问题分优先级，任何项目都是带着风险前进的，那么识别出高风险的问题，优先解决高风险的问题，带着低风险的问题继续走。这也是华为电路设计中“0欧姆”电阻用的比较多的有一个原因，识别出风险之后，但是又分析不清楚，或者来不及分析，只好做兼容设计。这里不得不感慨一句，在你的设计过程中，你马虎对待，没有分析清楚的问题，最后一定会暴露出来。

所以，在“菊花厂”做硬件工程师，“专题分析”是设计硬件最核心的工作，而不是画原理图。通过这个方法，用1~2个月做电路分析，而用1~2周时间画原理图，取代了，画图，调试，改版，再调试，在改版的形式。多快好省，是不可能同时实现的，那么硬件工程师有责任做很好的折衷和权衡。

在我进入华为的时候，当时整个公司都在“规范”运动，什么都写规范，人人都写规范，什么任职、绩效、技术等级都看规范。（大公司用KPI来引导，容易搞成“运动”）。所以当时，按照器件种类，很多人写了各种器件选型规范。当时，原理图评审的时候，听得最多的就是“规范就是这样写的”，这里面有一些问题：

1、写规范的人不一定水平高，或者写得不细致，如果出现错误那就更是害人了。

2、规范有时抑制了开发人的思维，什么都按照规范来，不一定适合实际的设计场景；例如我需要低成本设计，但是规范强调的是高质量，就不一定适用。

3、有了规范之后，也会导致部分开发人员不思考，例如晶振要求在50MHz以上，放pF级的电容进行电源滤波，而低于50MHz的不用。大家都不想为什么，自然也不知道为什么；再例如网口变压器防护，室内室外，按照各种EMC标准的设计要求，直接照着画就可以；但是很少有人想为什么，也不知道测试的结果怎样，等实际碰到困难时就抓瞎了。的确在有的时候提高了工作效率和产品质量，但是工具也发达，人也就越退化，这是必然。

4、有些器件的选型，不适合写规范，因为器件发展太快，有可能等你规范写好，器件都淘汰了。例如：在X86处理器进入通信领域了之后，处理器选型规范就显得多余。

规范确实能带来好处。但是，并不是所有工作都适合用规范来约束。硬件工程师要能跳出“参考电路”、跳出“规范”，从原理思考问题和设计。

当然规范还是非常有用的一个手段，是大量的理论分析+经验积累+实践数据的精华。我觉得当时我看得最多的规范，是《器件选型的降额规范》，这是基于大量试验，实际案例，总结出来的器件选型的时候，需要考虑的内容。

例如：规定选用铝电解电容的时候，需要考虑稳态的工作电压低于额定耐压90%；而钽电容，稳态的降额要求在50%；而陶瓷电容，稳态的降额要求在85%；因为这里考虑了一些器件的实效模式、最恶劣环境（高温、低温、最大功耗），稳态功率和瞬态功率的差异……等等因素。

在华为的PDM系统上，器件都有一个优选等级“优选”“非优选”“禁选”“终端专用”等几个等级。工程师可以根据这个优选等级来直观的感受到器件是否优选。

那么器件的优选等级，是考虑了哪些因素呢？

1．可供应性：特别是华为这样厂家，有大量发货的产品。慎选生命周期处于衰落的器件，禁止选用停产的器件。我2005年时曾设计过一个电路，设计的时候就是拷贝别人的电路，结果加工的时候发现器件根本买不着，由于器件停产了，只能在电子市场买翻新的器件。对于关键器件，至少有两个品牌的型号可以互相替代，有的还要考虑方案级替代。这点很重要，如果是独家供货的产品，是需要层层汇报，决策，评估风险的。

2．可靠性：

散热：功率器件优先选用RjA热阻小,Tj结温更大的封装型号；处理器选型，在性能满足的情况下，尽量选择功耗更小的器件。但是如果是Intel这样垄断的器件，你也只有忍受，加散热器，加风扇。

ESD：所选元器件抗静电能力至少达到250V。对于特殊的器件如：射频器件，抗ESD能力至少100V，并要求设计做防静电措施。（注：华为是严格要求，禁止裸手拿板的。我本来也不理解，后来我带团队之后，发现兄弟们花大量的时间在维修单板；我们的团队就非常严格要求这一点，看似降低效率，其实还是提高效率的。至少不用总怀疑器件被静电打坏了。）

所选元器件考虑更高的湿敏等级。

安全：使用的材料要求满足抗静电、阻燃、防锈蚀、抗氧化以及安规等要求。

失效率：避免失效率高的器件，例如标贴的拨码开关。尽量不要选择裸Die的器件，容易开裂。不要选择玻璃封装的器件。大封装的陶瓷电容不要选择。

失效模式：需要考虑一些器件的失效模式是，开路还是断路，会造成什么后果，都需要评估。这也是钽电容慎选的一个重要原因。

3．可生产性：不选用封装尺寸小于0402的器件。

尽量选择表贴器件，只做一次回流焊，就完成焊接，不需要进行波峰焊。部分插件器件不可避免选用的话，需要考虑，能否采用通孔回流焊的工艺完成焊接。减少焊接的工序和成本。

4．环保：由于华为大量的产品是发往欧洲的，所以环保的要求也比较严格。由于欧盟提出无铅化要求，曾经整个公司的几乎所有的硬件工程师都在做无铅化的整改。

5.考虑归一化：例如某产品已经选用了这个器件，并且在大量出货的时候，往往有时这个器件的选型并不是很适合，也会选择，因为不但可以通过数量的增多来重新谈成本，还可以放心的选用，因为经过了大批量的验证。这也是为什么倾向于选用成熟期的器件，而慎选导入期和衰落期的原因。

6.行业管理：某一个大类，例如：电源、时钟、处理器、内存、Flash等等都是有专门的人做整个公司的使用的规划和协调，提前进行市场调研，分析，编写规范。他们会参与到新器件的选型上来。

7、器件部门：专门有器件部门的同事，会分析器件的失效原因，可靠性分析，拍摄器件的X光，评估器件寿命等等工作。

8、成本：如果在上述因素都不是致命的情况下——上述的因素都是浮云，紧盯第八条。

1、首先大公司就是“会多”，因为公司大，部门多，人的职责划分的细，所以一件事情，需要很多人参与。容易出现扯皮的事情。我刚到华为时，非常不适应，什么都写文档，什么都评审，什么都开会；所以不适应这么多会议，开会时就会无聊，所有的贪食蛇的最高纪录都是那段时间破的。

2、任何事情还是有主要负责人的，华为给予负责人足够的权利，所以能够推动事情的发展，协调到资源。例如行销有足够的强势去推动研发实现客户的需求。产品经理、客户经理的能量还是很大的，能够跟研发的部长直接进行对话，推动研发干这干那。

3、所有问题最终都是会记录，跟踪，保证完成的。这就是为什么哪怕有些设备的质量，性能并不能让客户足够满意的时候，客户还愿意用华为的设备。就是这个原因，运营商都喜欢用华为的设备。一个问题出来了，还没确定是哪家的问题，华为的兄弟就冲上去了。联通2个人参加会议，华为6个人来参加会议，通过试验举证，证明是Juniper设备的问题。然后给出充分的报告告诉客户，这不是我们的问题，这是XXX厂商的问题。

4、林子大了，什么鸟都会有。所以推、拖、赖的事情自然总是有发生。这就需要强大而明确的绩效评价体系，去引导员工去主动承担任务，而不是去划清界限。这种“划清责任”的事情也不可避免。否则就是三个和尚没水喝。注：华为的这种凡事充分讨论的做法，在电信运营商的领域是适用的，放在消费者领域、甚至企业IT领域往往会不适用的，因为没有足够的利润率去支撑这么做。所以我说的一些华为的一些优点，各位华为手机的用户不用向我吐槽，：-）

5、在开会的过程中，经常人们容易进入误区，或者过于发散，或者过于保守。在产品定义阶段的会议，往往都有人提醒，发散的时候不要收敛；在问题解决的会中，往往会提醒，不要过去发散，聚焦问题。这个能够提醒大家的人往往就非常重要。当然有时也会流于形式，各位朋友可以看下一篇案例《华为内部讨论如何给孙杨涨姿势》，会议中不断有人提醒聚焦，但是大家还是比较发散。

什么是《罗伯特议事法则》？

一百年前有个好小伙子,名叫享利.马丁.罗伯特,二十五岁,中国人叫愣头青。他毕业于西点军校在南北战争期间奉命主持一个地方教会的会议。结果呢——搞砸 了。人们争个不亦乐乎，什么结论都没有。总之一塌糊涂。这个会开了比不开还要糟糕。这个小伙子呢，有点一根筋。说我要研究一下，弄个规则，否则我就再也不开会了。他研究上下几千年的开会讨论，有一个结论：人大概是特别爱争论的一个动物，最难被道理说服的动物，分歧一旦出现。很难在短时间内靠语言交流说服对方。否则吵个几天几夜都不会有结果。而且越吵越觉得自己有道理，对方是个笨蛋。所以双方找到共同点达成一个结论一定要有一个机制。他把这个研究当作一个战争一样。把人的争论本性当作敌人。最后这个小伙子打赢了。

打赢的结果是1876年罗伯特议事规则。他自费出版买了一千本到处送人。1915 愣头青罗伯特成了将军，他修订了这规则。一开始人家不重视，嘴上没毛说话不牢的小家伙行吗。唉，没想到，真行，他们一实行这个规则，吵架没了，会开下去了。墨水瓶，板凳也不乱飞了。结果罗伯特议事规则成了世界上最通行的议事规则。

开会经常有三个问题。

一，跑题：就是你说李连杰，我扯到成龙，我说猪八戒，你扯到温家宝**。跑得没个边了。而且老人家特别爱摆掌故，一开头，我给你们讲个故事，这一讲，就讲到中饭了。

二，一言堂：这一个一言堂呢，是领导者爱讲话，谁是领导就哗哗哗说个没完，一讲就全他讲了。第二个呢，农村有一些特别爱讲话的。也有从来不讲话的。。

三，野蛮争论：一讨论问题，就说你上次多报了五元钱，你不是好孩子，怀疑别人的品德。一百句话中抓住人家一个词不放。甚至打起来。会议就没法子开了。

四，打断：不得打断别人的正当发言。

     

     

     

     

     

     

罗伯特议事法则的一条就是：主持人来解决以上问题。但是一般的企业往往，领导出现的时候，主持人是不会去提醒领导，“你跑题了”，“你一言堂了”，“你不应该打断别人的正常发言”，这就是国外的科学的一些理论和方法到了中国往往不适应中国的土壤，不能生搬硬套的典型案例。

其实在华为，已经能够在大多数会议中，做到发生“跑题、一言堂、打断、不文明”时，有主持人去提醒，并拉回到正轨上。但是一些会议也做不到，比如：领导比较强势，领导自己是主持人，主持人是个马屁精，一些政治敏感问题，就不能去破坏和谐。此处不展开细说。

那么华为是怎么去解决这些问题的呢？

1、“以客户为中心”，所以领导再大，大不过客户，客户需求一律允诺，一律搞定。所以大家都是为了搞定客户，当大家在原则性的问题上不会有大的分歧。

2、 绩效导向，一切是按照结果去评价绩效的。所以在一些问题上，如果领导提出了某个方案，但是可能存在重大隐患时，底下人是有责任去提醒和反对的。否则造成重大严重后果后，领导跑不掉，一样会修理底下的人。都是拴在一条绳子上的蚂蚱。当某个同事提出跟领导不同的意见时，并有价值时，会从绩效结果上去认可这个兄弟。这就是教育员工，鼓励提出反对意见，鼓励纠正领导的错误。

3、 教育主管。华为提倡狼文化，所有的主管能够被提拔上去，一般都是狼性十足，能讲会说，精力旺盛，在开会时balabala一顿，与员工沟通时也是balabala一顿自己说得爽。那么就会容易造成一言堂，或者跑题。那么在主管培训的时候，都会教育带团队的人，要会倾听，会交流，沟通时要把握节奏和分寸。

我曾经支持过CCB的网络建设一段时间，当时刚去的时候，跟他们的IT规划部，开了一个会。当时，开会时就是典型的“一言堂”，他们一个领导过来，一顿狂骂：“你们华为的设备怎么怎么不行，你们思科的设备也是狗屎，你们西门子服务太差。。。。。。”，建行的人，还有设备厂商的人都被骂蒙了，就听他一顿牢骚，骂完设备厂商，开始骂自己的员工“balabala”。然后所有人都不知道这哥们想干嘛，这哥们也讲不出自己想要什么样的设备，性能和服务。然后气愤愤就走了。

一言堂、跑题、不文明，这些都不是致命的，最致命的就是“无效会议”。当这位领导走了之后，大家继续按照自己的思路，方法，继续讨论，然后花2分钟讨论一下，怎么应付这位领导。所以我们开会时需要的，但是如何开的有效是有套路的。

那么如何做到呢？

第一、 例行会议，有议题。例如周会，一周例会的议题做事先的安排，不是很随意的说一下。订好议题，订好每个议题的时间，保证不跑题。

     

     

     

     

     

     

第二、 会议要有纪要，每次开会的会议主持人，会议纪要人都明确。会议纪要是很重要的一件事情，也需要很高的技巧，即需要有效参与会议讨论，有需要记录下关键要点，不记流水账。

     

     

     

     

     

     

第三、 会议纪要要分为：

结论（会议结论不随意更改）；

遗留问题（要符合SMART原则）；

要有责任人；

要求完成的时间等等。

纪要有模板，提醒大家纪要要符合SMART原则。

     

     

     

     

     

     

第四、 勤跟踪，要闭环。所有的遗留问题，在下次会议的时候都会回顾，看看是不是完成了，有没有拖延，直到有个交代。当然，如果返现任务安排有问题，根据评估也会进行问题的关闭和挂起。

第五、 所有的决议都是需要有理有据的，不能是拍脑袋。因为事前拍脑袋，事后就会拍大腿。然后就有人拍**走人了。这样就不会决议是下级服从上级，少数服从多数。当然，这样的话就会存在效率问题，因为有些问题就会因为短时间研究不清楚，决策不下来。这是就有了CCB(这个CCB不是建设银行的意思，CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中，是“变更控制委员会”的含义，CCB可以由一个小组担任，也可以由多个不同的组担任，负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。至少会保证，决策的决议是集体的智慧。)

     

     

     

     

     

     

按照小米UI每周发布的进度，周四一天的内测。我按照华为的流程怎么套都套不出来。

疑惑点在于：

1、内测是指开发人员自测试，还是测试人员的测试？

2、如果是指开发人员自测试，那么测试人员在哪里测试？

3、如果是测试人员测试，那么开发人员的自测试呢？开发转测试的点在哪里？

华为背景的朋友一定会问：测试人员怎么可能用一天的时间完成测试？

也许有人说，小米的效率就是高。

那么我们来看一下华为的测试流程，你就知道是否可以压缩到一天完成相关的测试。

首先说明一点，华为的软件部门，包括UI、或者网站的开发团队也是按照小步迭代进行开发的，在产品稳定后，新增需求会拆分成细小的版本，进行最短周期的开发测试。也可能华为的拆解需求的能力弱于小米，但是这里我们单纯谈测试流程。

测试是产品开发过程中必不少的环节,在华为的研发人员中,有近三分之一的人员是测试人员。

华为的测试体系在国内算是起步较早,大概经历了这样几个阶段:

1) 青铜器时代: 手工作坊式测试

1996年研发测试团队成立手工作坊方式的研发过程和测试

2) 铁器时代：IPD和CMM阶段

1998年华为与IBM合作，开始引进IPD流程

1999年左右引入CMM理念

产生IPD-CMMI流程

     

     

     

     

     

     

2004年在IPD基础上开发PTM流程，自动化测试规模开展

2006~2007年左右PTM趋于完善

注：上图中各个TR点的含义如下：

     

     

     

     

     

     

HLD：概要设计文档；

LLD：详细设计文档；

1. UT

单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。

UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。

单元测试比较适合开发人员做。

2.IT

集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。

IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。

IT可以由开发人员做，也可以由测试人员做。不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。

3.ST

CMM定义的系统测试：系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。

4.BBIT

BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。

以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。

5.SDV

SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。

6.SIT

SIT也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。

7.SVT

SVT是验收测试，其测试对象是产品包需求OR。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。

即使是网页开发项目，外包项目，终端的项目，华为的测试仍然会经历以下几个测试阶段：

SIV：System Integration Verify 系统集成验证

SDV：System design Verify 系统设计验证

SIT：System Integration Test 系统集成测试

SVT：System Verification Test 系统确认测试（系统模拟测试）

迭代结束后，在正式对外发布前，会将历次迭代实现的所有Story再做一次测试，测试 的主体在测试人员，包括功能、非功能，并要给出测试报告。这个活动就称为SIT或发布测试。

如果Story 测试、迭代SDV测试都自动化了，则本次测试主要是执行自动化用例、如前 面有测试不充分，则补充测试，以及详细性能测试。如果用例自动化程度不高，则本次测试会 刷选部分用来进行测试。测试结束后需要给出测试报告。

SIT测试重点：所有迭代开发完成后，由迭代开发团队中的测试人员完成对全系统进行回归测试，达到TR4A的质量标准。遗留问题要满足TR5的DI（缺陷密度）目标。

4) 集团军时代：IPD-RD-I&V阶段

2008年左右开始推广敏捷，研发组织演变为PDU方式

引进迭代开发模式，形成IPD-RD-I&V流程

系统集成与验证流程：IPD-RD-I&V(I&V：Integrationand Verification)

     

     

     

     

     

     

项目管理论坛

《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和系统工程师，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。

项目管理者联盟

待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和系统工程师，返回评审结果。测试组长组织测试成员修改测试方案，直到评审通过后才进入下个阶段――编写测试用例。

测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开发人员，测试人员，系统工程师的评审，测试组长也需要组织测试人员对测试用例进行修改，直到评审通过。

在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。

修改问题单，直到满足规定的缺陷密度，才能够通过相关TR点。

如果验收发现的缺陷率在SOW规定的范围内，那么验收成功。如果超过规定的缺陷率，需要质量回溯。

雷军说：

     

     

     

     

     

     

那么我们看华为的硬件测试过程，就知道成本出在哪里了。

第一、 全程测试参与的流程：

     

     

     

     

     

     

第二、 多层级的测试与试验

对于电路的设计，会进行单元测试、整机测试、小批量试制、HALT试验、环境试验、EMC试验、热测试、进入生产环节之后会进行HASS试验。特殊的设备还会进行盐雾试验、硫化试验。整机结构还会进行：跌落试验、挤压、扭曲等等。

HALT（Highly accelerated life test）高加速寿命试验。HALT是一种发现缺陷的工序，它通过设置逐级递增的加严的环境应力，来加速暴露试验样品的缺陷和薄弱点，而后对暴露的缺陷和故障从设计、工艺和用料等诸方面进行分析和改进，从而达到提升可靠性的目的，最大的特点是设置高于样品设计运行限的环境应力，从而使暴露故障的时间大大短于正常可靠性应力条件下的所需时间。

环境试验是为了保证产品在规定的寿命期间，在预期的使用，运输或贮存的所有环境下，保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用，以评价产品在实际使用，运输和贮存的环境条件下的性能，并分析研究环境因素的影响程度及其作用机理。

HASS应用于产品的生产阶段，以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。

硬件工程师最怕HALT试验，因为会超越器件的限制范围去进行测试。但是为什么要这么做呢，其实是找到整个设备的最薄弱点，然后对最薄弱点进行改进。但是由于超出了器件的允许的工作范围，异常的情况特别多，原因也复杂。但是按照规范必须分析清楚，并给出优化措施。这是非常烧脑的意见事情，很多经典的问题都是HALT试验过程中产生的。

由于我本人非测试出生，有讲的不对的地方请专家指正。现在小米开始不复当年风光了，想到雷军的5%，就写下这些。