提到敏捷交付，我們總會(huì)說(shuō)到持續(xù)集成，持續(xù)交付，持續(xù)發(fā)布，即頻繁地交付產(chǎn)品特性。而我們都知道要實(shí)現(xiàn)真正的持續(xù)交付，必然少不了兩個(gè)關(guān)鍵要素：

• 持續(xù)集成工具
• 自動(dòng)化測(cè)試 ， 自動(dòng)化的產(chǎn)品質(zhì)量反饋機(jī)制

只有測(cè)試不行，只有集成工具也不行，二者需合二為一，保持相同的步調(diào)，實(shí)現(xiàn)持續(xù)不斷的質(zhì)量反饋，方能實(shí)現(xiàn)保質(zhì)地持續(xù)發(fā)布。

自動(dòng)化測(cè)試不只自動(dòng)化工具

可以開(kāi)門(mén)見(jiàn)山地說(shuō)：Automation Test ≠ Automation Tools ≠ Continuous Test

根據(jù)我個(gè)人的項(xiàng)目經(jīng)驗(yàn)，試著畫(huà)了下面這個(gè)圖來(lái)表達(dá)這三者的關(guān)系。

在提及自動(dòng)化測(cè)試的時(shí)候，很多人會(huì)把工具的使用等同于自動(dòng)化測(cè)試。自動(dòng)化測(cè)試應(yīng)該是一個(gè)策略性的系統(tǒng)工程，不只有自動(dòng)化工具。像我們的產(chǎn)品一樣，不僅要有技術(shù)語(yǔ)言，還要有產(chǎn)品架構(gòu)設(shè)計(jì)。自動(dòng)化測(cè)試除了工具框架，還需要考慮：

項(xiàng)目的技術(shù)棧，產(chǎn)品架構(gòu)，開(kāi)發(fā)流程，基礎(chǔ)設(shè)施，可靠的測(cè)試數(shù)據(jù)，穩(wěn)定干凈的測(cè)試環(huán)境，如何呈現(xiàn)測(cè)試報(bào)告，如何工程化測(cè)試配置，測(cè)試套件等等。

有了自動(dòng)化測(cè)試還不夠，我們的目的是在持續(xù)交付的過(guò)程中實(shí)現(xiàn)快速頻繁的質(zhì)量反饋，我們需要持續(xù)不斷地測(cè)試（Continous Testing)。實(shí)現(xiàn)持續(xù)測(cè)試，不僅需要團(tuán)隊(duì)從文化上去支持，真正做到全員對(duì)測(cè)試和質(zhì)量負(fù)責(zé)，創(chuàng)建Devops文化氛圍，打通開(kāi)發(fā)-測(cè)試-運(yùn)維的壁壘；還需團(tuán)隊(duì)從技術(shù)上去儲(chǔ)備知識(shí)，比如云平臺(tái)、虛擬化技術(shù)，容器及相應(yīng)的編排技術(shù)，甚至網(wǎng)絡(luò)知識(shí)等等。

維基百科對(duì)自動(dòng)化的解釋：

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.

從定義可以總結(jié)出自動(dòng)化測(cè)試的兩個(gè)特點(diǎn)：

• 自動(dòng)化測(cè)試本身也是軟件
• 自動(dòng)化測(cè)試基于預(yù)期結(jié)果進(jìn)行斷言

測(cè)試，質(zhì)量評(píng)估的重要手段之一，而自動(dòng)化測(cè)試只是測(cè)試的一種具體實(shí)現(xiàn)方式而已。它能釋放QA的雙手和一部分大腦（這部分大腦，即know knowns），將對(duì)已知特性和既定邏輯流程的檢測(cè)交由計(jì)算機(jī)來(lái)完成。而QA去做更多需要思辨能力，分析判斷能力的事情。例如，通過(guò)向團(tuán)隊(duì)提問(wèn)，來(lái)澄清需求的unknowns；通過(guò)探索產(chǎn)品去拓寬對(duì)產(chǎn)品的knowns；抑或運(yùn)用經(jīng)驗(yàn)幫助團(tuán)隊(duì)走出Unknown Unknowns 帶來(lái)的迷局。

維基百科對(duì)持續(xù)測(cè)試的解釋：

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

