[[129315]]

在持續(xù)集成的世界中，單元測試是確保添加新功能時不破壞任何其他功能的關(guān)鍵。對于執(zhí)行全部、端到端的測試以及追蹤主要績效指標(biāo)同樣重要，不僅僅是確保了維護(hù)功能，而且沒有傷害性能。預(yù)部署測試的關(guān)鍵是確保測試環(huán)境盡可能同生產(chǎn)環(huán)境緊密貼合。管理員應(yīng)該也能確定他們擁有一套完整的單元測試，因此沒有功能的回歸分析。

如果你使用了任何形式的敏捷開發(fā)——Scrum、GTD或者任何其他的——你很可能熟悉單元測試，并且知道它對于持續(xù)集成多么重要。每一個變成語言都至少有一套單元測試。

以Python為例，py.test允許你編寫你想要的測試。通過Node.js，你可能想要使用Mocha 和Should的組合。不管你選擇哪一條路，確保在每一個提交階段之后運(yùn)行測試。如果測試失敗了，你就知道沒法部署這個分支。

有很多托管的預(yù)部署測試工具可用，但是大部分都有剛性結(jié)構(gòu)要求，或者只支持特定的語言。Jenkins-CI是基于觸發(fā)器運(yùn)行工作的既定方式，而且可以測試任何語言。Jenkins適用于大多數(shù)工作流，并且如果有失敗出現(xiàn)就會發(fā)送郵件提醒。它甚至還能展示測試運(yùn)作的圖表。

測定KPI

關(guān)鍵性能指標(biāo)（KPI）是一種簡單的定量指標(biāo)用來卻行新代碼的質(zhì)量。比如，企業(yè)可能希望度量登錄一個應(yīng)用的時間，搜索內(nèi)容和點擊內(nèi)容的時間。運(yùn)行電子商務(wù)系統(tǒng)的企業(yè)同時可能希望知道付款流程需要花費多少時間，以及用戶在進(jìn)入購買點時需要多少點擊。

原文鏈接：http://www.searchcloudcomputing.com.cn/showcontent_88095.htm

一旦KPI確定，開發(fā)者可以使用AWS的工具來度量他們，比如CloudWatch。CloudWatch可以讓IT團(tuán)隊自動化檢測服務(wù)水平度量——服務(wù)器負(fù)載和彈性負(fù)載均衡器性能。他們也可以上傳自定制標(biāo)準(zhǔn)到CloudWatch，使用CloudWatch API即可實現(xiàn)，這也意味著任何代碼都可能成為KPI。CloudWatch在KPI度量達(dá)到非常規(guī)水平時會提醒開發(fā)者。

確保在高水平負(fù)載下測試你的應(yīng)用。一個實例可以處理多少請求？對比每秒少量點擊，每秒一萬次點擊的延遲增加多少？

第三方性能測試工具，比如New Relic，提供額內(nèi)置的度量KPI支持，通過“關(guān)鍵處理”實現(xiàn)。這個想法確保了大多數(shù)的重要的或者大多數(shù)常規(guī)的任務(wù)識別，而且確保這個任務(wù)的性能，并且追蹤每一個部署對其的影響。

也可以拋棄統(tǒng)計你的日志，使用 Loggly、Splunk或者類似的工具來生成圖表。重要的是要在你上線一項新系統(tǒng)的性能之前監(jiān)測性能。

記住：KPI不是一成不變的。如果一個客戶抱怨具體的某一人物執(zhí)行時間太長，比如下載PDF，i可以將其增加到KPI列表中。目的就是確保終端用戶被照顧到，這也會影響你的應(yīng)用的性能底線。

計劃選擇性的上線

測試一項更新的常規(guī)做法就是選擇性的提供給客戶。這類似于A/B測試，但是取代了嘗試看看用戶對不同的布局做出怎樣的反映，你可以嘗試確定用戶對于新代碼做出的反映。很難預(yù)測一個人會怎樣使用一個應(yīng)用，因此選擇性地發(fā)布開發(fā)通常有助于最小化變化帶來的影響。

谷歌經(jīng)常選擇性的發(fā)布新功能，發(fā)布給一小部分人，而且慢慢地使其成為所有用戶能接受的功能?？梢宰龅煤茈S機(jī)，或者基于用戶的登錄事件。如果有什么錯誤出現(xiàn)，被選擇的用戶反饋的時間長短也沒太大關(guān)系。

如果你正在使用亞馬遜彈性Beanstalk或者亞馬遜Code Deploy，設(shè)置一個獨立的環(huán)境，或者為不同的客戶設(shè)置服務(wù)器群。這將允許你的IT團(tuán)隊在一個環(huán)境發(fā)布更新，同時保持現(xiàn)有的代碼在舊的環(huán)境中。嘗試將用戶分布到多個環(huán)境中，你則無需總是更新同樣的群組。在保持更新的群組中的用戶要特別留心關(guān)注。