? ? 理想情況下，一個完美的開發(fā)過程是測試先行，在一行代碼都沒有編寫前，就思考如何測試即將要編寫的代碼。理想情況下，需要兩種開發(fā)工程師：功能開發(fā)人員和測試開發(fā)人員。前者的思維模式是創(chuàng)建，主要關(guān)注用戶、使用場景和數(shù)據(jù)流程；后者的思維模式是破壞，重點在如何寫代碼用以擾亂數(shù)據(jù)。理想情況下，產(chǎn)品的每個功能對應(yīng)一個開發(fā)，整個產(chǎn)品配備一定數(shù)量的測試開發(fā)，另外，整個產(chǎn)品還需要一些面向用戶的測試人員。
? ? SET一部分職責是在單元測試方面給開發(fā)人員支持，另一部分職責是為開發(fā)人員提供測試框架，方便他們編寫中小型測試。
? ? 1.SET的工作
? ? 1）開發(fā)和測試流程
? ? 單一的代碼庫，所有的源代碼對每個人都是開放的，每個人都可以修改別人的代碼，但要遵守一些規(guī)則。另外，最小化對平臺的依賴。每個工程師的機器、系統(tǒng)、工具、編譯器盡量保證和線上一致。
? ? 一個版本的構(gòu)建流程：
? ? a）寫功能函數(shù)，編譯通過，并將它的構(gòu)建目標設(shè)定為公共庫
? ? b）針對a)寫一套單元測試用例，并創(chuàng)建一個測試構(gòu)建目標
? ? c）構(gòu)建并運行測試目標，修改調(diào)整，直到所有的測試運行成功
? ? d）運行靜態(tài)分析工具，保證代碼風格等的正確性
? ? e）提交代碼審核，根據(jù)反饋修改，并運行單元測試，審核通過后，提交代碼
? ? 2）SET究竟是誰？
? ? SET工作的有趣之處在于他們不是通過“質(zhì)量模式”和“測試計劃”介入到開發(fā)流程中，而是通過參與設(shè)計和代碼開發(fā)的方式。測試是產(chǎn)品的另外一種功能，而SET就是這個功能的負責人。
? ? 3）項目的早期階段
? ? 只有在軟件產(chǎn)品變的重要的時候質(zhì)量才顯得重要。明顯，在試驗初期階段強調(diào)測試是一件非常愚蠢的事情。因此，一些來源于團隊20%的業(yè)余時間投入的產(chǎn)品，在早期原型階段，主要精力在于試驗并證明這些想法的可行性。一旦項目得到正式批準立項，開發(fā)總監(jiān)就會找測試資源。他們在尋求測試幫助時，會介紹他們的項目、進度、發(fā)布計劃、當前已有的測試狀態(tài)、期望的單元測試覆蓋率水平、以及明確在發(fā)布過程中各自承擔的責任。
? ? 4）團隊結(jié)構(gòu)
? ? SWT一般僅在自己的模塊領(lǐng)域里提供最優(yōu)方案，而一個好的SET不僅要具有寬廣的整體產(chǎn)品視野，而且在產(chǎn)品的整個生命周期里對產(chǎn)品及功能特性做充分理解。Google產(chǎn)品團隊最初由一個技術(shù)負責人和一個或更多的項目發(fā)起人組成。
? ? 5）設(shè)計文檔
? ? 最早期的項目設(shè)計文檔，包含項目的目標、背景、成員、系統(tǒng)設(shè)計，將來需要完成的工作清單，如果系統(tǒng)足夠大，還要有子系統(tǒng)設(shè)計文檔。設(shè)計文檔必須要經(jīng)過相關(guān)技術(shù)負責人的審核。SET在初期階段就加入項目，通常來說，代碼復(fù)用和模塊交互方面的設(shè)計由SET來做，而不是SWE。SWE在完成設(shè)計文檔的各部分后，SET會進行審核，一般審核以下要點：完整性、正確性、一致性、設(shè)計、接口與協(xié)議、測試。在SET與相應(yīng)的SWE一起溝通設(shè)計文檔時，關(guān)于測試的工作量以及各個角色之間如何共同參與測試，也會有一個比較正式的討論。
? ? 6）接口與協(xié)議
? ? 開發(fā)人員使用protocol buffer的描述語言來定義數(shù)據(jù)結(jié)構(gòu)，然后使用自動生成的源代碼。對于新項目而言，protocol buffer源碼通常是第一份源代碼。protocol buffer定義的接口與協(xié)議的代碼實現(xiàn)是要由SET來完成的，在系統(tǒng)真正搭建起來之前，集成測試的運行依賴于這些接口實現(xiàn)。
? ? 7）自動化計劃
? ? 自動化計劃中需要包含自動化、以及如何公開產(chǎn)品質(zhì)量方面的信息（測試結(jié)果和測試進度）給所有關(guān)心的人。自動化中如果包含所有端到端的測試用例是錯誤且難以維護的，需要構(gòu)建一個輕量級的自動化框架，控制mock系統(tǒng)的創(chuàng)建和執(zhí)行，SWE需要使用mock接口自測，保證提交的代碼永遠是正確的、干凈的。
? ? 8）可測試性
? ? Googler每個新開發(fā)人員提交代碼時需要提交CL（變更列表）以及所有變更的測試代碼，給具有審閱資格的SWE或SET審核，審核成功后，才能提交。在提交審查之前，會經(jīng)過一系列的自動化檢查。規(guī)模較大的團隊可利用提交隊列在同一個分支上開發(fā)。提交隊列的主要功能是保持“綠色”的構(gòu)建，即所有測試必須全部通過。
? ? 在早期，所有等待提交的CL必須逐個排隊，等待測試，如果測試通過則可以提交進代碼庫，但隨著項目規(guī)模和復(fù)雜度的上升，當有大量長時間運行的測試需要執(zhí)行時，CL在發(fā)送給提交隊列和CL真正被提交到源碼庫之間可能需要消耗數(shù)小時。因此，后來，允許所有等待的CL在互相隔離的前提下，并發(fā)地構(gòu)建并運行測試。這樣會有一些競爭條件的出現(xiàn)，但實際上很少發(fā)生。由此，保證進入代碼庫的代碼不會出現(xiàn)問題，不影響測試。
? ? 由于第二章內(nèi)容挺多了，暫且分為上、中、下三部分，以防消化不完~，上篇到此為止，中篇從 2.1.9（SET的工作流程：一個實例）開始~
? ? 上篇看完的整個感受是原來Google的SET遠比國內(nèi)很多公司所說的測試開發(fā)工程師做的事情要多很多，包含編碼、設(shè)計、寫設(shè)計文檔、審核、自動化等等，因此，需要的技能應(yīng)該比開發(fā)還多~