從這個(gè)定義可以看出，持續(xù)測(cè)試的目的即在軟件交付的流水線中執(zhí)行自動(dòng)化測(cè)試以提供對(duì)產(chǎn)品質(zhì)量的反饋。

想強(qiáng)調(diào)定義里的幾個(gè)關(guān)鍵字：automated tests, delivery pipeline, immediate feedback, business risks.

• automated tests 而不是automated test，一個(gè)產(chǎn)品只有一種，或者某一層級(jí)上的自動(dòng)化測(cè)試是無(wú)法達(dá)到整體質(zhì)量評(píng)估的，持續(xù)測(cè)試需要不同類型的自動(dòng)化測(cè)試在交付的不同階段為產(chǎn)品的不同層級(jí)提供反饋。
• delivery pipeline，immediate feedback，自動(dòng)化測(cè)試一定是和交付流水線交合集成的，至少是同頻運(yùn)行的，不是孤立的，只有這樣才能就團(tuán)隊(duì)每一次的新變更對(duì)產(chǎn)品質(zhì)量的影響做出快速而及時(shí)的反饋。
• business risks，持續(xù)測(cè)試廣義上來(lái)說(shuō)包含交付中的所有質(zhì)量反饋行為，既要測(cè)試左移，質(zhì)量?jī)?nèi)建，也要測(cè)試右移，實(shí)現(xiàn)產(chǎn)品質(zhì)量主動(dòng)監(jiān)控，不然無(wú)法識(shí)別業(yè)務(wù)風(fēng)險(xiǎn)。

測(cè)試工具的選擇需要考慮項(xiàng)目的技術(shù)棧，也需要考慮QA自身的技術(shù)能力。

不管多火的工具，如果不能兼容項(xiàng)目的技術(shù)棧和基礎(chǔ)設(shè)施，那都無(wú)處發(fā)揮其優(yōu)勢(shì)，流行的不一定是適合項(xiàng)目的。

在寫(xiě)自動(dòng)化之前，QA需要對(duì)項(xiàng)目的技術(shù)棧，開(kāi)發(fā)流程，和基礎(chǔ)設(shè)施有基本的認(rèn)識(shí)和了解；另外也需要了解和掌握各個(gè)工具之間的優(yōu)劣，這樣才能為項(xiàng)目選擇最匹配的自動(dòng)化工具。是不是像老生常談？但是別人告訴你的經(jīng)驗(yàn)和自己經(jīng)歷的實(shí)戰(zhàn)真的兩種不同的收獲。就跟蹲家看電視和去現(xiàn)場(chǎng)看演唱會(huì)的區(qū)別一樣，別人的經(jīng)驗(yàn)之談總歸是別人的，自己走過(guò)的路才是自己的。

這兩年Cypress真的很火，去年在項(xiàng)目上做UI自動(dòng)化測(cè)試的時(shí)候，出于好奇也想實(shí)踐一把。實(shí)踐出真知，Cypress本身可以通過(guò)環(huán)境變量和plugin配置代理，但是不支持socks5的代理（客觀現(xiàn)狀是項(xiàng)目所有資產(chǎn)，包括測(cè)試環(huán)境都是通過(guò)socks5的代理連接），線上環(huán)境無(wú)法訪問(wèn)。當(dāng)時(shí)還試過(guò)將socks5的代理轉(zhuǎn)換成http代理，但因?yàn)镃ypress本身是多線程的，而socks5只能截獲第一個(gè)進(jìn)程的網(wǎng)絡(luò)通信， 即使能連通應(yīng)用本身，Cypress也無(wú)法將測(cè)試過(guò)程可視化的優(yōu)勢(shì)發(fā)揮出來(lái)。人無(wú)完人，工具也一樣，只有適合你的才是好的。

考慮自己也不會(huì)造輪子，喜歡拿來(lái)就用，加之項(xiàng)目上socks5代理約束，之后便轉(zhuǎn)用了CodeceptJS, 幾次嘗試下來(lái)，覺(jué)得非常滿足項(xiàng)目需要。下面羅列CodeceptJS 幾個(gè)好用的點(diǎn)，具體細(xì)節(jié)請(qǐng)移步官網(wǎng)。

