【正文】 爭期間奉命主持一個地方教會的會議。這個會開了比不開還要糟糕。很難在短時間內(nèi)靠語言交流說服對方。他把這個研究當作一個戰(zhàn)爭一樣。他自費出版買了一千本到處送人。墨水瓶，板凳也不亂飛了。跑得沒個邊了。也有從來不講話的。甚至打起來。但是一般的企業(yè)往往，領導出現(xiàn)的時候，主持人是不會去提醒領導，“你跑題了”，“你一言堂了”，“你不應該打斷別人的正常發(fā)言”，這就是國外的科學的一些理論和方法到了中國往往不適應中國的土壤，不能生搬硬套的典型案例。那么華為是怎么去解決這些問題的呢？“以客戶為中心”，所以領導再大，大不過客戶，客戶需求一律允諾，一律搞定。否則造成重大嚴重后果后，領導跑不掉，一樣會修理底下的人。 教育主管。第三部分 減少無效會議我曾經(jīng)支持過CCB的網(wǎng)絡建設一段時間，當時剛去的時候，跟他們的IT規(guī)劃部，開了一個會。一言堂、跑題、不文明，這些都不是致命的，最致命的就是“無效會議”。例如周會，一周例會的議題做事先的安排，不是很隨意的說一下。第三、 會議紀要要分為：結論（會議結論不隨意更改）；遺留問題（要符合SMART原則）；要有責任人；要求完成的時間等等。第五、 所有的決議都是需要有理有據(jù)的，不能是拍腦袋。 當然，這樣的話就會存在效率問題，因為有些問題就會因為短時間研究不清楚，決策不下來。CCB由項目所涉及的多方成員共同組成，通常包括用戶和實施方的決策人員。上圖是小米UI的一周進度圖。那么我們來看一下華為的測試流程，你就知道是否可以壓縮到一天完成相關的測試。華為的測試體系在國內(nèi)算是起步較早,大概經(jīng)歷了這樣幾個階段:1) 青銅器時代: 手工作坊式測試1996年研發(fā)測試團隊成立手工作坊方式的研發(fā)過程和測試2) 鐵器時代：IPD和CMM階段1998年華為與IBM合作，開始引進IPD流程1999年左右引入CMM理念產(chǎn)生IPDCMMI流程函數(shù)是產(chǎn)品開發(fā)實現(xiàn)的最基本單位，下一個實現(xiàn)單位是模塊，從測試的角度看，希望UT完成后，每個函數(shù)都牢固可靠，下一步的IT測試將聚焦在函數(shù)之間配合能否實現(xiàn)分配需求，而不用擔心函數(shù)本身的輸入輸出響應問題。IT的目的，是根據(jù)模塊設計對模塊的分解，從已驗證的函數(shù)開始，逐層向上集成，得到一個可運行的模塊。主要采用的測試方法是黑盒測試，即不管程序內(nèi)部的實現(xiàn)邏輯，以檢驗輸入輸出信息是否符合規(guī)格說明書中有關需求規(guī)定的測試方法。BBIT為模塊間接口測試，驗證模塊之間的接口能不能配合，有時和聯(lián)調(diào)混在一起，其實目的并不相同。以上UT/IT/MST/BBIT一般由開發(fā)人員完成，系統(tǒng)基本可以運行起來了，測試人員可以開展SDV、SIT、SVT了。SVT是驗收測試，其測試對象是產(chǎn)品包需求OR。如果Story 測試、迭代SDV測試都自動化了，則本次測試主要是執(zhí)行自動化用例、如前 面有測試不充分，則補充測試，以及詳細性能測試。遺留問題要滿足TR5的DI（缺陷密度）目標。V(Iamp。項目管理者聯(lián)盟待開發(fā)人員把《SRS》歸納好并打了基線，測試組長開始組織測試成員編寫《測試方案》，測試方案要求根據(jù)《SRS》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。同樣，測試用例也需要通過開發(fā)人員，測試人員，系統(tǒng)工程師的評審，測試組長也需要組織測試人員對測試用例進行修改，直到評審通過。否則，軟件轉測試部進行系統(tǒng)測試。修改問題單，直到滿足規(guī)定的缺陷密度，才能夠通過相關TR點。那么華為的成本花到哪里去了呢？那么我們看華為的硬件測試過程，就知道成本出在哪里了。第二、 多層級的測試與試驗對于電路的設計，會進行單元測試、整機測試、小批量試制、HALT試驗、環(huán)境試驗、EMC試驗、熱測試、進入生產(chǎn)環(huán)節(jié)之后會進行HASS試驗。HALT是一種發(fā)現(xiàn)缺陷的工序，它通過設置逐級遞增的加嚴的環(huán)境應力，來加速暴露試驗樣品的缺陷和薄弱點，而后對暴露的缺陷和故障從設計、工藝和用料等諸方面進行分析和改進，從而達到提升可靠性的目的，最大的特點是設置高于樣品設計運行限的環(huán)境應力，從而使暴露故障的時間大大短于正?？煽啃詰l件下的所需時間。HASS還能夠確保不會由于生產(chǎn)工藝和元器件的改動而引入新的缺陷。但是按照規(guī)范必須分析清楚，并給出優(yōu)化措施。由于我本人非測試出生，有講的不對的地方請專家指正。但是為什么要這么做呢，其實是找到整個設備的最薄弱點，然后對最薄弱點進行改進。是將產(chǎn)品暴露在自然的或人工的環(huán)境條件下經(jīng)受其作用，以評價產(chǎn)品在實際使用，運輸和貯存的環(huán)境條件下的性能，并分析研究環(huán)境因素的影響程度及其作用機理。整機結構還會進行：跌落試驗、擠壓、扭曲等等。如果超過規(guī)定的缺陷率，需要質(zhì)量回溯。待到開發(fā)修改完bug并轉來新的測試版本，測試部開始進行第二輪的系統(tǒng)測試，首先回歸完問題單，再繼續(xù)進行測試，編寫第二輪的測試報告，如此循環(huán)下去，直到系統(tǒng)測試結束。轉測試部后直接進行系統(tǒng)測試。其中操作步驟和預期結果需要編寫詳細和明確。測試組長組織測試成員修改測試方案，直到評審通過后才進入下個階段――編寫測試用例。項目經(jīng)理編寫《項目計劃》，開發(fā)人員產(chǎn)出《SRS》，這時測試組長就要根據(jù)SOW開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內(nèi)容。V階段2008年左右開始推廣敏捷，研發(fā)組織演變?yōu)镻DU方式引進迭代開發(fā)模式，形成IPDRDIamp。測試結束后需要給出測試報告。即使是網(wǎng)頁開發(fā)項目，外包項目，終端的項目，華為的測試仍然會經(jīng)歷以下幾個測試階段：SIV：System Integration Verify 系統(tǒng)集成驗證SDV：System design Verify 系統(tǒng)設計驗證SIT：System Integration Test 系統(tǒng)集成測試SVT：System Verification Test 系統(tǒng)確認測試（系統(tǒng)模擬測試）迭代結束后，在正式對外發(fā)布前，會將歷次迭代實現(xiàn)的所有Story再做一次測試，測試 的主體在測試人員，包括功能、非功能，并要給出測試報告。SIT也是驗證設計需求是否得以滿足，與SDV不同的是，SIT完全把系統(tǒng)當作一個黑盒來測試，不關心內(nèi)部具體的實現(xiàn)。而聯(lián)調(diào)一般涉及軟件、硬件或者不同產(chǎn)品間的配合測試。模塊SRS文檔給出了模塊的輸入輸出的相應要求。不難看出，UT是面向每一個單元的測試，IT是測試單元之間的接口，可以把UT/IT歸為“單元級”測試。集成測試是指把若干個經(jīng)過單元測試的單元組裝到一起而進行的測試，集成測試應依據(jù)HLD，主要發(fā)現(xiàn)接口、依賴中的錯誤或不完善的地方。該測試對象可能由一個或多個函數(shù)或者類組成，測試設計就是對測試對象進行測試用例設計。也可能華為的拆解需求的能力弱于小米，但是這里我們單純談測試流程。我按照華為的流程怎么套都套不出來。至少會保證，決策的決議是集體的智慧。典型的變更控制委員會會同樣決定在哪一些版本中