華為內部硬件開發設計流程

2007年，以2年的工作經驗去一家小公司去面試。當時筆試完，對方對我很認可。但當時他說：“我需要招一個，在大公司待過的，最好知道硬件開發流程和規范的。雖然你題答得不錯，但是我們需要一個有豐富經驗的，最好在華為待過的。”

當時，我就在想“華為的規范和流程是啥樣的”。后來我去了華為，我把能想到的華為硬件開發的幾個不一樣的點，跟大家分享一下。

NO.1 文 檔，評 審，設 計

當時剛入職時，三個人做一個電路板。雖然電路復雜一些，還是有一些人力過剩的。所以，我就被安排去寫一個PCI轉UART的邏輯。

我當時是新員工，也急于表現自己，利用周末的時間，估計用了一周的時間，就寫完代碼，開始仿真了。我以為我的導師兼主管會表揚一下，結果沒有，他說：“你為什么沒有召集大家討論？然后再寫方案，評審？然后再動手寫代碼？”我當時是不理解的，覺得我一個人就搞定的事情，為啥要這樣勞師動眾？

后來反思過后發現了以下問題：

第一、 從主管的角度，不知道新員工的個人能力，你能把做的事情講清楚了，他才放心。

第二、 從公司的角度，有一套流程來保證項目的交付。那么則不再太依賴某個人的個人能力，任何一個人的離職，都不會影響項目的交付。這也是華為最了不起的地方，把復雜的項目拆得非常細碎，這樣不需要特別牛的人來交付項目。這是為什么華為的工程師的收入是思科的N分之一。

第三、 從效果角度，畢竟一個人的想法是有限的，把想法文檔化的過程，就是整理思路的過程；討論的過程，就是收集你自己沒有想到的過程。正式的評審，是大家達成意見的過程。提前討論，讓相關的人都參與到你的設計中，總比你設計完了，被別人指出一個致命的問題要強得多。

就是因為華為把一項工作拆散了，所以溝通，文檔，評審，討論，變得非常重要。這個工作模式的缺點，也是顯而易見，溝通成本高，工作效率低。

NO.2 硬件領域的人員構成

在華為內部里面，人員角色非常多。硬件的人是對產品開發階段，端到端負責的。做單板硬件工程師，可以涉獵最多的領域，同時也是工作內容最雜，接觸人最多，扯皮的最多的工種。

但是也因為有人專門負責畫PCB、EMC、電源、邏輯，原本硬件工程師應該做的領域。那么硬件工程師就武功盡廢，變成“連連線”。

其實不然，正是由于每個人都是一個小的領域，沒有人統領，所以一個好的硬件經理的作用非常的重要，是貫穿所有領域和全部流程的關鍵角色。正如原來華為內部論壇上有一個人比喻的，硬件工程師更像是處理器里面的“Cache”，是所有環節的中轉站。大公司把人的分工分的這么細，也是防止某一撥掌握了太多公司的核心技術，出去單搞了。

NO.3 華為的流程

其實華為的流程，很多人都知道IPD流程是從IBM來的，我個人理解：IPD流程已經在華為變種，結合了中國人的特點，華為的企業特點進行了變通和優化。如果華為僵硬的套用IBM的這套流程，也必定不會這么成功。

那么概括一下華為的硬件開發流程：

需求分析→總體設計→專題分析→詳細設計→邏輯詳設→原理圖→PCB→檢視→粘合邏輯→投板→生產試制→回板調試→單元測試→專業實驗→系統聯調→小批量試制→硬件穩定→維護。

流程的根本在于，這個環節做好了，再進入下一個環節。所有的環節其實跟其他公司并沒有太大的區別，只不過嚴格把握了進入下一個環節的考核條件。令硬件工程師最糾結的是“沒有個節點跟’投板’對應”。

華為支撐IPD流程的系統是PDM（又名爬的慢）

PDM的中文名稱為產品數據管理（Product DataManagement）。PDM是一門用來管理所有與產品相關信息（包括零件信息、配置、文檔、CAD文件、結構、權限信息等）和所有與產品相關過程（包括過程定義和管理）的技術。華為所有的器件資料，產品部件，工具，文檔，原理圖，PCB，邏輯代碼等都存在這個系統上。但是系統過于龐雜，其實比較難使用，跟服務器歸檔、SVN歸檔、也容易搞混淆。

NO.4 歸一化 1 器件歸一化

硬件工程師一般都能夠理解，在一個板子上面的，盡可能的選擇成本更低的器件，選擇更少種類的器件，便于集中采購，同時也便于加工。但是其他公司可能沒有對器件歸一化的工作做得那么細致和嚴格。