• 支持不同的helper: WebDriver, Puppeteer, Protractor, Nightmare, Testcafe， 我在項(xiàng)目上選用的是Puppeteer。
• 支持web也支持mobile，當(dāng)時(shí)項(xiàng)目上的第一個(gè)產(chǎn)品是有手機(jī)端版本的， 這也是選擇這個(gè)工具的一個(gè)考慮。
• 封裝良好的頁(yè)面元素操作方法，拿來(lái)即用，對(duì)于不擅長(zhǎng)編碼的我來(lái)說(shuō)，非常友好。
• 因?yàn)轫?xiàng)目產(chǎn)品是和礦場(chǎng)上爆破緊密相關(guān)的，很多產(chǎn)品都有礦場(chǎng)地圖展示和設(shè)備可視化，CodeceptJS 提供了現(xiàn)成的codeceptjs-resemblehelper以實(shí)現(xiàn)視覺(jué)上的回歸測(cè)試。
• 最近發(fā)現(xiàn)它還支持API測(cè)試，包括REST和GraphQL的， 但是這部分特性尚未實(shí)踐。

由于團(tuán)隊(duì)有完全的自由來(lái)選擇技術(shù)棧，在做第三個(gè)產(chǎn)品的時(shí)候， 我們的開(kāi)發(fā)小哥哥就已經(jīng)不滿足于只寫(xiě)REST API了，第三個(gè)產(chǎn)品開(kāi)始引入GraphQL。在以前的項(xiàng)目上用過(guò)REST Assured 做API測(cè)試，覺(jué)得也是好用的，但當(dāng)時(shí)并沒(méi)有選用REST Assured, 因?yàn)樵谀菚r(shí)，剛好發(fā)現(xiàn)一枚ThouhgtWorks開(kāi)發(fā)自己做的API功能測(cè)試工具 Pandaria。（這也從側(cè)面證明TW的開(kāi)發(fā)很有質(zhì)量意識(shí)）選擇這個(gè)工具，除了自己不會(huì)造輪子，除了它支持代理，更重要的是它基于Cucumber JVM，我個(gè)人以前的項(xiàng)目上用過(guò)cucumber，對(duì)gherkin語(yǔ)法還算熟悉，還有它能提供漂亮的測(cè)試報(bào)告。它既支持REST API的測(cè)試，也支持GraphQL 的測(cè)試，完美匹配我個(gè)人的技術(shù)和項(xiàng)目的實(shí)際情況。

選擇合適的時(shí)候做自動(dòng)化, 避免不必要的浪費(fèi)。

在項(xiàng)目做第一個(gè)規(guī)范安全流程的產(chǎn)品時(shí)，MVP1(Minimum Viable Product) 一完成，該產(chǎn)品的接口自動(dòng)化測(cè)試和端到端自動(dòng)化測(cè)試便實(shí)現(xiàn)了，并集成到了產(chǎn)品CI/ CD 流水線上。后來(lái)由于客戶方硬件集成的問(wèn)題，該產(chǎn)品基于MVP1進(jìn)行了一次演進(jìn)，從產(chǎn)品直接融入并規(guī)范安全流程換成了‘曲線救國(guó)’地強(qiáng)化安全流程，頁(yè)面和接口設(shè)計(jì)也有較大變動(dòng)。由于產(chǎn)品流程設(shè)計(jì)上的變動(dòng)導(dǎo)致之前的接口測(cè)試和端到端的自動(dòng)化測(cè)試全部都失效，需要重新編寫(xiě)和維護(hù)。

這個(gè)經(jīng)歷挺真實(shí)的，自動(dòng)化是有好處，但是也是有代價(jià)的： 在MVP1，特別是POC（Proof Of Concept)階段的產(chǎn)品建議不要急于做自動(dòng)化，項(xiàng)目的初期更別嘗試做UI層面的自動(dòng)化。當(dāng)然對(duì)工具的spike是可以的，把框架搭建好，等待特性穩(wěn)定了，就可以直接加測(cè)試用例了。

