如今，IT世界里的發布已經變成幾小時內的事情，甚至幾分鐘就能完成。所有的內容都要垂直伸縮、水平擴展。因此，有一個良好的監控系統是必需的。在很多IT組織里，應用是業務的核心。但監控卻由不寫應用的OPS（運維）團隊單獨去做。為什么會這樣？如果是這樣的話，為什么需要改變？又該如何去改變？怎樣才能得到更好的結果呢？在這篇
文章里，我將分享我的想法和來自于我和DEV（開發）團隊一起
工作的經驗——讓度量變得有意義。
本文描述的觀點來自我在Adform公司任職IT架構師（聯系開發團隊和運維團隊）的工作經驗。Adform是一家數字廣告公司，有自己的開發團隊（65人）和運維團隊（8人）。運維團隊負責發布流程和開發環境，并負責準備和維護生產環境里的網絡和服務器。開發團隊則負責維護他們編寫的應用，其中包括發布到生產環境里的應用。下面的內容基于我們的實際經驗，這些經驗有助于開發人員挖掘度量信息和監控信息，但在原來，大家都認為度量和監控應該是完全由運維團隊關心的。
你可能聽說過廣為人知的TDD實踐——
測試驅動開發，也可能聽說過鮮為人知的BDD——行為驅動開發，或者可能聽說過最不為人知的ADD——混蛋驅動開發（在Scott Berkunn的博文里可以看到一個不錯的開發實踐名稱列表）。但度量驅動開發（MDD）是本文才提出的。
那什么是MDD呢？我認為MDD是用度量驅動整個應用開發的實踐。在使用MDD的公司里，所有東西都是可以度量的，無論是性能和使用模式，還是收益。此外，開發人員、運維人員、甚至業務人員所做的每個決定都是基于度量結果的。度量用來監控團隊的績效、解決性能瓶頸、估計硬件需求，或者在開發生命周期的任意階段達成其他目的。
度量驅動開發的主要原則有：
給度量擁有者分配度量項
創建分層的指標，相互關聯、發現趨勢
利用度量做決定
每個度量項都應該有一個擁有者，他/她要掌握一定的知識和方法來推行、維護確定的度量結果。度量擁有者負責應用、服務，設置運行應用和服務的服務器，確保能正常監控、收集結果。度量擁有者要獲取現有度量項的最新結果，還要為新應用或功能設立新的度量項。
對度量進行結構化也很重要。按照一定標準分組或分層的指標能確保所有人（從業務人員到開發人員）更好地理解它們。而且指標分層后，能更容易相互關聯、發現趨勢，也能更快地找到、解決問題。
MDD讓整個開發過程具備了可見性，所以大家能迅速而又準確地做出決定，錯誤也能被立即發現、修復。此外，可以度量的內容都能進行優化。換句話說，MDD能讓你為應用“把脈”，并給你提供了一個持續改進的機會。
最后，利用度量給Sprint設置目標，MDD也能借此很好地和其他慣常實踐結合起來使用，比如TDD、BDD或Scrum。度量也能發現問題和生產環境中的使用模式，這在驗收測試過程中很難被注意到。一個例子是Lance Armstrong
Bug：代碼在測試時永遠不會出錯，但還是有證據表明它和預期結果不一致。另一個例子是從不會被使用的功能的業務Bug。這些Bug相關的證據可以用度量來收集。MDD確實能實現集中、高效的開發過程，過程回顧可以提高應用使用率。
誰創建指標？
當我們從無到有開始做一件事情的時候，你會有機會重新思考一些概念，給流程加入一些創新，甚至完全修改流程。我們在Adform就做了類似的事情。我們寫完需求、構想好完善的監控解決方案后，發現期望和現實很不匹配。我們本想收集更多應用和服務相關的信息，因為它們帶來收入和競爭優勢。但監控完全由運維團隊去做，他們對基礎設施有深入的了解，卻不怎么了解應用和服務的內部工作原理。
公司不會因為他們的服務器運行穩定（盡管這很重要）和有10G互聯網連接而賺錢。公司賺錢是因為他們的應用和服務提供的功能，以及功能運行穩定（這和“服務器運行穩定”是不一樣的）。因此要快速發現問題，把真正編寫應用的人引入監控流程是必不可少的。事實上，當應用和期望不一樣的時候，開發人員能很容易看出來，因為產品就是他們開發的，他們掌握著產品相關的所有知識。
最重要的是，開發人員去監控還有更多好處：
開發團隊能在開發過程中把監控點嵌入到應用里去
開發團隊能從生產環境里快速獲得應用相關的反饋（性能、Bug、使用模式）
開發團隊能在開發過程中
學習基礎知識，可以預見一些瓶頸
運維團隊長久以來一直在做監控——CPU、內存和IO已經溶入到他們的血液里去了，至于應用和服務的指標，擁有者應該是開發團隊。開發團隊掌握著應用相關的所有知識，還有改進所需的所有技能。這就是運維團隊為什么不能單獨做監控的原因。開發團隊應該和運維團隊一起設立、維護指標。在接下來的部分里，我將介紹我們公司是怎么開始改變、如何把開發人員引入監控和度量里的。
在RTB（實時競拍）項目中應用MDD
經過一個理解、學習、失敗、最終成功的過程，我們才幫開發人員掌握了度量。情況并不簡單，開發團隊從來沒用過度量，而且突然要依靠度量結果去做決策。這個是漫長而艱難的過程，很多因素都會影響最終結果，比如公司文化、員工態度、管理層、甚至工作習慣。為了讓管理層和開發團隊“買賬”，先把度量的價值展示出來就很重要。我們偶然在一個名為實時競拍（Real Time Bidding）的項目里完成了這件事情。
RTB是一種相對較新的買賣方法，會實時在線顯示廣告，每次顯示一個廣告。簡而言之，為了在特定網站向特定用戶顯示橫幅廣告，我們通過一個叫“Ad Exchanges”的結構接收請求，了解客戶愿意支付多少錢。我們收到、處理請求的時候，會給發送端的服務返回響應。這個項目的運營需求是每秒處理四萬個查詢（QPS），單個交易的往返處理時間不超過一百毫秒。
應用發布到生產環境之后，情況果然非常糟糕，因為我們每秒只能處理五千個查詢。而且近30%的交易都失敗了，因為我們滿足不了一百毫秒的需求。更糟糕的是，性能如此之差卻沒什么明顯的原因。我們搞不清楚問題是源自網絡、服務器容量，還是應用層。
最終是度量幫我們找出了問題的真正原因，并扭轉了局面。我們每秒能處理的查詢最終有七萬多個（比一開始多十四倍多），同時能保證失敗交易數低于0.5%（大概比原來低五十倍）。但為了實現這樣的結果，我們對數據進行了更多分析和結構化處理，在接下來的章節中我們繼續說明。
分層的指標
由于在RTB項目開始的時候我們已經有一個度量項目了，所以我們就在RTB應用里嵌入了一些指標。而且我們已經有針對服務器和網絡方面的度量。但在數據的海洋里很難辨別出必要的數據、了解趨勢，并找出我們的性能遠遠低于要求閾值的原因。很顯然，僅僅有數據并不會帶來多大的價值。
所以我們決定在三個層面對數據進行可視化：
業務指標
應用指標
基礎設施指標
分層的方法讓度量更加結構化了，對所有人（從開發人員到業務人員）來說都變得可用、易于理解。Business Dashboard成為檢查應用狀態的公共入口點。任何人都可以訪問它，檢查當前的狀況是否符合要求的SLA、使用趨勢或收入。如果需要的話，大家還可以深入到Application Dashboard去檢查不同應用組件的性能、不同服務器組的延遲及數據增長。事實上，Application Dashboard上的一些指標在Business Dashboard上也有，只是更為詳細。舉例來說，我們在Business Dashboard上繪制了應用性能，在Application Dashboard上則繪制了應用不同部分的執行情況（見圖1和圖2）。最后，我們在Infrastructure Dashboard上檢查關于CPU、內存和I/O使用率的相關信息。
圖1. Business Dashboard上的應用性能
圖2. Application Dashboard上的應用性能
要找出問題的根本原因（不僅僅是看結果），接下來要做的就是把不同的指標關聯起來。我們把顯示關鍵指標的圖形疊加了起來，從上到下依次是業務指標、應用指標和基礎設施指標。這種方法有兩種用途。我們從上往下看這些圖形的時候，可以清楚地看到QPS的變化是怎樣影響應用性能和服務器CPU的（參見圖3）。相反，從下往上看的時候，則可以看出I/O的增加是如何影響SLA的。
圖3. 關聯的指標示例（自上往下依次是：QPS、SLA、競拍服務的性能、CPU負荷）
分層和可用的指標能讓開發人員了解項目業務方面的內容。事實上他們能看到我們從哪里賺了多少錢。當新特性或Bug修復發布到生產環境里后，開發人員立即就能在Business Dashboard的金錢圖標里看到這些內容對收益產生了怎樣的影響。反過來，業務人員也能理解項目技術方面的內容，看到開發人員所面臨的問題和我們的負載局限。在現實中，我們還根據度量設置了目標，借此把MDD嵌入到了Scrum里。最終，參與項目的所有人員都對項目的各個部分都有了認識，結果很圓滿。
利用度量做決策
在任何活動里，最重要的事情都是認識和理解目標及其背后的原因。你可以創建不同的Dashboard、收集大量度量數據，但如果不作為決策的輸入，度量就沒什么用處。我見過好幾個例子，都是團隊創建了多個度量項，但大家卻不理解度量的含義和必須設置的原因。所以他們也沒利用度量指導決策。還有一個不好的例子，團隊做決策時甚至不知道他們的應用到底是怎么運行的（我寧愿說這是我猜的）。他們有一些指標，但還不足以從中獲取價值。
MDD的美妙之處在于，它還能最低限度地減少誤解。當基于度量做決策的時候，幾乎不需要任何解釋。決定變得明確、有邏輯、易于闡述，因此也就不易被反駁。決定做得更快更準確，團隊的氣氛也好轉了很多。此外，這也能帶來跨團隊邊界的級聯效應。團隊間的溝通更多由數據驅動，不再那么情緒化了。換句話說，開發團隊和運維團隊之間、多個開發團隊之間以前會相互指責，這種情況現在則很少發生，甚至完全消失了。
需要注意的是，在某些情況下我們可能從現有的度量里找不到證據，只會去猜問題的真正原因。解決辦法是再創建一些指標，來支持或否定最初的假設。
在決策過程中使用度量對大家來說是一個雙贏的局面。MDD的主要目標是提供基礎設施和應用各個方面的信息，除此以外，MDD還有助于改進團隊內部和團隊間的關系。
我們學到了什么
我們走了很長的路才在整個組織里應用了MDD實踐。這不僅僅是技術的變化，更重要的是文化上的改變。每個人都需要轉換觀念、態度、對開發過程的理解。在達成愿景的過程中，我們發現了不同的結果。因此，我想和大家分享兩個對你可能有益的經驗教訓。
我們學到的第一個重要經驗是，你應該盡全力為開發團隊創造盡可能順利的體驗，避免充當中間人。我們最初嘗試的解決方案是讓運維團隊和開發團隊共用一個度量服務器。但效果并不理想，對我們來說主要原因有兩個。第一，開發團隊受制于運維團隊，開發團隊做的每個修改都需要運維團隊的授權。第二，運維團隊不喜歡開發團隊頻繁修改內容。所以我們決定給開發團隊專門提供一臺服務器，讓他們從中獲取所有服務器相關的度量信息。開發人員在那臺服務器上修改內容不需要按發布過程執行，也不需要特殊的授權。事實上，他們可以在這臺服務器上做幾乎所有的事情——甚至從監控里刪除其他服務器。盡管讓開發人員自由去決定、實施并負責變更看起來有些匪夷所思，但這確實是我們做過的最好的決定之一。
第二個非常實用的經驗是，我們花費時間去寫“監控愿景”或“監控工具的需求”，但都是浪費時間，因為我們的期望和實現在整個過程中變更了好幾次。而且它們會繼續變化。花費過多的時間去選擇一個度量工具也是一種浪費。沒有工具能滿足你所有的需求，所以挑一個你用著順手、適合你們愿景和公司的就可以了。我們選擇了Zabbix——一個開源工具。盡管它有一些局限，而且導航復雜（我們甚至稱它為“一點就死的工具”），但它能讓我們迅速開始。最后，別忘了給最常見的用例準備幾個收集數據、圖形化展示數據的例子。
讓MDD變得有趣些，而且讓大家都能看到。把顯示重要指標的電視放在門廳或工作空間里。如果可能，圖形化顯示不同項目的收益。給一定的成就設置獎勵，比如連續成功發布的次數（參見圖4）。大家一起度量最好的成績，比如每天、每周、每月最高的訪問量或交易數，并一起為之慶祝。這種方法會引發大家的好奇心，讓大家提出問題，并參與到度量里來。通常情況下，你可以從添加一些簡單的圖形開始。同事們在門廳看到后，會立即提出一些很棒的改進意見。
圖4. 成功發布的獎勵
對參與MDD的所有團隊來說，尤其是對開發人員來說，MDD要求的文化變化還是很冒險的。他們開始用自己的應用來觀察問題，之前大家都不了解這種做法。Adform的思維模式完全發生了變化。原來的態度是，只要沒人抱怨，就認為一切都正常。現在，所有人都知道這不是度量應用性能的好辦法。開發人員現在都能很自如地處理度量了。出乎意料的是，開發團隊原先看不到度量信息，對自己的應用倒是感覺良好，而現在只要指標不可用，他們就會覺得不舒服。
目前的工作重點和未來計劃
我們要在整個組織里推行MDD，新的挑戰會隨之不斷出現。當多個團隊有不同的需要、愿景、對度量的理解，卻在一起創建指標的時候，事情就會變得很混亂。我們要定期刪除不用的指標，并以類似的方式讓度量覆蓋到新項目。
目前，我們正試著為開發人員創建準則，以確保所有開發人員達成共識。每個開發團隊都要能回答下面三個問題：
你怎么知道你的應用運行正常？（Bug少并不夠，必須提供進一步的證據，比如模擬）
應用的性能隨著時間的推移會有怎樣的表現？（比如說，和上一個版本相比，它是越來越快還是越來越慢？在高負載情況下是否仍能良好運行？）
你的應用的使用頻率是多少？（比如有多少用戶會在同一時間去生成報告？系統在白天會發布多少橫幅廣告？我們收到多少筆交易？）
這些問題有助于確保所有的應用在進入生產環境前都能被度量，并達到相同的度量覆蓋水平。
至于以后的改進，我們現在正在做一個交通信號燈監控層（為了獲得更快的反饋，最終達到外包一級響應等級——參見圖5），還有度量驅動的硬件容量評估。
圖5. 應用信號燈
總之，把度量加到開發過程里有很大的潛力。在整個組織內推行這種實踐是很難的。但潛在的好處也很巨大：應用和業務表現對開發團隊和業務人員來說是可見的，大家可以基于真實的數據更快、更準確地做決定，而且團隊內和團隊間的溝通也能得到提升。
關于
敏捷方法論的
文章已經很多了。其中，相當一部分文章講述了敏捷方法技術方面的問題，比如
測試驅動開發和持續集成。同樣，還有相當一部分文章討論了敏捷 方法論的應用問題，例如發布計劃，跟蹤生產率，如何使用度量數據對過程“調優”，甚至讓公司里的業務人員確信需要采納一種特別的方法。讀過這些有關敏捷方 法的文章后，很容易讓人產生一種感覺，即通過購買一套工具并遵從一系列看上去很簡單的實踐，就算采納了像極限編程和Scrum這樣的敏捷方法。然而，現實 世界的經驗表明，成功地采納敏捷要比那復雜得多。它涉及到如何培養一些正確的做事態度來建立信任，鼓勵交流與協作，最終讓人們更加適應，并產生高效。
敏捷方法常常被描述為以人為中心，而不是強調技術，并有充分的理由來說明這一點。然而，雖然敏捷宣言強 調了“個體和交互勝于過程和工具”的重要性，但它并沒有清晰地闡明如何處理這個重要的社會性維度。在強調技術的業務中，這些都太簡單，無法概觀個人態度在 項目團隊中的強大影響力。要想知道哪種態度可以促進（或阻撓）敏捷的采納，我們要問一個問題：“在成功的開發者和管理者之中，我們能發現那些與眾不同的行 為嗎？”，更重要的問題是 “這些行為是由什么態度驅動的呢？”
很多開發者習慣于獨立
工作，花費大部分的時間來閱讀規范，并完成設計和編碼。在前敏捷環境（pre-agile environment）中，一些開發者甚至戴耳機聽音樂，不聽來自辦公室的“噪音”。采納極限編程的開發者發現其自身已經融入到更加社會化的環境了，在 這種環境下，成功依賴于與同伴和客戶更緊密的協作。另外，經典的前敏捷開發是個體獨自“擁有”那些設計和編碼。在敏捷環境下，工作任務由團隊共同決定： 沒有誰能獨自擁有某段代碼。這種態度的調整可能特別具有挑戰性。
剛接觸敏捷開發的人可能習慣于在那種將自身劃分成子系統再進行開發的項目。他們習慣于依據各子系統之間互聯的高層次規范，獨自負責某個子系統的設計。剛接 觸集體代碼所有制的開發者很容易被他們不得不掌握的代碼的數量嚇倒。與此同時，很少的技術文檔（甚至沒有技術文檔）和快速變化的代碼基線（包括那些熟悉的 類名和方法名都有可能在短時間內發生變化）很可能加劇這種情況。但是，敏捷方法論（特別是極限編程）要求編程人員有很強的編碼能力。通過對缺乏經驗和富有 經驗的敏捷開發人員的觀察，很容易就可以看出不僅僅是技能問題，態度也是非常關鍵的。
表1：傳統團隊與敏捷團隊的對比
表一在代碼級別上列出了一些傳統團隊與敏捷團隊的不同。富有經驗的敏捷開發者有不同的編碼方法。他們傾向于靈活編碼，而不是等到整個設計都很完善了再進行 開發。另外，他們還傾向于把編碼視為
學習和探索的機會。例如，遇到一個問題時，他們總是通過編寫一個小的概念驗證模型或“技術原型（spike solution）”使問題具體化，而不是構建一個復雜的模型或者通過自然語言描述來說明各種行為。同樣，敏捷開發者更愿意去閱讀第三方的代碼。有時候， 他們想做一些力所能及的改進；有時候他們這么做只是為了學習一種新的設計方法。最后，通過盡可能地讓類、方法以及與潛在的方法調用鏈等相互獨立，以便僅了 解局部代碼就足夠了，這樣就不用去花很多時間去研究整個子系統或應用。所有這些差異能更好地使開發者發現并處理編碼中出現的問題，而不是僅僅使用高超的編 碼技能完成任務而已。
拿結對編程為例。對于采納敏捷方法論（尤其是極限編程）的團隊來說，結對編程是最有爭議的幾個問題之一，因為它需要兩個開發人員共同完成同一段代碼。雖然 一個開發者可能具有杰出的設計能力并精通開發平臺，但作為一個高效的XP開發者，他還必須能夠溝通思想，協作進行測試，提供可能的實現方案，并在某個實現 策略上達成共識。很多開發者不愿意進行結對編程，并不是因為他們不會編碼，而是因為他們不熟悉結對編程。有個開發者在他的blog中寫道：“結對編程會使 他們暴露他們真正的知識和技能水平”。獨立編程時，別人只會看到編碼結果。而結對編程時，不順利的開始和早期犯的錯誤都會被別人看到。這時肯定會有一種壓 迫感，甚至對高水平的開發者也是一樣，要花上一段時間才能習慣。值得牢記的是：當你了解了其它團隊成員，并且熟悉每個參與者的個性之后，結對編程就會變得 容易起來。
大多數成功的極限編程者對使用各種語言編程、學習新的設計方法都相當感興趣，特別是閱讀已存在的代碼。這些成功的開發者愿意通過嘗試做一些小的練習來“實 踐”編碼。他們可能會通過編寫一些小工具或參與開源項目進行實驗。在這里，著重強調“實踐”是非常重要的。好的敏捷開發者常常通做一些事情來掌握知識和技 術，而不僅僅通過閱讀了解它。
“極限編程是共產主義……”這就是某個開發者對結對編程的牽強解釋。他提到，在XP中的編碼使大家分享了的各自的經驗，他嘲笑“集體代碼所有制”，并對所 有開發人員可及接觸所有領域的工作以便能夠編寫任意部分的代碼這一事實嗤之以鼻。我與這個開發者聊過一段時間以后，才明白他的想法實際上是為了與他人競爭 以保住“飯碗”。他擔心同一團隊中以及不同團隊間的競爭問題。與別人一起工作意味著允許別人看到他是怎樣解決問題的，用了什么工具，這就使別人有機會學到 他的訣竅。他對結對編程的反感表明，在敏捷團隊中需要解決個人英雄式開發和“飯碗”問題。結對編程很自然地使開發者向同事敞開胸懷，分享領域知識，并時刻 準備把你的方法與大家分享。
一個極度自信的開發者也可能會拋開結對編程這一方式。有時面對生產速率下降而一個成員獨立工作可以使其提高的情況下會發生這樣的事。另外，當一對開發者中 的某個人能力不濟，而另一個人就會把“結對”變成“個人秀”。 還有一些時候，其中的一個開發者可能急不可耐地想完成任務，因為一些個人原因驅使他盡快完成用戶故事，可能最顯而易見的原因就是“野心”：試圖通過展示技 術能力成為團隊領導者，或得到其它晉升機會。這樣的態度很容易使結對褪變成一個“得分比賽”，比賽的目標就是看誰能贏，而不是設法完成有意義的工作。
過少的發言權也可能是成為一個問題。一個開發者很少主動關心他的結對任務的話，很可能他就會被他的伙伴所領導。在這種情況下，這個開發者實際上是放棄了很多在設計和代碼質量上的責任。
塑造敏捷教練
至此，我們僅討論了在開發者中發生的常見實踐問題。然而，創建和維護一個具有敏捷態度的開發團隊也是教練和其他領導者最重要的責任。這些領導者必須為他們的團隊建立一套好的樣例并成為真正的教練，而不是成為只有“教練”頭銜的團隊成員。
最有效的領導技能之一就是建立一整套好的樣例。開發團隊會建立一整套規則，比如所有的產品代碼要結對編寫，所有的產品代碼都要先寫測試等等。只有團隊成員 堅信這些規則是非常重要的，這些規則才會起作用。然而，“說了不做”真的是太容易了。例如，團隊領導者向團隊成員宣布：“構建失敗了，我們現在最重要的任 務就是修復它。”剛聽到時一定會信以為真，可是接下來的話卻不是那么回事了，“我第一個發現了這個問題，原本應該由我來修復它，可是我太忙了。”他的行動 使其對這件事的重要性大打折扣。別人會認為，構建可能是現在最重要的事，也可能不是。作為一個團隊領導者，讓別人看到他正在與一個開發者一起修復這個構建 是很平常的事情。這么做可以向團隊成員進一步表明，構建是一個非常重要的事。
好的教練并不僅僅是知道如何教開發人員技巧，還要鼓勵開發人員務實思考，并高效協作。這有點與Ken Schwaber所描述的ScrumMaster 的角色相似，即該角色對鼓勵團隊協作負有責任。當教練拒絕解釋而直接用自己的知識來解決問題或者以命令的口氣來領導團隊時，這就是一個不太好的信號。
我想，最好從外面請一個人來作為“教練”幫助團隊，而不應該是團隊的固定成員。如果教練是團隊中的一個固定成員，那么會存在利益沖突：有時他要幫團隊成員，以便提高團隊能力和效率；而有時他要客觀地評估團隊，在團隊成員之間做一些比較。就象Kent Beck在他的《Extreme Programming Explained》一書中所提到的，一個教練應該有一個目標，即幫助團隊成長，最終達到不再需要教練。一個好的教練需要一定的自信和情緒控制力，也需要技術能力和經驗。
鏟除潛在的問題
有幾個潛在的因素會對團隊態度產生負面影響。一些團隊成員很擔心：他們的團隊領導做改革只是為了進一步達到個人目標，而不是為了使團隊做得更好。另一部分 成員不愿意面對變化的原因是怯于表達。另外一個特別麻煩的問題就是：誰不喜歡自己得到夸獎，并可以批評別人呢？可是我們真正需要的是虛心地接受批評和學 習。
在軟件業，很多創新可以得到個人獎勵。寫東西和在會議上講演顯然都會提升個人形象。技術領導者、教練或處于同樣角色的人就處于一種可以引入變化的位置上。 我們應當意識到，盡管我們鼓勵創新，但變化也有可能帶有破壞性或給已經高效工作的團隊更大的壓力。因此，和團隊一起進行回顧找到解決方案要比由領導宣布某 種改進策略要好得多。
“激勵整個團隊擁抱變化要比使用權力來執行對他們自己及業務有利的某些變化好的多”。對于領導者來說，能認識到這一點是非常重要的。正如一個開發人員抱怨 說：“這么做只能使我們更傷心。他們只想通過會議來使他們看起來更有權力。”他認為在他的團隊中，只是為了使團隊中一兩個權威人士顯得更專業就將某種革新 強加在團隊之上，甚至不顧這會使軟件交付的每日任務更難完成。所以另一個關鍵之處就是要認識到每個人都需要穩定性和安全感，而過多的變化會使其很快動搖。
然而有時很明顯的是，人們已經根深蒂固地反對那種尚未發現的變化。不管已經有多少人的擔憂被巧妙地說了出來，還是會有更多的擔憂不斷涌現，這是經常發生的 事情。很可能那些提出個人擔憂的人就有某種個人或動機問題需要改進，這是好事，但說出來以后并不一定會感到舒服一些。例如，很多人可能會對極限編程提出一 些技術和業務方面的異議。很少有人會坦言真正困擾他們的到底是什么。例如，你不可能聽到：“使用XP意味著固定的工作時間，所以我不能到學校接我的女 兒。”
當團隊成員發現他們可能要使用某種新的技術平臺來構建一些產品時，同樣的事情也會發生。一些開發人員強烈反對這樣做，他們的理由就是“我們需要多考慮一些 技術問題，例如可擴展性、學習和維護成本、工具的質量等等”。幾個月以后，我們就會發現，真正的原因是很多開發人員不想花時間去研究被提及的新平臺，因為 他們感到學習新技術平臺會證明他們的個人學習能力不行。從專業角度來看，盡管職業發展、就業能力和工作與生活的平衡都都是很正常的問題，但對于個體來說， 還是很難消除這種擔心。
在培養敏捷團隊中的最后一個潛在因素就是需要一點謙虛的品德。在敏捷團隊中，謙虛有很多好處。其一就是它減少那種反生產力的“得分式(point scoring)”競爭的可能性。這正是與XP中的“做最簡單的事”相吻合的心態，正象Steve McConnell在《Code Complete》中所指出的，它鼓勵開發人員寫可讀性更高的代碼。當你想批評別人，尤其是當他正努力采用敏捷方法的時候，你就該學習如何保持謙虛的心態 了。雖然別人有缺點，但當你看到了一個缺點并自問“我曾經犯過同樣的錯誤嗎”時，這才是重要的。你可能無法改正別人的缺點，但你肯定可以從中學到東西。
結論
在敏捷團隊中培養高效的態度和工作方式是一個復雜而關鍵的活動。很多試圖進行敏捷項目的人把焦點放在業務上。盡管業務很重要，但是一定要記住：項目干系人 都是人。他們也有他們的個人需求和關心的事情。一個成功的自組織的項目團隊需要每一個參與者都能真誠地來推動各方面的改進。敏捷不是被“統治”出來的，但 是，假如給予那些具有能動性的團隊成員進行自我組織的自由，那么敏捷是能培養出來的。
我們在
測試活動中，時常關注一些性能數據，這些數據從哪兒來？很顯然，放在我們面前的第一道關卡便是
監控技術，我們需要合理的，可以高度擴展和集成的監控系統，可以實時監控性能數據，并將他們用漂亮的方式展現出來，云時代背景下誕生了這么一些給力的工具，他們中有一些名字已經讓大家足夠熟悉了，Nagios，Gmond等，他們中還有一個強大的身影，就是今天給大家分享的
Ganglia。
Ganglia
Ganglia是一個跨平臺可擴展的，高性能計算系統下的分布式監控系統，如集群和網格。它是基于分層設計，它使用廣泛的技術，如XML數據代表，便攜數據傳輸，RRDtool用于數據存儲和可 視化。它利用精心設計的數據結構和算法實現每節點間并發非常低的。它已移植到廣泛的
操作系統和處理器架構上，目前在世界各地成千上萬的集群正在使用。它已被用來連結大學校園和世界各地，可以處理2000節點的規模。
這幾天
測試一個項目，上線時間比較緊，人手不夠，白天都忙著測試功能了，對于 系統的一堆接口經常要迭代測試， 、并且性能基本沒有時間去做，正急得頭暈眼花的時候老大給了一個方案：寫一些腳本 ，申請一臺機器，做個定時任務 晚上去跑，白天來看結果，然后重點人工去測試。想法是不錯，可以前沒有高過腳本和定時任務，沒有辦法趕緊去補一下。
問題一：如何寫訪問接口的腳本，要保證接口正常，就要滿足請求的接口是可訪問的 ，同時返回的數據是正確的，我的乖乖，接口是否可以訪問好弄 使用curl 命令訪問接口接口以了。
例子：get接口：
curl "http://api.map.baidu.com/images/blank.gif?product=jsapi&v=2.0&t=66977464&code=5000"
post接口：
curl -d "user=nickwolfe&password=12345" http://www.yahoo.com/login.cgi
返回都是個json串。根據返回的json 來判斷 返回結果有沒有。但是我又該如何判斷返回結果對不對呢？糾結了好久（肚子沒有貨，都這樣），結果大神一個命令給解決了。貼一個腳本看看：
#！ /bin/sh ##! 后面喲喲空格 sudo curl "http://===============" >> /home/url.txt #接口url cd /home if [ $((grep "ok" url.txt)| wc -l) -gt 0] then echo "ok" >>result.txt date +%y%m%d%H%M >>result.txt else echo "no" >>result.txt date +%y%m%d%H%M >>result.txt fi echo "end" exit 0 |
下面開始做定時任務：
sudo crontab -e
0 */1 * * * sudo sh /home/test.sh # 每個小時運行一次腳本
保存 退出
sudo /etc/init.d/cron restart #重啟 定時任務腳本的配置
sudo tail -f /var/log/cron.log #監控 定時任務日志
好了定時任務搞定 ，這個是搞的一個 接口，多個接口 可以 把 所有的接口訪問 url 寫成一個文件 然后到文件中讀取，再 用curl 去請求。哈哈，100多個接口 不用每個版本都去 看看 接口有沒有問題 只需要一次測試沒有問題，以后看運行結果就可以了。
版權聲明：本文出自 huangzigang 的51Testing軟件測試博客：http://www.51testing.com/?498111
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
近一年多一直在從事服務端的
測試工作，雖然之前也做過兩年，但融合了
自動化測試和
功能測試以及
單元測試，所以精力有限，接觸到的
白盒測試比較碎也比較淺。近期項目進入了調整期，有時間整理下對于項目測試中的代碼測試一些感觸。 順便對未來的工作方向和計劃做好準備工作。
2014年可能需要繼續負責服務端項目測試工作，但到底白盒測試和功能測試以及模塊測試，自動化測試之間應該如何進行抉擇，如何進行搭配，相互補充，來達到項目高質，高效的目的呢？ 站在整個項目的角度，從以下幾個維度對白盒測試進行了一些思考：
1. 什么樣的項目可以考慮做白盒測試
1.1. 大項目，周期比較長（因為需要前期介入review RD代碼）
1.2. 功能測試不放心的項目，接口比較明確，重要函數做的修改
1.3. 對整個項目了解較清晰，時間要求較低
1.4. 新項目
1.5. 邏輯較復雜的模塊
1.6. 通用類的
1.7. 異步的、多線程的程序
1.8. 函數用到的外部數據較多的不適合做，構造起來非常復雜，如大量的信令、詞典等
2. 如何結合白盒測試和其它測試方法
首先，需要根據項目特點，比如項目周期，項目難度等來確定測試方法。
然后，如果滿足做白盒測試的條件，則需要先確定白盒測試處于項目測試中的什么階段，如果是迭代或優化類的項目，建議進行分層測試，重點對更新的代碼進行白盒測試，其它的進行傳統的自動化或手工回歸測試。如果是周期比較長的全新項目，可以考慮在RD編碼階段介入，了解接口和底層內部函數構造，為白盒測試做準備。 為了避免白盒測試和功能測試的交叉工作量，可以底層庫用白盒測試，上層功能測試用功能測試，在功能測試上就不再關注底層的測試，可借助分層測試思想。
3. 如何降低白盒測試成本
不管從技術還是從周期上，白盒測試成本比較大，所以站在高效和簡易的基礎上，盡量借助工具來盡量減少白盒測試范圍，比如可以借助：
3.1. 手工測試+代碼覆蓋率測試來覆蓋一部分代碼
3.2. C代碼可以用gdb（其它語言也有）來構造一些比較難引入的上層變量，再結合代碼覆蓋率來做
3.3. 單測工具，比如cppunit，gtest等來做
接口測試 3.4. 其它
我們之前的做法是將模塊測試做成自動化CASE，然后新版本來后，進行自動化測試回歸，并結合代碼覆蓋率來出一份覆蓋報告（從分支和代碼行兩個維度），然后再對新升級的代碼進行review，并拓展用例來覆蓋，如果功能測試實在無法模擬，會采取gtest，最后仍不好模擬會采用gdb掛載的方式
4、 白盒測試收益和風險是什么
4.1. 功能測試無法深入到底層的測試上，白盒測試可以
4.2. 投入成本較大，收益較小
4.3. 通過白盒測試只能發現函數級的錯誤，較難發現函數接口之間的錯誤
4.4. 時間會增加，覆蓋率會增加
4.5. 可促進rd的單元測試做的更充分
4.6. 短期收益不明顯，長遠會有收益
5、白盒測試方法
5.1. 最基層的函數做詳細的測試(傾向于功能)，策略較復雜的做詳細測試(傾向于邏輯)，通過自己寫5.2. 程序去調用被測函數，外層的通過GDB的方式去測試
5.3. 自己寫驅動去調用被測程序或構造上下層來驗證被測程序
5.5. 通過程序包裝被測程序，通過多線程的方式去實現多個動作之間的交互
5.6. cppunit去做，但調用關系較復雜的測試很難去實現，支持case的管理、驗證
5.7. 可借助gtest去實現，擴展為和c++test類似的功能
版權聲明：本文出自 800716 的51Testing軟件測試博客：http://www.51testing.com/?359684
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
QQ登陸的輸入項為QQ號碼(長度為5到10位數)和QQ密碼，登陸和退出按鈕，一臺機器可以同時登陸超過一個QQ號碼，請設計
功能測試用例。
快捷鍵的使用是否正常：
1. TAB 鍵的使用是否正確
2.上下左右鍵是否正確
3.ENTER 鍵的使用是否正確切換時是否正常。
布局美感
界面的布局是否符合人的審美的標準
具體因人而依
輸入框的功能：
輸入合法的用戶名和密碼可以成功進入
輸入合法的用戶名和不合法密碼不可以進入，并給出合理的提示
輸入不合法的用戶名和正確密碼不可以進入，并給出合理的提示
輸入不合法的用戶名和不正確的密碼不可以進入，并給出合理的提示
不合法的用戶名有：不正確的用戶名，，使用了字符大于用戶名的限制
正常用戶名不允許的特殊字符 空的用戶名，系統(
操作系統和應用系統)的保留字符
不合法的密碼有：空密碼(除有特殊規定的)，錯誤的密碼，字符大于密碼的限制
正常密碼不允許的特殊字符，系統(操作系統和應用系統)的保留字符
界面的鏈接：
對于界面有鏈接的界面，要測試界面上的所有的鏈接都正常或者給出合理的提示
補充
密碼框顯示的不要是具體的字符，要是一些密碼的字符
驗證用戶名前有空格是否可以進入，一般情況可以。
驗證用戶名是否區分大小寫。(有的軟件是區分大小寫的)
驗證必填項為空，是否允許進入。
驗證登錄的次數是否有限制。從安全角度考慮，有些安全級別高的軟件會考慮這方面的限制。
單元測試的概念
單元通俗的說就是指一個實現簡單功能的函數。單元測試就是只用一組特定的輸入(測試用例)測試函數是否功能正常，并且返回了正確的輸出。
測試的覆蓋種類
1.語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行次。
2.判定覆蓋(也叫分支覆蓋)：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
3.條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。
4.判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，并且每個可能的判斷結果也至少執行一次。
5.條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。
6.路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。
用例的設計方案主要的有下面幾種：條件測試，基本路徑測試，循環測試。通過上面的方法可以實現測試用例對程序的邏輯覆蓋，和路徑覆蓋。
版權聲明：本文出自 沙場點兵 的51Testing軟件測試博客：http://www.51testing.com/?535396
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
介紹
每個實行持續交付的項目，都有生產流水線的元素，如持續集成和
自動化測試。這些測試是在不同層面進行的，從
單元測試到冒煙測試再到
功能測試。自動化功能測試的優點之一是可重復性和可預測的執行時間。出于這個原因，它應該作為軟件質量的每一個構建之后的指標。功能測試自動化往往會成為一個瓶頸，所以你應該熟悉一下如何創建這樣的測試的基本原則。
首先設計你的測試
測試集合可以比作盆景樹。
最初的時候，我們照顧樹根和樹干。我們選擇會成長的主要分支，我們每天都細心照料這棵樹并等待它長出健康的葉子。
我們可以以類似的方式繼續測試。
我們建一個將負責應用程序主要功能（例如：開啟）的基類。
根據說明，我們先明確將被測試覆蓋的應用程序的主要功能，然后每天我們在執行測試的時候都添加更多平行測試。
每一個支持測試（例如創建一個新的用戶）的方法都需要與測試分離——讓我們在單獨的類里面來實現。
你應該在包括了應用程序主要功能的目錄里保持類。
去建一個規定很多功能共有方法的抽象類是很好的做法。
如果你正在測試Web應用程序，就用頁面對象設計模式。該模式里，一個類及其方法對應了單個頁面的功能或一個大型網頁里單個頁面上的一個元素。
無需事事自動化
自動化花費很多，所以你應該主要測試應用程序的主要功能。
某些測試可以快速輕松地手動完成，且潛在腳本可能難以實現。
值得用到自動化的是那些繁瑣的需要被重復很多次的，和那些需要大量數據驗證的測試
工作。
寫短測試
在一個或多個測試失敗的情況下，開發團隊的任何成員都應該能夠輕松地找到錯誤的原因。
出于這個原因，每個測試方法里應該最多有5個斷言，并且每個方法都必須提供的測試操作的完整記錄。
明智的做法是使用BDD（行為驅動開發）技術，但是當你沒有用一個特定的測試框架時，你應該把接下來的測試步驟放在comments //given //when //then下。
創建獨立測試
在測試類中的每個方法應該是一個獨立的實體，而不是依賴于其他測試。我們應該能夠在任何時間運行單個測試。否則，這樣的
測試用例集將來維護起來就會很貴——必須定期跟蹤和更新測試之間的聯系。
很多時候，測試需要一定的前提條件來滿足。這些條件不應該用外部方法，應該在試驗開始時運行。如果這些條件和測試類的所有方法一樣，它們就可以被放在一開始進行的方法里（例如：在
JUnit中被標記為@ BeforeClass）。
關注可讀性
源代碼應該是自我記錄的，而寫下以下幾行代碼的每個利益相關者應該明白測試在做什么，為什么它被這么寫。盡量避免在源代碼注釋，因為它也必須被更新。這值得花比平常多一點的時間來命名方法，從而使你的代碼更易讀。
再看看行為驅動開發技術，每個測試方法都應以單詞“應該”開始，而不是“測試”。
根據這一慣例，我們馬上就可以明白一個特定的方法測試什么內容了，它在分析測試報告時特別有用。
測試必須要快
正如在本文開頭所提到的，自動化功能測試應該是應用程序質量的一個指標。連續傳遞過程中的每一步都應指明最長持續時間；并且根據這個概念，開發團隊應該盡快獲得有關軟件質量的反饋。自動化功能測試的持續時間應不超過幾分鐘。
對一個非常全面的測試集來說，有必要并行運行測試（經常在不同的機器上）。虛擬化在這里可能是非常有幫助的。
創建抗變測試
最常提及自動化功能測試的缺點是其對應用程序中變化的低抵抗性，尤其是在GUI中。
在Web應用程序中，測試應該能抵抗網站的內容的變化。測試應該只驗證功能，這就使得它可以在不同的位置運行測試。這并不意味著我們不應該編寫自動化測試來檢查網頁的內容。
如果你已經想創建這樣的測試，你應該遵循DDT（數據驅動測試）技術。這意味著，檢查內容是與源代碼分離開的。
Web應用程序的頁面布局變化非常頻繁，這已經影響到了用戶界面。
當你設計一個界面時，每個區段和每個頁面你都應該有一個你可以用來測試的唯一標識符，即使一個網站的層次結構發生了變化。
自動化測試無法取代人類
功能自動化測試可以是項目中的主要測試技術，但絕不是唯一的一個。
自動化測試是可重復再生的，他們的覆蓋范圍總是相同的。
另一方面，雖然探索性測試是低再生的，但是它們能夠覆蓋自動化測試未觸及的區域。
你還應該記住，自動化測試的“綠色”狀態并不意味著你的應用程序是沒有錯誤的。
這種情況往往會讓測試員分心，而且有可能會影響測試的準確性。
一面（技術面）
棧和堆的區別
數組中第一個不重復的字符串（如AABBBC，則為C）
二面（技術面）
百度的
工作環境是
Linux，所以問了Linux常用命令的使用情況，問了一個查看進程的命令，是ps -aux | grep 進程名
問了hash map
介紹了下項目
三面（經理面）
1、自我介紹
3、你為什么在上海這家公司實習
4、你和你項目主管、師父的相處怎么樣
5、你的優缺點（重點是確定）
6、對面試經理提問題
暫時記得這些，結果等待中
結果出來了，很幸運被錄取了，哈哈，期待~
模糊
測試（fuzz testing）是一類
安全性測試的方法。說起安全性測試，大部分人頭腦中浮現出的可能是一個標準的“黑客”場景：某個不修邊幅、臉色蒼白的年輕人，坐在黑暗的房間中，正在熟練地使用各種工具嘗試進入某個系統。這種由安全人員“模擬黑客進入系統”的測試方法的確是安全性測試中的一種有效測試手段，名叫“滲透測試”。滲透測試方法完全依靠測試執行者的能力，能力強的“白客”能夠發現有價值的安全性漏洞，而不具備很強的攻擊能力的測試者就無法有效發現系統中的安全性漏洞。必須承認，滲透測試是一種有效的安全性測試手段，當然，前提是你要能夠找到足夠好的測試執行者。
滲透測試是一種有效的測試方法，但由于它對執行者的能力要求太高，因此很難被大規模應用。站在測試的角度，我們是否能夠用“
自動化測試”這個強有力的武器幫助降低安全性測試的門檻呢？一個容易想到的“錄制/回放”方法是：將滲透測試的執行者們的操作錄制下來，形成腳本，期望這些腳本可以在不加修改或是稍加修改時應用在對其他應用的安全性測試中。但由于滲透測試的過程并不具有可重復的特點（測試執行主要依賴執行者的經驗，類似調試），這種想法在真實的安全性測試環境下完全不可行。完全自動化的工具通常只能發現那些可被用標準化方式發現的特定安全漏洞（如簡單的
SQL注入漏洞）。
模糊測試是一種介于完全的手工滲透測試與完全的自動化測試之間的安全性測試類型。它充分利用了機器的能力：隨機生成和發送數據；同時，也嘗試將安全專家在安全性方面的經驗引入進來。從執行過程來說，模糊測試的執行過程非常簡單：
測試工具通過隨機或是半隨機的方式生成大量數據；
測試工具將生成的數據發送給被測試的系統（輸入）；
測試工具檢測被測系統的狀態（如是否能夠響應，響應是否正確等）；
根據被測系統的狀態判斷是否存在潛在的安全漏洞。
顯然，模糊測試的整個執行過程是依靠工具進行的自動化測試。但是，看起來它完全是一個類似MonkeyTest工具的隨機數據生成器嘛，這怎么能和安全專家的經驗結合起來呢？別著急，我們用一個例子來演示一下。
為了簡單起見，假定我們要測試的應用是一個C/S應用的服務端程序。這個程序運行在Unix平臺上，名字叫做TgServer。我們唯一知道的信息就是客戶端和TgServer之間使用基于TCP/IP的自定義協議進行通訊。這種情況下，我們該如何嘗試找到應用系統中可能的漏洞？
方法1：
如果我們手頭上有TgServer的源代碼，通過代碼審查顯然可以找到可能的漏洞。就算沒有源代碼，通過逆向工程方式，用代碼審查的方式也可以達到找到漏洞的目的。當然，這必然要求審查者具有足夠好的技能，而且，被測應用規模越大，需要付出的成本也就越高。
方法2：
嘗試抓取到客戶端和服務器之間的通信數據，根據這些數據分析出客戶端與服務器之間的通信協議，然后根據協議的定義，自行編造數據發起攻擊，嘗試找到可能的漏洞。
方法2在成本上比方法1要低，而且由于方法2關注的是協議層面的攻擊，效率會更高。但是，稍微想一下，方法2還是存在一些問題：
完整的協議分析難度很大；
人工編造數據的成本很高；
在方法2的基礎上，我們嘗試引入模糊測試的概念，由于機器生成和發送數據的能力足夠強，因此我們完全可以把生成數據的任務交給機器去完成。當然，協議的分析主要還是依賴人工來進行，模糊測試領域內有一些自動化的協議分析手段（《模糊測試》一書中有專門的章節描述），但從效率和效果上來說，在面對復雜協議的時候，人工分析的方式更為有效。
假如根據抓取到的數據包，我們發現被測應用使用的協議如下（|僅表示字段間的分割，不是實際的數據內容）：
|00 01| GET | 11 | user:dennis
2字節的包頭（00 01）
10字節定長的命令（GET）
一個1字節的數據，表示命令參數的長度
不定長的命令參數
根據這些信息，使用模糊測試方法，我們就可以借助通用的模糊測試工具（如Spike），用模板方式將協議描述出來，并讓模糊測試工具自動填充可變字段的內容，生成大量的測試用例并發送給TgServer。同時，通過模糊測試工具提供的功能監視TgServer，一旦TgServer出現可被識別的問題（如性能下降，不再響應，或是返回異常數據等），我們就可以停止模糊測試，并通過日志找到導致問題的請求，進而確認問題。
簡單的說，模糊測試嘗試降低安全性測試的門檻，通過半隨機方式的數據發送來找出被測系統的漏洞。顯然，測試這對被測應用越了解，模糊測試的生成就能越準確。但與滲透測試或是代碼審查相比，模糊測試顯然更加易于進行。而且，通過自動化工具，模糊測試可以把安全方面的經驗積累到工具中，為組織持續的安全性測試提供幫助。
這是本系列的第一篇，后續還將寫兩篇來介紹不同類型應用的模糊測試，以及常用的模糊測試工具。
《模糊測試——強制發掘安全漏洞的利器》這本書全面覆蓋了模糊測試這一技術。
jira是個bug跟蹤管理系統，許多開源項目也使用它來進行bugtrac，如：jenkins。
用戶可以把產品中的bug report到jira上，創建問題issue并進行跟蹤。
issue的優先級（priority）和描述（description）如下：