第一， 由于華為整個公司使用的器件種類非常的多，所以如果減小一個器件編碼，帶來的收益是十萬人民幣到幾百萬，而其他公司可能達不到這個高的收益。所以如果能減少一個編碼，寧愿選擇可能成本更高的器件。但是這個也需要按照每年的器件直接成本收益*器件發貨數量，與編碼成本+加工成本差異，進行對比的。不過器件歸一化之后，器件的價格又可以跟供應商重新談價格，這個收益是迭代的。所以，有時即使是成本占優，也會傾向去器件歸一化的結論。例如，逐步去除了5%精度的電阻，歸一化到1%。

第二， 器件歸一化，都是需要進行專題分析的。因為也有工程師為了歸一化，對電路原理沒有充分分析，導致的歸一化帶來“問題引入”。所以，當時我的部門當時有一個表格，“器件歸一化分析.xls”的excel表格，把每個器件，原來選型，歸一化的選型，更改的原因，都做好記錄和原因分析。一是讓每個做歸一化的員工都充分考慮分析，二是問題都有記錄，便于評審，三是出了問題，好打板子。

2 單板歸一化

除了器件歸一化，更高一個層次的歸一化，就是單板歸一化。（單板這個概念，我稍微澄清一下，我剛到華為的時候，也覺得這個詞很奇怪。因為通信設備，都是機框，背板，加各個功能模塊的電路板，各個功能模塊的電路就叫做“單板”，硬件工程師，一般也叫做“單板硬件”）

單板歸一化帶來的好處，首先是電路的種類少，電路的種類少的好處有三個：

一是生產成本降低；

二是硬件維護成本降低；

三是軟件開發和維護的成本降低。

第一、單板歸一化的先決條件首先是處理器歸一化。其實，華為的有的產品這點做得其實不好，X86、MIPS、ARM、PPC全部都用個遍，所以一個硬件平臺，需要配備各種軟件人員，操作系統搞N套，VxWorks和Linux，BIOS各種配套。

第二、單板的歸一化，要注意產品的衍生。第一個版本的機框上的單板所實現的功能，如果后續的產品可以使用，應該直接可以用，不需要再開發。如果不注意這點，第一個版本的單板，到第二版本時，發現不能相互借用。反過來，再修改第一個版本的電路板，來適應新版本。有時問題更糟糕，就是完全不能兼容，只好重新開發。單板的規劃顯得非常重要。

第三、單板歸一化時，雖然電路部分兼容了，但是結構件不兼容。對于市場人員的配置來說，仍然是兩種配置。一樣是失敗的。

3 平臺歸一化

那么如果發現不同的硬件平臺的架構雷同，功能類似。那么機框也可以歸一化。只需要制作不同的電路功能模塊，就可以實現不同的功能需求。

但是不同的硬件形態都是有他存在的意義的，如果強行歸一，市場未必會接受這種事情的發生。例如用一個運營商的平臺去歸一一個企業應用或者家庭應用的產品，可能就未必能夠成功。

4 網絡架構歸一化

這個說法是我自己想的，早在08年的時候，華為就在討論“云管端戰略”了，當時不是很理解。當我們一個運營商平臺部門，跟“服務器”的部門合并的時候，似乎理解了點什么。

當X86處理器足夠強大的時候，所有的運算，不管是否性價比最高，都送到云端進行處理，那么所有中間的存儲和計算都顯得不重要了。那么整個網絡的結構，就是終端+管道+云存儲和云計算。

NO.5專題分析

我覺得很多硬件工程師有個誤區，覺得自己的核心競爭力是在于會使用幾個軟件（cadence、Protel），畫畫原理圖，畫畫PCB。我早期的一份工作就這樣，最大的本事就是照葫蘆畫瓢，抄Demo板，抄以前成熟的電路，如果碰到了新的電路設計，一般是按照參考電路先畫出電路，再通過調試，去嘗試，碰到問題，再去解決問題。

那么我現在的觀念是，硬件工程師最值錢的地方是在于懂硬件原理，懂得電路分析，模電數電原理，電磁場理論，而不是會使用畫圖軟件。

那么華為是怎樣做電路設計的呢？為什么會有專題分析的說法呢？為什么電路設計的時候要做專題分析？

第二、當電路設計過程中，碰到一些新的問題，之前團隊中沒有接觸過的問題，或者認為是重點，難點的內容，會專門做這個問題點的專題分析：例如我們做過的一些雙BIOS啟動，攝像頭的紅外LED的驅動，主備倒換啊，之類的，就會把一個問題點分析透，然后再動手做畫原理圖。