我們選擇自動(dòng)化一定是要考慮項(xiàng)目是否存在客觀的現(xiàn)實(shí)需求，在動(dòng)手實(shí)施具體的自動(dòng)化測(cè)試之前，一定要對(duì)自動(dòng)化測(cè)試的投入產(chǎn)出比做一次客觀理性地評(píng)估。如上圖所示，自動(dòng)化測(cè)試的成本相對(duì)單次（或者少量的）手動(dòng)測(cè)試來(lái)說(shuō)是較高的，為了少量的測(cè)試活動(dòng)而做自動(dòng)化，投入產(chǎn)出比是很低的。需要QA根據(jù)項(xiàng)目進(jìn)度，產(chǎn)品演進(jìn)程度，測(cè)試策略，回歸頻率等等做一個(gè)綜合評(píng)估，找到出圖中交集的點(diǎn)，即何時(shí)何種情況團(tuán)隊(duì)和產(chǎn)品應(yīng)該必須引入自動(dòng)化測(cè)試了。因?yàn)樽詣?dòng)化前期需要投入產(chǎn)品分析，工具框架選型，用例設(shè)計(jì)，數(shù)據(jù)環(huán)境準(zhǔn)備等等，后期還需要持續(xù)不斷地投入人力進(jìn)行及時(shí)的維護(hù)和更新以保證自動(dòng)化測(cè)試的嚴(yán)密性和足夠的覆蓋率。

自動(dòng)化測(cè)試和產(chǎn)品代碼一樣重要，需要全員負(fù)責(zé)。

雖然敏捷強(qiáng)調(diào)質(zhì)量全員負(fù)責(zé)，但我所待過(guò)的團(tuán)隊(duì)，做過(guò)的項(xiàng)目，踐行得好的很少。幸運(yùn)的是，現(xiàn)在團(tuán)隊(duì)的質(zhì)量意識(shí)都很好。但故事一開(kāi)始不都是美好的，每個(gè)團(tuán)隊(duì)都是在 “掉坑-反饋-調(diào)整磨合” 的循環(huán)里走向成熟的。

在交付一個(gè)微服務(wù)化的產(chǎn)品時(shí)，后端多個(gè)API，每個(gè)API有相應(yīng)的API集成測(cè)試，產(chǎn)品還有UI測(cè)試，同時(shí)團(tuán)隊(duì)還有額外的3個(gè)產(chǎn)品需要維護(hù)。每個(gè)產(chǎn)品都有自動(dòng)化測(cè)試，前端的后端的。其中一個(gè)微服務(wù)實(shí)現(xiàn)的產(chǎn)品就有四套測(cè)試，而且后續(xù)還會(huì)增加視覺(jué)測(cè)試。

在剛開(kāi)始的時(shí)候，測(cè)試掛了沒(méi)人去看，也沒(méi)人去修。由于項(xiàng)目是基于Trunk Based Development，為了保證測(cè)試的及時(shí)性，每天不是在加新用例的路上，就是在修各種測(cè)試的路上。UI測(cè)試相較于API測(cè)試更為脆弱，需要頻繁的維護(hù)成本，特別是項(xiàng)目基于主干開(kāi)發(fā)的團(tuán)隊(duì)。那段時(shí)間感覺(jué)自己成了automation engineer，對(duì)產(chǎn)品新增的功能特性并不是非常清楚，對(duì)故事卡的可測(cè)性也沒(méi)及時(shí)作出反饋，感覺(jué)自動(dòng)化并未真的達(dá)到釋放自己精力和時(shí)間的初衷。

如果只是QA一個(gè)人來(lái)維護(hù)管理，那么這個(gè)QA一定做不了自動(dòng)化以外的事情了。ThoughtWorks好多項(xiàng)目都只有一個(gè)QA，我們的這個(gè)QA是Quality Analyst， 并不是Automation Engineer。敏捷項(xiàng)目之下，QA的首要任務(wù)應(yīng)該是驅(qū)動(dòng)團(tuán)隊(duì)各個(gè)角色對(duì)質(zhì)量負(fù)責(zé)。

為了提升團(tuán)隊(duì)對(duì)自動(dòng)化測(cè)試的重視程度， 如下是一些我個(gè)人在項(xiàng)目上實(shí)踐過(guò)的方法：

• 為每套自動(dòng)化測(cè)試編寫(xiě)清晰的README, 保證團(tuán)隊(duì)里除你以外其他的小伙伴，也都清楚明白如何運(yùn)行自動(dòng)化測(cè)試。
• 除了實(shí)用的README引導(dǎo)團(tuán)隊(duì)如何運(yùn)行測(cè)試，可視化良好的測(cè)試報(bào)告也非常必要。如下是我們項(xiàng)目上的測(cè)試報(bào)告：

• 讓UI測(cè)試更穩(wěn)定，請(qǐng)求開(kāi)發(fā)把頁(yè)面的關(guān)鍵組件元素加上ID 屬性，用唯一的ID去定位元素就穩(wěn)定多了。
• 建議每個(gè)Dev提交代碼前，在本地自行運(yùn)行測(cè)試腳本，保證自動(dòng)化測(cè)試的及時(shí)性和正確性，并對(duì)新變更提供及時(shí)的質(zhì)量反饋。

除了以上，項(xiàng)目還需要有高度可視化或者能及時(shí)通知測(cè)試狀態(tài)的方式。

項(xiàng)目上用的是Jenkins自帶的 Build Monitor View。將對(duì)項(xiàng)目pipeline的監(jiān)控投影到電視上，并配置相應(yīng)的提示音，能非常及時(shí)地讓團(tuán)隊(duì)知道最新的構(gòu)建，部署，測(cè)試狀態(tài)。

如下是我們項(xiàng)目上當(dāng)前的一個(gè)流水線dashboard：

這些實(shí)踐都是對(duì)‘質(zhì)量全員負(fù)責(zé)’最落地的踐行。我相信，每個(gè)團(tuán)隊(duì)是不一樣的，但是敏捷QA的主要價(jià)值一定是能驅(qū)動(dòng)團(tuán)隊(duì)為質(zhì)量作出改進(jìn)和貢獻(xiàn)。

敏捷QA是對(duì)項(xiàng)目流程質(zhì)量，產(chǎn)品內(nèi)部質(zhì)量，產(chǎn)品外部質(zhì)量都需要負(fù)責(zé)的，而自動(dòng)化測(cè)試只是質(zhì)量保證的一種措施而已而非唯一措施。‘質(zhì)量全員負(fù)責(zé)’的團(tuán)隊(duì)才能釋放出你們的QA，去做更多Quality Analysis的工作，比如提更多需要思辨能力的問(wèn)題以實(shí)現(xiàn)產(chǎn)品風(fēng)險(xiǎn)的識(shí)別和管理，反思開(kāi)發(fā)流程以促進(jìn)團(tuán)隊(duì)流程質(zhì)量的提升，分析產(chǎn)品架構(gòu)制定適合項(xiàng)目產(chǎn)品的整體測(cè)試策略等等。

持續(xù)測(cè)試除了自動(dòng)化測(cè)試還需要QA和團(tuán)隊(duì)具備Devops相關(guān)的技術(shù)。

在項(xiàng)目上做自動(dòng)化集成到流水線的時(shí)候，有遇到一些常見(jiàn)的在云容器里運(yùn)行測(cè)試會(huì)遇到的問(wèn)題。

1）測(cè)試工具相關(guān)的

• 在容器里安裝puppeteer之前，需要手動(dòng)下載Chromium包以及相關(guān)的依賴。
• 在Docker里面啟動(dòng)puppeteer，要么配置一個(gè)puppeteer的user，要么選擇去掉默認(rèn)的沙盒環(huán)境。
• 當(dāng)時(shí)還遇到因?yàn)閐ocker默認(rèn)的64MB內(nèi)存空間不夠，Chrome渲染頁(yè)面崩潰

雖然很多問(wèn)題都是可以從網(wǎng)上找到答案，但是在解決問(wèn)題的時(shí)候，通常需要我們了解工具框架的工作原理，否則連搜索關(guān)鍵字可能都憋不出來(lái)。

2）測(cè)試報(bào)告可視化相關(guān)的

測(cè)試報(bào)告對(duì)于我們快速定位失敗根因有很大的幫助，好的測(cè)試報(bào)告可以直接揭示問(wèn)題的根源。在云端運(yùn)行測(cè)試，我們通常希望測(cè)試工具能輸出可讀性強(qiáng)的測(cè)試報(bào)告以方便非技術(shù)人員閱讀，也希望測(cè)試工具能把運(yùn)行過(guò)程的細(xì)節(jié)打印在console里，以方便技術(shù)人員定位根因。