第三、那么在開發硬件的時候，Demo只是作為參考，每一個依據都是來自于datasheet，除了看芯片的數據手冊之外，還要仔細查看數據手冊的勘誤表errata，核對datasheet與Demo的差一點，如果器件有checklist還得核對checklist。曾經開發AMD的時候，datasheet、Demo、checklist，三個文檔對不上的情況。也出現過，一個比較難復現的問題，后來查看了Errata，發現是廠家芯片升級了，修正了bug，而我們還在采購老版本的芯片。

第四、由于項目本身有交付時間要求，那么在有限時間內其實不可能做到每個問題點都做得深入透徹。那么問題來了：

是怎么做到的呢？首先，每個項目都有《問題跟蹤表》，而硬件團隊由于事情非常的雜，所以把這個表要用的非常好，不然丟東拉西很正常。我曾經把這個表應用到家里裝修。這個表的原理很簡單，就是記錄，問題內容，責任人，完成狀態，完成時間。但是只要你堅持用，你會發現，你問題不會跟蹤丟，做事情會比較有條理，而且會有成就感。用了這個表以后，發現問題之后，先記錄下來，即使現在不解決，那么也會識別他要不要解決，什么時候解決。其次、問題分優先級，任何項目都是帶著風險前進的，那么識別出高風險的問題，優先解決高風險的問題，帶著低風險的問題繼續走。這也是華為電路設計中“0歐姆”電阻用的比較多的有一個原因，識別出風險之后，但是又分析不清楚，或者來不及分析，只好做兼容設計。這里不得不感慨一句，在你的設計過程中，你馬虎對待，沒有分析清楚的問題，最后一定會暴露出來。

所以，在“菊花廠”做硬件工程師，“專題分析”是設計硬件最核心的工作，而不是畫原理圖。通過這個方法，用1~2個月做電路分析，而用1~2周時間畫原理圖，取代了，畫圖，調試，改版，再調試，在改版的形式。多快好省，是不可能同時實現的，那么硬件工程師有責任做很好的折衷和權衡。

NO.6 專題攻關：器件選型規范

一、關于“器件選型規范”：

在我進入華為的時候，當時整個公司都在“規范”運動，什么都寫規范，人人都寫規范，什么任職、績效、技術等級都看規范。（大公司用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、成本：如果在上述因素都不是致命的情況下——上述的因素都是浮云，緊盯第八條。

NO.7 開會

開會第一部分 “華為的會議”

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的工作是通過評審手段來決定項目是否能變更，但不提出變更方案。至少會保證，決策的決議是集體的智慧。)

NO.8 測試

1、從進度的角度對比華為和小米的測試

按照小米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規定的范圍內，那么驗收成功。如果超過規定的缺陷率，需要質量回溯。

2、不可思議的小米5%

雷軍說：

那么我們看華為的硬件測試過程，就知道成本出在哪里了。

第一、 全程測試參與的流程：

第二、 多層級的測試與試驗

對于電路的設計，會進行單元測試、整機測試、小批量試制、HALT試驗、環境試驗、EMC試驗、熱測試、進入生產環節之后會進行HASS試驗。特殊的設備還會進行鹽霧試驗、硫化試驗。整機結構還會進行：跌落試驗、擠壓、扭曲等等。

HALT（Highly accelerated life test）高加速壽命試驗。HALT是一種發現缺陷的工序，它通過設置逐級遞增的加嚴的環境應力，來加速暴露試驗樣品的缺陷和薄弱點，而后對暴露的缺陷和故障從設計、工藝和用料等諸方面進行分析和改進，從而達到提升可靠性的目的，最大的特點是設置高于樣品設計運行限的環境應力，從而使暴露故障的時間大大短于正常可靠性應力條件下的所需時間。

環境試驗是為了保證產品在規定的壽命期間，在預期的使用，運輸或貯存的所有環境下，保持功能可靠性而進行的活動。是將產品暴露在自然的或人工的環境條件下經受其作用，以評價產品在實際使用，運輸和貯存的環境條件下的性能，并分析研究環境因素的影響程度及其作用機理。

HASS應用于產品的生產階段，以確保所有在HALT中找到的改進措施能夠得已實施。HASS還能夠確保不會由于生產工藝和元器件的改動而引入新的缺陷。

硬件工程師最怕HALT試驗，因為會超越器件的限制范圍去進行測試。但是為什么要這么做呢，其實是找到整個設備的最薄弱點，然后對最薄弱點進行改進。但是由于超出了器件的允許的工作范圍，異常的情況特別多，原因也復雜。但是按照規范必須分析清楚，并給出優化措施。這是非常燒腦的意見事情，很多經典的問題都是HALT試驗過程中產生的。

由于我本人非測試出生，有講的不對的地方請專家指正。現在小米開始不復當年風光了，想到雷軍的5%，就寫下這些。

責任編輯：lq