像前面提到的CodeceptJS它就提供多種不同形態(tài)的運(yùn)行，并且可以運(yùn)用Mocha生成各種類型的測(cè)試報(bào)告。目前市面上的測(cè)試工具，都會(huì)有對(duì)第三方庫(kù)的依賴，特別是前端測(cè)試框架和工具，這個(gè)對(duì)QA或者團(tuán)隊(duì)的技術(shù)寬度是有一定要求的。

另外Jenkins有非常豐富的插件庫(kù)，在選擇測(cè)試工具的時(shí)候可以把是否有Jenkins報(bào)告可視化支持考慮進(jìn)去。QA需要對(duì)Jenkins和測(cè)試工具都相當(dāng)熟悉，還需要知道如何通過(guò)將某一測(cè)試工具生成的某種格式的測(cè)試報(bào)告集成在Jenkins上以方便一鍵獲取測(cè)試報(bào)告。 像cucumber的測(cè)試報(bào)告插件：

像Allure的測(cè)試報(bào)告插件：

有了這些插件的輔助，在流水線上就一鍵可得測(cè)試報(bào)告，為‘質(zhì)量團(tuán)隊(duì)負(fù)責(zé)’提供了很好的契機(jī)。

3） Pipeline as Code, 想要集成測(cè)試到流水線，不可避免是需要一些DevOps相關(guān)知識(shí)的

也許項(xiàng)目的需求是如何通過(guò)Jenkinsfile 并行運(yùn)行各種測(cè)試，也許是通過(guò)Jenkinsfile傳遞測(cè)試相關(guān)參數(shù)以為云上運(yùn)行測(cè)試所用，還也許你需要在Jenkinsfile里添加調(diào)試信息用以線上調(diào)試，等等。

云上運(yùn)行，我們還要學(xué)會(huì)如何在一個(gè)slave 上優(yōu)雅地管理運(yùn)行測(cè)試的容器，不出現(xiàn)容器占用，slave內(nèi)存不足，測(cè)試失敗之后報(bào)告不可得等等問(wèn)題。

所以只會(huì)自動(dòng)化工具不夠，只有自動(dòng)化測(cè)試也不夠。如果你們團(tuán)隊(duì)開(kāi)發(fā)們沒(méi)有DevOps的經(jīng)驗(yàn)，或者他們忙于特性開(kāi)發(fā)，上線沖刺，那么QA必須對(duì)Docker，Kubernetes 基本命令和用法有些了解。QA就是一個(gè)不分前后端，不挑技術(shù)棧，需要持續(xù)不斷學(xué)習(xí)的角色。

最后用個(gè)比喻結(jié)束這篇文章

會(huì)自動(dòng)化工具算是有了織網(wǎng)的道具，有自動(dòng)化測(cè)試資產(chǎn)算是編出了能撈魚(yú)的網(wǎng)，而持續(xù)測(cè)試才能真正地實(shí)現(xiàn)持續(xù)交付，才算是把一張張過(guò)濾不同缺陷的網(wǎng)放置于了不斷提交變更的交付之流中。

只有網(wǎng)而無(wú)法至于河里，或者不知道于何處放置，那就只能站于岸邊時(shí)時(shí)撒網(wǎng)捕魚(yú)，不夠及時(shí)，也不算釋放了捕魚(yú)人（QA和團(tuán)隊(duì))。

我們期望的是，各種不同的網(wǎng)（自動(dòng)化測(cè)試資產(chǎn)），置于不同的河段（軟件產(chǎn)品不同層級(jí)：函數(shù)級(jí)別？組件級(jí)別？接口級(jí)別？系統(tǒng)級(jí)別？），過(guò)濾不同的魚(yú)（缺陷），而不管是誰(shuí)（團(tuán)隊(duì)的所有角色）都可以去確認(rèn)有沒(méi)有撈著魚(yú)（測(cè)試掛了嗎？為什么掛？我們對(duì)目前的變更有足夠的信心嗎？），也需要所有人時(shí)時(shí)確認(rèn)我們的漁網(wǎng)是不是破了？（測(cè)試覆蓋率不夠？斷言不嚴(yán)謹(jǐn)？測(cè)試用例過(guò)時(shí)？）。

軟件交付是一項(xiàng)團(tuán)隊(duì)工作，即便自動(dòng)化測(cè)試也一樣需要全員協(xié)作。

文/ThoughtWorks郭泰瑜