軟件質量保證的實踐

常見的SQA的架構

 

我們持續演化，對于將軟件 QA 濃縮到所有開發任務完成后的測試階段的方法，它們的問題在于：會給團隊帶來巨大成本并將整個項目置于高風險之中。在測試階段，開發人員竭盡全力確保他們的代碼具有極少的缺陷。然后測試人員努力揭示軟件中每個可能的缺陷，而經理和客戶希望他們擁有適合向市場發布的軟件。

倉促的開發可能會為團隊節省片刻的時間，但是，如果有一些重大開發問題沒有從一開始就考慮到，最終可能導致需要投入更多的時間。結果是浪費了大量團隊資源來修復和重新設計代碼，而不是將這些資源投入到更有用的事情上。軟件團隊人員內心里對整個始末一目了然，但面對著嘮叨的客戶、嚴格的銷售團隊，以及一些自我感覺編寫了無缺陷的軟件的開發人員，軟件團隊確實很難將 QA 撇在一邊而只顧著完成代碼。

有幾種實踐方法，包括需求審核、代碼審核和演練、基于會議的測試、基于風險的測試等.

在開始每個新開發階段之前審核軟件需求，這樣做能夠最大限度地減少缺陷并滿足客戶的需求。在實現之前審核需求，這樣做有助于考慮潛在的變化，克服在項目的整個壽命中可能發生的誤解。團隊必須與客戶一起反復檢查所有應實現的業務領域細節。需求審核也可以使用原型和領域模型來完成。當開發團隊在開始實際實現之前完成這個小任務時，他們的項目或開發迭代會獲得良好的開局。通過確保在實現之前所有利益相關者都達成共識，并且每位團隊成員都意見一致，客戶和管理人員可確信開發人員將在開發周期結束時交付正確的成果。

而“代碼審核和演練”聽起來像很簡單，但代碼審核是軟件開發中最有效的實踐之一。它對減少缺陷數量以及增強代碼和軟件設計的質量具有直接影響。這消除了在未來的版本中執行重大的代碼重構和清理的需求。

依據項目需求和實現細節，團隊可能認同簡單的編碼和設計原則。團隊成員應共同遵守這些原則，而且只要開發一項新功能，一個或多個團隊成員（除了作者）應審核新代碼，并搜索所有編碼或設計錯誤。

這種做法可在許多方面為團隊帶來幫助，包括提高代碼質量和設計，最大限度地減少缺陷，并預防它們。另外，它還使得整個團隊能夠深入了解彼此的工作，輕松移交工作，并提高團隊對不同軟件組件和功能的認知。團隊協作驗證和證明代碼的質量和設計的實現方法。它們從同事那里獲得直接反饋。這么做可謂一舉兩得：代碼質量增加了，團隊的認知和項目責任也增加了。

第三個實踐是“基于會議的測試”，表示將測試負載分解為會議，每個會議有一個任務（一種希望從測試會議獲得的明確規定的結果）。每個會議有一個既定的時間范圍（從 20 到 40 分鐘），測試人員在執行測試會議期間不應中斷。

這就像將測試人員放在一個測試房間一段時間，讓測試人員專注于查找特定軟件特性或功能的缺陷。在會議期間，測試由一組測試案例引導執行，測試人員也可以執行探索性測試。因此，基于會議的測試是正式測試方法與測試創新的一種組合，因為它提供了測試人員房間來進行探索和獲得直覺思維，留出了時間和自由空間來發現不常見的缺陷，或者通過折騰軟件來進一步了解它。

會議期間，測試人員應將軟件的行為記錄在案，獲取快照，以及寫下軟件在特定輸入和設置下的行為。會議結束時，將與團隊領導或技術經理討論會議腳本。從他們的討論中，他們找出所認為的正常行為和不正常行為，然后基于討論創建缺陷報告。

另一種則是“基于風險的測試”，因為在開發流程中進行了一些更改，開發團隊通常擁有同一個軟件的許多常用版本。一種重要的 QA 實踐是在每個主要版本之后徹底測試軟件。另一方面，在每個版本中都對整個軟件運行全面的回歸測試既耗時又很難實現。但是，僅測試更改的功能或笨拙地刪減測試案例套件是不安全的。一段代碼可能解決了一個缺陷，但也可能破壞了代碼中的其他內容。

基于風險的測試方法采用了折中方式。它的基本理念是按降序對軟件功能和失敗模式排序，從最重要或風險最高到值得擁有的功能和簡單的風險（一個類似工具是 FMEA：失敗模式和影響分析）。如果測試人員在嚴格的時間限制下測試某個新版本時手頭有這個列表，他就可以集中精力確保新引入的更改不會破壞其他任何內容。然后就可以輕松地確保更改不會破壞軟件中的任何最重要的功能，因而不會發生任何最嚴重的風險。

我們期望是

測試和開發同時進行。編寫一些代碼，馬上進行測試和構建。接著，編寫更多的代碼，繼續測試。更好的是，在你編碼的時候或者編碼之前，就計劃好你的測試。測試不是一個獨立分開的過程，它是開發的一部分。質量不等同于測試；要想有高質量的產品，就要把開發和測試緊密捆綁在一起，直到不分彼此。

保證質量，預防勝于檢查：

質量來自開發，而不是測試。為了拓寬開發環節，我們可以把測試融入到開發中去。我們已經建立了一個超高效的增量流程，只要有一個增量被證明缺陷太多，我們就可以回滾這些錯誤。我們不僅預防了很多產品級問題，還大大地減少了那些為確保消除“召回級別”缺陷而安排的測試人員的人數。

衡量軟件質量的常用指標

軟件開發實踐過程中常用的幾個衡量軟件質量的指標，包括源代碼行數、代碼段/模塊/時間段內的平均Bug數、代碼覆蓋率、設計/開發約束等

源代碼行數（SLOC）

計算源代碼行數也許是最簡單的辦法。它主要體現了軟件的規模，并為項目的發展和規劃提供了有用的信息。比如，如果我們每月計算一次源代碼行數，那么就可以繪制一個項目成長圖。當然，這種方式并太不可靠，原因是重構和設計階段等因素會對此產生影響，但是至少可以為項目描繪一個趨勢。首先，使用代碼行數之和無法有效評估一個項目的實際進度，因為它更注重行為而不是結果。最終產品在多大程度上依賴于代碼的性能和質量，這也是代碼行數無法說明的。因此，聚焦于此實際上是非常有限的工作效率測量方式。SLOC無法表明要解決的問題的復雜性，也不能以可維護性、靈活性、擴展性等等因素來說明最終產品的質量。說到質量，它反而可能起到負面作用。通過重構、使用設計模式會減少代碼行數，同時提升代碼質量。代碼量大，可能意味著有更多不必要的代碼、更高不必要的復雜性、更加僵化難懂。

代碼段/模塊/時間段內的Bug數

缺陷跟蹤對于更好的測試和維護是必不可少的。通過缺陷跟蹤，我們可以利用報告工具（如Mantis）計算出每個代碼段、模塊或者特定時間段內的bug數量。憑借這些數據，我們可以盡早的查出和解決缺陷起因。Bug數量可能會作為衡量開發人員效率的指標之一，但是必須非常謹慎。如果把這項指標看得太重，那么開發人員和測試人員可能會成為敵人。在一個高效率的公司，所有的員工必須團結協作。為了更好地實現評估，bug可以被分為低、中、高等，因為這些缺陷的重要性和解決成本不是相同的。

代碼覆蓋率

代碼覆蓋率反映了程序當中源代碼被測試的程度。有許多自動化工具可以完成該功能，比如Cobertura。代碼覆蓋率不能完全代表單元測試的整體質量，但是可以反映出測試覆蓋率的問題。它可以和其他測試指標一起作為軟件質量的指標。同時，單元測試代碼、集成測試場景和結果應該經常地被審查。

有效的代碼度量模型應具備以下特征：

• 與組織的目標一致：代碼度量模型的底線要與組織的要求一致，和業務相關的東西會體現在規范里。在支付寶，代碼安全規范、敏感信息處理規范被作為代碼質量最基本的要求。
• 有針對性：要做針對性分析，比如對線上故障的研發原因進行分析，分析的規則會有周期性變動的，但不要太頻繁，而且規則會隨著組織的成熟度而改變。
• 可操作性：要對度量維度做進一步分解，比如測試要有明確的檢查點，覆蓋要完整，可重復運行。支付寶就制定了具體的度量維度，從多個維度對系統加以度量。
• 有工具支持：這不是必要條件，工具不能解決所有問題！能用工具最好，不行的話就人工檢查。工具檢測維度要按照優先級和操作性，逐步增加精細化維度。這一點上，支付寶將一些編碼規則的檢查放入了持續集成工具之中，以求盡早檢查、頻繁檢查。

設計/開發約束

在軟件開發過程中，存在許多設計約束和準則，其中包括：

• 類和方法的長度
• 單個類里方法和屬性的個數
• 方法或者構造函數的參數個數
• 代碼中的魔數、字符串用法等等
• 注釋行比例等

 

研發流程

整個研發做到了類似于火車發車的發布過程：

1. 各個bundle在有著自己的需求、開發、測試計劃，相互獨立。
2. 主項目制定發布計劃，確定集成窗口和發布時間點。
3. 在集成窗口時間bundle可以自主提交集成。
4. 集成提交需要走流程，包括填寫checklist、代碼檢查、bug統計、提前編譯預集成包進行測試等。這就避免了明顯的集成問題遺漏到集成環境中。
5. 集成期間的集成包每天出一個或者兩個，避免了測試人員不斷拿包回歸的情況。
6. 集成窗口對于時間要求嚴格，趕不上計劃或者質量不達標的bundle不予集成。這就是火車不等人的原則。
7. 以上機制保證了手機淘寶每天都有一個候選包，可以隨時進行灰度發布，并且灰度發布單獨拉取一個依賴配置分支，不影響集成窗口。
8. bundle的獨立，依賴配置的獨立保證了手機淘寶可以并行多個發布計劃，各個bundle可以按照需求自主決定搭乘哪個發布計劃進行發布。
9. 目前項目節奏為兩個星期發布一個版本。如果需要還可以更快的進行發版。最短只需要1個小時就可以發一個新版。

所有的項目生命周期都有相應的平臺工具支持，如下圖：

質量保證手段

有了高效穩定的流程，剩下的事情就是如何保證產品在快節奏的持續交付下的保持很高的質量。質量保障上面手機淘寶研發團隊做了幾方面事情：

1. 流程方面

1）創建了提測單、集成單、發布單等流程。建立了標準，并依托平臺自動檢查，提高了交付的質量。

2）建立持續集成體系，不但能提早發現更多的問題，而且提升了測試人員拿到的包的質量。

3）建立線上線下監控分析體系。

2. 包穩定性方面：

1）bundle階段根據項目進度自己控制提測包的頻率，集成階段每日驗證DailyBuild即可，所以解決了之前測試同學不斷安裝新版本的包的問題。

2）研發階段的包內部支持環境切換，這實現了只構建一次，環境根據配置切換的夢想。測試時手機上只需要安裝一次包即可完成多種環境下的測試。

3. 自動化測試與測試工具方面

1）引入多種靜態掃描引擎，并定制多種規則：適配規則、Crash規則、框架約定規則、安全規則等，并且不斷地將測試階段、線上問題等總結抽象成新的掃描規則補充進入掃描引擎。

2）在測試階段包種插入相應的測試SDK，并且這種SDK不會侵入應用代碼，所以只需要在發布的時候去掉測試SDK即可。測試SDK可以在測試人員（包括外包適配測試人員）正常使用過程中自動檢測并上報問題，這樣就可以在同一的平臺上看到研發過程中的質量情況并進行修復。

3）自動化平臺方面也在根據測試經驗不斷的進化，在整個研發過程中自動化測試一直在執行，不僅可以提高產品穩定性，也可以發現性能、電量等非功能問題。

4）mock工具、驗證平臺等輔助測試工具也提升了測試人員的效率。

4. 線上線下監控分析

1）線下質量數據、線上業務問題、輿情反饋等信息統一匯集到平臺上進行統一的分析告警，不僅能快速的發現問題，而且能通過數據分析能夠幫助快速定位和解決問題。

2）根據平臺中的數據，可以用經驗推動流程的優化、補充測試用例、添加掃描規則、增加自動化場景、催生新的測試工具等，這樣可以使經驗形成閉環，使質量保障工作更加高效。

在敏捷開發過程下質量保證

對于目前的開發架構來說，一個用戶故事，涉及這四個點，可以從這四個點入手來進行質量保證。如何做呢？單元測試就開發人員處理了；代碼審查，測試人員可以參與和監督，其實就是要保證：將開發任務與提交到Git的代碼進行關聯。這樣一來，當測試人員檢查開發任務的時候，就可以找到改變過的代碼。我曾經試過從這些代碼里面查看邏輯，找到分支場景，補充到測試用例里面。

Scrum中測試人員價值應當體現在：

1. 預防缺陷的手段，提高洞察力，增強業務知識。
   缺陷在需求、開發前期就已經存在了，關鍵是用什么手段去挖掘出來預防。在sprint前獲取到的需求，測試人員可以站在客戶角度上來闡述自己的觀點，與開發人員進行充分交流和討論，使自己在用戶體驗、業務邏輯等等方面的經驗充分體現出來。

2. 在開發過程中，測試人員除了站在客戶的角度進行測試，還應當提供更全面的質量反饋，包括代碼質量的檢查，這個可以通過redmine與git雙向關聯來做檢查依據。目前整個過程測試人員尚未參與代碼編寫，應當參與并推進代碼評審，將代碼問題及時反饋出來；并且參與或者推進單元測試，檢查單元測試狀態（確保單元測試達到80%以上覆蓋率，幫助開發人員開發出具有良好可測試性的代碼），自始至終將質量問題及時反饋出來，保證在sprint的整個過程中質量受到足夠的關注，提高質量改進的持續性和可視性。

3. 隨著版本任務的增加，每個版本回歸測試的成本增加，可以適當考慮部分穩定功能進行自動化測試。當然，這是遠景。

4. 持續改進、反饋，充分發揮每個版本統計報告的作用，對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。

敏捷中的QA日?；顒?/h3>

從迭代到發布，敏捷測試的生命周期各個階段QA的活動主要有：測試分析，測試自動化策略分析、框架構建等，故事測試，迭代計劃會議和客戶演示，測試自動化的維護和執行等。如下圖示：

QA通常不是僅僅工作在某個迭代，而是并行的同時工作在多個迭代：要對當前迭代的故事進行驗收測試、探索性測試，和開發人員結對實現測試自動化；還要和業務人員結對分析下一個迭代的故事，編寫驗收標準和測試用例。

在單個迭代內部，伴隨著故事生命周期，QA的活動有哪些呢？用戶故事生命周期包括以下幾個階段：故事分析、故事計劃、故事開發、故事驗收、故事測試／探索性測試、系統測試和客戶演示。QA參與故事的整個生命周期，在每個階段都會發揮作用。

• 故事分析階段：需求澄清，業務場景和驗收測試的確認
• 故事計劃階段：拆分測試任務，在每個故事開發估算基礎上考慮測試的時間和估算
• 故事開發階段：和開發人員結對實現自動化測試，和團隊溝通發現的問題和缺陷
• 故事驗收階段：開發人員開發完故事后，QA和業務分析人員要在開發機器上進行驗收，以提供快速的反饋；同時還要對測試覆蓋率（單元測試、組件集成測試、功能測試）進行確認和提出反饋
• 故事測試／探索性測試階段：執行自動化驗收測試，執行探索性測試，強調會阻礙故事發布的因素，和團隊就測試覆蓋率進行溝通，為發現的缺陷添加自動化測試
• 系統測試和客戶演示階段：執行端到端的系統測試，執行業務或集成的用戶測試場景，和團隊及客戶就功能特性的質量和穩定性進行溝通，參與給客戶演示功能和特性

正如前面提到的，在每個階段，QA除了要獨立進行測試，通常還需要跟不同的角色結對，包括業務分析人員、開發人員、以及客戶。

• QA與業務分析人員結對：通常在業務分析師分析用戶故事的時候，QA要與業務分析人員結對編寫驗收標準。通過與業務分析人員結對，QA能夠更好的理解領域知識，從而有利于定義合適的測試用例；QA從測試角度添加的驗收測試用例可以幫助整個團隊對產品功能性有更好的理解。
• QA與開發人員結對：QA和開發人員分別能給團隊帶來不同的技能集，認識到這一點很重要。作為一個團隊，最好通過平衡不同的技能集來獲得共同的目標。這對于傳統的瀑布式團隊來說是一個很重要的心態改變。通常在實現測試自動化的時候，QA與開發人員結對是比較理想的方式。這樣結對實現的自動化測試質量相對較高，有測試意識較強的QA參與能夠保證自動化測試測得是真正需要測試的部分，而開發人員的編碼能力有利于寫出簡潔可維護的自動化測試代碼。另一方面，QA通過與開發人員結對，編碼能力也會相應有所提高，而開發人員通過與QA結對，測試意識也會增強，更有利于編寫質量較高的產品代碼，更有利于形成全功能團隊。
• QA與客戶結對：客戶是業務領域專家，通過與客戶結對，QA能夠更好的從終端用戶的角度理解系統，從而定義或者增加更多的端到端的測試用例；一旦QA理解了領域知識和終端用戶的觀點，其業務價值分析能力會有所提高，在團隊需要的時候可以承擔業務分析角色；在用戶驗收測試（UAT）階段，QA通過與客戶結對，幫助客戶熟悉使用系統，在必要時可以幫助客戶解決一些系統問題。

敏捷QA的這些日?；顒?，的確反映出敏捷QA的日常工作內容和方式都跟傳統開發模式下的測試人員有很多不同。

敏捷QA與傳統測試人員有何不同。我們分別從團隊構成、測試階段、工作方式、關注點、業務知識來源以及發布計劃制定幾個方面，來看看敏捷QA與傳統測試人員有哪些不同：

傳統測試人員	敏捷QA
單獨的測試團隊	多角色開發團隊的一員
在開發流程后期才開始測試	測試貫穿于整個開發流中
通常是獨立工作	QA和不同角色進行結對
被當作最后也是唯一的質量保證	關注并強調風險
缺乏與業務人員的直接溝通	和業務人員直接溝通
沒有機會參與發布計劃制定	參與發布計劃的制定

從上表的對比可以看到，敏捷QA是特殊的，主要體現在：

• 敏捷QA是提出建議者而非看門人，需要在參與的每個階段提出自己的建議，而不是等到開發流程最后來對系統進行驗證；不僅要驗證開發設計是否滿足需求，還要發現需求是否能真正體現業務價值，分析是否有不恰當或缺失的需求。比如說，敏捷QA在跟業務人員結對編寫驗收標準的時候發現故事分析過程中漏掉的需求，在跟開發人員結對過程中跟開發人員討論某個測試放在哪層實現比較合理等。
• 發現風險，并將風險與團隊及客戶溝通。QA參與整個開發流程，對系統整體的認識和把握可以說是團隊里邊最全面的，因此也更容易看到系統存在的風險。
• 及時向團隊提供關于產品質量的反饋，便于調整。在每個迭代結束時候，QA需要分析統計該迭代的缺陷，并結合自己通過測試對系統質量的了解，及時跟團隊反饋，討論分析質量下降的原因以盡快作出改進，或總結質量上升的經驗，鼓勵團隊再接再厲。
• 在制定產品和版本的發布計劃的時候，QA可以根據自己對產品質量的了解，從測試人員獨有的視角提出一些關鍵的建議。
• QA通過參與開發流程的每個階段，能夠協助團隊從內部提升質量，讓質量融入到產品開發中來。比如：在故事驗收階段對測試覆蓋率的確認。

這些特殊性對敏捷QA也提出了更高的要求，需要做到：

• 具有豐富的產品知識和對用戶業務目標的準確了解
• 對不同系統和數據庫所用到的技術知識的了解
• 和不同角色以及客戶進行有效溝通
• 主動驗證質量目標并及時說出自己的想法
• 編寫測試計劃，列出需要執行的活動并進行估算
• 自動化測試的能力和對測試工具的基本了解
• 在團隊內部進行知識分享，協助整個團隊參與到測試活動中來
• 持續提供并獲取反饋

敏捷軟件測試的七個關鍵成功要素

包括?使用團隊整體參與的方法、采用敏捷測試思維、?自動化回歸測試、提供并獲取反饋、構建核心實踐的基礎、與客戶合作、保持大局觀等。

1. 使用團隊整體參與的方法

當整個開發團隊負責測試和質量問題，你會擁有很多不同的技能集合和經驗等級來處理測試可能發生的問題。測試自動化對于技能高超的開發人員來說不是大問題。當測試置于團隊的優先權，任何人都參與測試任務，團隊才會設計可測試的代碼。使測試人員真正成為開發團隊的一部分意味著向他們提供支持和訓練他們適應敏捷開發的快節奏。他們需要時間掌握新技能以便與開發和客戶團隊緊密協作。

如果你管理一個敏捷團隊，幫助團隊使用團隊整體參與的方法。記住質量，而不是速度，才是敏捷開發的目的。團隊需要測試人員幫助客戶理清需求，轉化為指導開發的測試，提供發布優秀產品的唯一觀點。確保測試人員能夠把技能和長處轉移到團隊其他成員身上。確保他們不是局限于一種角色，如只做手動測試。確保當他們需要幫助時（可能需要極大的勇氣），團隊成員能夠提供。反過來也是如此。測試人員應該隨時準備幫助那些需要他們幫助的隊友。

如果你是敏捷團隊中的測試人員，并且計劃會議和設計討論沒有邀請你，或者業務用戶正在獨自定義故事和需求，那你應該站出來和團隊的其他成員交流。和開發人員一起參與會議，并提議嘗試“三方協作”，即測試人員、開發人員和業務專家。謹慎地提供反饋并幫助客戶提供例子。讓你的問題成為團隊的問題，讓他們的問題成為你的問題。請你的同事采用團隊整體參與的方法。

2. 采用敏捷測試思維

我們提醒敏捷測試人員丟掉一直以來的“質量警察”思維?，F在你在敏捷團隊中，開發人員參與測試，測試人員可以做任何事情以幫助團隊生產最優秀的產品。敏捷測試態度是前瞻性的、創造性的、歡迎新思想、樂于承擔任何任務。敏捷測試人員不斷磨練自己的技能，隨時準備協作，相信直覺，希望幫助團隊和業務成功。我們并不是說你應該披上超級測試王的斗篷，去保護世界免受缺陷的危害。在敏捷團隊中不存在狂妄自大。團隊成員分享你對質量的追求。關注團隊目標，幫助每一個更好地工作。使用敏捷準則和價值觀指導你。不斷嘗試最簡單的方法來滿足測試需要。勇敢地尋求幫助和實驗新想法。關注于產生價值。盡可能多的直接交流。靈活地應對變化。記住敏捷開發以人為中心，我們應該享受工作。當對此懷疑時，回顧敏捷價值和準則來決定該怎么做。

敏捷測試思維的一個重要部分是不斷想辦法改進工作。成功的敏捷測試人員持續地磨練技能。讀好書、博客和文章以獲得新想法和技能。參加本地的用戶組會議。加入郵件列表討論以獲得問題或者新想法的反饋。如果你的公司沒有付錢讓你參加一個很好的會議，那么把你的經驗寫成報告在免費的會上作交換。對測試和敏捷開發社區進行反饋也會對你有益。實驗新的實踐、工具和技術。鼓勵團隊嘗試新方法。短期迭代非常適合這種實驗。你可能會失敗，但是很快你可以嘗試其他的。如果你管理敏捷測試人員或者敏捷團隊，給他們時間去學習并提供所需的培訓支持。移除障礙使他們更好地工作。當你面對影響測試的問題時，讓團隊都知道這些問題。通過頭腦風暴的方式克服這些障礙?；仡檿h可以討論這些問題并想辦法解決。維護一個阻礙事項列表，并在每個迭代中解決一到兩個。使用可視化的大圖片或者虛擬方式，確保所有人都知道發生的問題并可以跟蹤編碼和測試的進度。

3.自動化回歸測試

敏捷團隊沒有測試自動化會成功嗎？可能吧，但是我們所知道的成功團隊都依賴自動化回歸測試。如果你花費全部時間用在手動回歸測試上，絕沒有時間用于重要的探索性測試（會發現隱藏在代碼中的危險行為）。敏捷開發利用測試來指導開發。為了編寫代碼使測試通過，你需要快速、簡單地運行測試。沒有短期反饋周期和安全的回歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。

自動化回歸測試是團隊的工作。整個團隊應該選擇每種測試適合的工具。提前考慮測試將幫助開發人員為了便于測試自動化來設計代碼。使用敏捷測試象限和測試自動化金字塔來幫助你自動化各種類型的測試。記住從簡單入手。你會驚訝地發現一些基本的自動化冒煙測試或者自動化單元測試會發生很大作用。測試自動化是團隊的工作。開始時很艱苦，需要克服很大的痛苦。如果你管理開發或者測試團隊，確保在時間、培訓和激勵上提供了足夠的支持。如果你是沒有自動化測試的團隊的測試人員，開發人員瘋狂地編寫代碼以至于不會停下來考慮測試，那么你會面臨很大的挑戰。嘗試從管理層和團隊成員中獲取支持以開始小規模的自動化工作。

4.提供并獲取反饋

反饋是敏捷的核心價值。敏捷的短期迭代可以提供持續的反饋以幫助團隊運轉正常。測試人員通過自動化測試結果、探索性測試的發現和系統實際用戶的觀察結果的形式幫助提供反饋。敏捷方法允許團隊獲取有關構建中軟件的反饋。這是關鍵。故事代表了測試人員和分析人員向開發人員提供反饋的工作單元。迭代發布有助于團隊外部的反饋。大多數敏捷實踐都創建了反饋循環使團隊應用。測試人員也需要反饋。你怎么知道從客戶手里拿到了預期行為的正確例子？你怎么知道編寫的測試用例正確地反映了這些例子？開發人員通過查看你收集的例子和你創建的測試能夠理解應該編寫什么代碼嗎？一個最有價值的技能是學習如何尋求自己工作的反饋。詢問開發人員是否得到了足夠的信息以理解需求并且是否能夠指導編碼。詢問客戶是否理解質量標準?；〞r間參與迭代計劃會議和回顧會議以討論這些問題并提出改進方案。

5.構建核心實踐的基礎

• 持續集成

每一個開發團隊都需要代碼管理和持續集成。如果不知道自己在測什么，就無法有效地測試，如果無法配置代碼你根本無法測試。所有團隊成員需要至少每天一次導入自己的工作。每一次集成必須通過自動化構建驗證，其中包括提供軟件狀態快速反饋的測試。實現持續集成過程應該是軟件開發團隊中優先級最高的事情。如果團隊沒有每日構建驗證的版本，停止手里的工作，開始構建。就是這么重要。一開始并不要求太高。如果你有很大的系統需要集成，肯定會更具挑戰性。通常來說沒有那么困難，市面上存在很多優秀的工具，開源的、商業的。

• 測試環境

沒有可控的測試環境就無法有效地測試。你需要知道部署了什么版本，使用的數據庫模式是什么，其他人是不是正在更新，其他進程是否運行在那臺機器上。硬件總是越來越便宜，開源軟件越來越多。團隊必須投資以有效地執行自動化和手動探索性測試。如果測試環境出現問題，趕緊說出來，讓全隊一起解決。

• 管理技術債務

即使優秀的軟件開發團隊在感覺到時間壓力之后，也會忽視重構或者快速解決問題修補缺陷。隨著代碼越來越混亂和難以維護，更多的缺陷出現，很快團隊的速度就慢了下來，因為要解決缺陷才能添加新的功能。團隊必須不斷地評估技術債務的數量，并努力減少和避免。大家經常說：“我們的管理層不會給我們時間做這些，沒有時間重構，日程很緊”。但是，我們可以很容易舉一個業務用例來顯示增長的技術債務如何耗費公司的成本。衡量代碼和缺陷率哪些會導致技術負債變為對底線的影響存在很多辦法。僅僅指出不斷下降的速度就足夠了。業務需要軟件開發團隊保持持續的生產力。他們不得不減少期望功能的范圍以保證足夠的時間來進行良好的、測試規范的代碼設計和優秀實踐，如持續小規模重構。自動化回歸測試的良好覆蓋率是最小化技術債務的關鍵。如果缺少，那就在每個迭代中拿出時間來構建自動化測試，規劃一個“重構迭代”以升級或添加必要的工具，編寫測試并進行重構。在每個迭代中花時間通過測試指導代碼，重構必要的代碼，添加丟失的自動化測試。對這件工作要重視。長期來看，團隊能夠變得更快。

• 增量工作

敏捷團隊能夠生產高質量代碼的一個原因是他們小規模地工作。故事代表了幾天的工作量，每個故事被分解成小增量，按步構建。測試可以針對一小塊，并且隨著功能聚集再增量測試。如果團隊成員喜歡一次開發一大塊功能，鼓勵他們采用步驟式的方法。提出問題：“這個故事的核心業務價值是什么？這塊代碼的最基本路徑是什么？下一步干什么？”建議大家編寫任務卡片以編碼和測試小增量，記錄設計概念和確認測試和測試自動化策略。

• 編碼和測試是同一個過程的組成部分

對敏捷思想不熟悉的人經常會問敏捷測試人員：“在所有故事完成并且可以測試的時候你會怎么做？”經驗豐富的敏捷實踐者會說：“測試人員必須貫穿整個迭代，整個開發過策劃那個。否則就會失敗”。測試人員基于客戶提供的例子編寫測試，以幫助開發人員理解故事并開始編程。測試和例子提供了一種通用語言使所有人都參與到軟件理解中。測試人員和開發人員在編碼時緊密合作，他們也會與客戶緊密合作。開發人員向測試人員展示他們編寫的功能，測試人員向開發人員展示他們發現的異常行為。測試人員隨著編碼進展編寫更多測試，開發人員是其通過測試，測試人員進行更多探索性測試以了解是否生產了正確的價值。每一個敏捷迭代包含了若干持續、快速、增量的測試——代碼—— 測試——代碼——測試迭代。當這種合作和反饋周期被打斷，并且測試與開發分離時，糟糕的事情會發生。如果故事是在編碼之后的迭代中被發現的，開發人員不得不停止新的故事，回憶代碼是如何實現上個迭代的故事的，修補它，并且等待其他人測試。在軟件開發中沒有什么幾個事實，但是我們確定缺陷發現的越早，修補的成本越低。當編碼一直由測試指導，編碼的同時進行測試，我們更有可能達到客戶預期的行為，提供客戶所需的價值。測試是團隊的職責。如果團隊沒有這種觀念，讓所有人想一想對質量的關注、對發布優秀產品的期待和采取哪些措施來確保團隊實現目標。

• 實踐之間的協作

單個敏捷開發實踐如持續集成能夠發揮作用，但是多個敏捷實踐的組合比各個部分相加要大。測試驅動設計、共有代碼所有權和持續集成一起促進快速反饋、持續改進代碼設計和快速產生業務價值。自動化測試很好，但是使用自動化測試驅動開發，隨后是探索性測試以發現缺陷或者弱點，分多層次更好。某些實踐單獨操作并不好。沒有自動化測試，重構是不可能的。通過迷你瀑布型的方式發布小版本會丟失敏捷開發的所有優勢。如果你的現場客戶沒有做決定的授權，那么他對團隊的價值有限。敏捷實踐是互補的?；〞r間理解各個實踐的目的，想想如何利用全部優勢，針對什么對團隊有用做出深思熟慮的決定。

6.與客戶合作

測試人員對敏捷團隊的最大貢獻之一是幫助客戶理清需求并設定優先級，通過預期行為和用戶場景的具體例子描繪需求，并把這些例子轉換為可執行的測試。測試人員使用業務的領域語言和開發團隊的技術語言。我們擔任優秀的輔助者和翻譯。千萬不要阻礙開發人員和客戶之間的直接溝通。鼓勵盡可能多地直接交流。使用“三方協作”方法。當需求丟失或者被誤解，客戶、開發人員和測試人員需要一起解決問題。請客戶經常在白板或者其他虛擬工具前討論問題。如果客戶發布于不用的地區、國家，那就使用任何能找到的工具來加強溝通和協作。電視會議、即時消息和 wiki不能完美的替代面對面的交流，但是也比發郵件或者什么都不做要好。

7.保持大局觀

我們發現測試人員有大局觀，通常從客戶的角度看問題。開發人員通常關注于實現當前的故事，雖然他們使用測試來指導，但是不得不關注于需求的技術實現。大局觀對團隊貢獻巨大。測試驅動開發，如果完成得很好，單獨的代碼沒有缺陷。如果新的功能導致一些應用明顯不相關的部分崩潰怎么辦？一些人不得不考慮這種對較大系統的影響并引起團隊注意。如果我們忽略了一些可能惹惱客戶的細節怎么辦？新的UI可能沒什么缺陷，但是如果背景顏色使文本難以閱讀怎么辦？這都是最終用戶會注意到的問題。使用敏捷測試象限作為綱領來幫助規劃測試覆蓋所有范圍。使用測試金字塔思想確保測試自動化的良好投資回報率。通過測試指導開發有助于確保你沒有丟失重要的事情，但并不完美。使用探索性測試了解系統應該如何工作，測試應該指向哪個方向。讓你的測試環境盡可能與生產環境類似，使用反映現實世界的數據。勤于重新構建一個生產環境類似的場景，如負載測試所需。團隊的每一個人都很容易只關注手邊的一個任務或者故事。這是一次只做一塊功能的缺點。幫助你的團隊后退一步，評估當前的故事如何負責業務的大局。不斷問自己如何才能更好的產生真正的價值。

互聯網產品下質量保障

質量保障的核心目標是質量 & 效率并重，對于互聯網產品來說詮釋如下：

質量

i.不僅僅是功能可用性層面，需要關注用戶體驗。

ii.不僅僅是上線前的質量保證，需要延伸至把關上線中、線上的質量。

iii.不僅僅只停留在好壞的感性模糊認識，需要將質量概念量化、可視化。

iv.不僅僅光靠抽樣個例，需要大數據統計做強有力的支撐。

v.不僅僅只局限自身產品的質量，也需要關心競品。

效率

i.加快產品迭代，唯快不破。

ii.提高問題暴露，定位以及解決速度，快中求穩。

對產品建立質量標準，將其度量化并形成穩定的、可衡量的產品質量benchmark，對于產品可以列出數據完整性、安全性、傳輸速度、在線消費體驗等最核心的質量維度。線下以此作為發版標準，驅動產品質量迭代越來越接近目標；線上以此作為監控范圍，對線上質量問題主動防御，加快應對。

“以質量為中心，以數據為驅動”為宗旨貫穿整個流程，將各種測試工具和方法融入進來，構筑一套全流程質量保障體系，如下圖所示:

 

二、測試技術

線下集成持續化、測試服務化，以應用質量（QPS、SLA、性能）、業務指標、過程質量（代碼覆蓋率，千行 bug 率）一系列發版標準為目標，將自動化測試、性能、單測、異常等工具集成入構建—部署—quickcheck—slowcheck—release 的流程中，快速發現問題并解決，迭代質量。線下需要更多精力關注在異常和性能測試中，這些往往是線上問題多發區。

上線過程中灰度控制，把產品發布過程劃分為多個級別，每個級別限制一定的流量和用戶范圍，并在每個級別對產品進行部署和驗證的迭代過程。一方面逐步放量，小心驗證，降低上線帶來的風險；另一方面開展用戶測試，讓用戶參與產品測試，加強與用戶互動。讓用戶參與 beta 環境分為兩種情形：被動命中（將同一特征的用戶強制劃分至小流量環境中）和主動邀請（邀請粉絲或有償用戶）。對服務器來說架構能夠支持逐步放開流量，對客戶端發版來說有一個平臺支持哪些版本哪些用戶能升級到beta版本，并且在小流量階段要密切關注監控和用戶反饋，將問題及時扼殺在萌牙階段，不帶到全量階段。

線上監控 & 定位，從基礎拓撲（網絡、單機、數據庫等底層服務）、服務穩定性（接口成功率、5XX、4XX非預期返回碼的占比等服務器可用性層面）和業務質量（上傳、下載的成功率等用戶功能層面的易用性）三個核心要素延展開全方位細粒度的監控覆蓋，并從質量標準、質量防線和質量閉環三個維度進行質量建設：首先對產品建立一套完善的產品質量標準體系，并將其度量化，固定成 benchmark。緊緊圍繞質量數據，組建從用戶（輿情熱點）、端（產品體驗）、服務器（穩定性）到基礎網絡（SLA）的層層實時防護網，最后通過上線管理—報警中心—智能定位—故障通報的質量閉環環節落地，不斷迭代優化，能夠快到線上問題快速預警、定位及解決。

三、專項質量保障

（1）多副本分布式存儲：旁路測試 & 線上數據檢查，以數據完整 & 安全為使命

考慮災備冗余、成本因素，云存儲都會使用多個機房，跨機房的傳輸相比單機房的數據流動本身即增大了延遲，不同機房網絡屬性、機器性能等差異更對服務質量的保障提出了挑戰。單一的機器性能測試已經不滿足需求，需要引入旁路測試：復制線上的部署拓撲，進行等比例縮放，仿真線上的數據，在測試環境里重放，觀察復雜部署和網絡環境下服務的穩定性，輔佐一定的異常流量，評估系統的容錯性以及災難發生時預案是否能生效等。為更進一步保障數據的安全，對線上每日新增的數據較驗各個副本的一致性及完整性。

（2）多機房 & P2P 流量架構：流量 diff 系統 & 實網系統 & 眾測測速，傳輸速度體驗

下載由源站IDC、CDN和P2P三部分承擔，用戶端、網絡端、服務器云端的每一個環節都會影響速度。服務端的流量調度是根據用戶地點、運營商網絡、請求入口、文件所在機房、資源熱度等多重屬性對用戶分配多個可帶優先級的下載域名，讓客戶端充分并發及容錯。多重維度的組合注定了調度策略的復雜性以及驗證的難度，流量 diff 系統應運而生：在線下構造兩套流量系統，一套線上代碼環境，一套測試代碼環境。通過回放線下真實流量，diff 前后調度是否符合預期，是否帶來了非預期的變化。

三、最終

從質量標準、質量防線和質量閉環三個維度進行質量建設。首先對產品建立一套完善的產品質量標準體系，并將其度量化，固定成 benchmark。緊緊圍繞質量數據，組建從用戶（輿情熱點）、端（產品體驗）、服務器（穩定性）到基礎網絡（SLA）的實時防線，最后通過“上線管理—報警中心—智能定位—故障通報”的質量閉環環節落地，不斷迭代優化。

文化價值驅動質量

產品也是創造它們的文化產物。麻省理工學院馬丁信托創業中心的總經理Bill Aulet，同時也是麻省理工斯隆商學院的資深講師，提醒我們：文化會吞噬策略，并且，我質疑流程也一樣會被文化所吞噬。當組織文化與流程改變的精神相沖突時，例如當命令式與控制式的文化試圖通過自管理，敏捷團隊來達到生產率的目的，每一次沖突都會是文化獲勝。文化通過組織的價值觀、標準、信念和習慣表現出了自己，這些表現形式進而通過規范團隊行動的方式產品質量產生影響。我的這一觀點并非來自某個組織的報告說明，而是通過組織在每一個級別上的行為所得出的。首先，組織的價值觀通常能夠幫助團隊排列出優先級最高的任務。

1. 領導重視。關于質量，領導需要展示如何“付諸行動”。并且必須來自于上層的授意。你可以通過如下方式來達成這一點：
   • 跟蹤質量度量。定義高層領導、產品經理、質量保證人員和工程師都認同的有意義的質量測量。
   • 讓你的度量可見。經常把在會議中提到它們，并且和你的團隊定期地回顧評審。
   • 用質量做取舍。對最小質量級別創建清晰的定義和規范，當鄰近發布時需要做出取舍時，就可以在會議中使用它們。當團隊看到質量度量用于決策的取舍時，他們就會了解為什么要重視質量了。

   特別要注意的一點是，當你要在組織中介紹或改變度量的時候。就像其他任何變化一樣，至關重要的是在采取這個改變時要在大家的認同和強行執行之間權衡利弊。度量的風險在于，不同的團隊可能已經在使用自己的度量方式了，他們會著重于強調他們所感興趣的部分。因由于度量的目的是全面地測量和轉變團隊的行為，因此關鍵在于讓所有的干系人（高層領導、產品經理、質量保證人員和工程師）認同并且堅持某些通用原則，你可以通過如下方式來達到：

   • 有目的地建立一個跨職能的工作組。清晰地說明出，如果沒有度量的情況下，當前存在的痛點，為什么必需要采取行動，以及常見的度量是如何幫助我們的，通過這些來激發大家對度量的需求。邀請那些有影響力的干系人，讓來自于不同部門的高層領導、產品經理、質量保證人員和工程師來設計度量。在討論的過程中，每一個參與者都代表了他們團隊感興趣的部分，也幫助了我們把度量在內部推廣給其他人。選擇一個好的引導師，并且請確保在度量設計完成之后，明確地要求參與者把這個結果推銷給他們的同事。
   • 對有價值的產出進行測量。讓工作組首先識別出不同的干系人所關心的、他們理想中的定性的產品產出是什么。一旦這些識別出這些產出之后，然后再邀請小組人員返回度量設計，選擇促進或偏離每一個產出需要的測量。比方說，假設你的產品是一個云應用，計算成本上升的速度比使用的增長速度還快，高層管理人員對此問題表示關注。工作組可能會識別出各種度量來測量有效性，例如各臺服務器的CPU使用率，而這是可以在開發和測試階段進行監控的。一旦這些度量最終被確定和使用，請展示給你的團隊并告訴它帶來的影響是什么。
   • 對跨團隊的度量進行標準化。讓工作組創建模板或者儀表盤，因此所有的團隊可以以此進行度量的查看。邀請每一位參與者展示他們特定團隊的結果，并且確保各個團隊統一使用這些標準工具。因為每個職能部門都對該流程表達了自己的觀點，并且清晰地設定了期望。因此這些度量就可以讓每個人在以后工作中使用。
2. 消息的可靠性。成功的經理人都會根據與團隊的共鳴度謹慎地選擇正確的方式去溝通有關質量方面的消息。做好這一點也許需要經過一些試驗。從不同的內部或外部的干系人的視角來溝通產品質量，看看如何激發你的團隊。例如以下幾種方式：
   • 客戶滿意度。采訪或調查客戶對產品的整體滿意度，在過程中注意以語言引導他們的情緒。
   • 演示中的銷售體驗。就像任何一個銷售代表會告訴你的一樣，在預期演示的時候出現產品崩潰會帶來十分嚴重的傷害，并且會讓銷售代表很難堪。應該注意了解銷售代表在演示產品中的表現，以及他們在演示中產品所表現出的可靠程度。
   • 高層領導的看法。在很多組織中，高層領導（尤其是創始人）喜歡動手嘗試新的產品功能。在鄰近發布時，邀請他們參與使用，并且詢問他們的體驗。
3. 同事參與。一旦他們開始彼此參與度量時，你的團隊可能會將質量深入內心，你可以通過下面不同的步驟來鼓勵團隊：
   • 在設計階段創造一些儀式。在設計討論階段，幫助你的團隊開發一個流程來評估不同設計方案對質量的影響。為團隊準備一些問題，讓他們回答他們所考慮的每一個方案對質量的影響，并且在發布之后展示這些問題是如何對整體的質量做出貢獻的。
   • 邀請同事評估。在定期的狀態審核會議中，為你的團隊展示最近的質量度量情況，并且要求每個人站在他們的立場做自己的評估。哪些是他們同意的，哪些是他們對結論有分歧的？不管答案是什么，只要邀請團隊做他們自己的評估，就會讓他們注意到質量。
   • 鼓勵結對編程。如果定期實施結對編程，尤其是在初級的和資深的開發人員之間進行結對，這會鼓勵大家在設計和實施的階段討論質量的問題。鼓勵你們團隊的資深開發人員在每一次結對編程的過程中進行討論。
4. 員工的主人翁意識和授權。你可以給你的團隊授權，讓他們做質量決策，并且通過這個結果，他們會感到更強的主人翁意識?？梢钥紤]到用以下方式實現這一點：
   • 識別質量貢獻者。創建個人的質量測量(例如每名開發的缺陷、也許根據項目的復雜度會變大)，提供可見性，并在團隊中贊譽那些獲得優秀結果的人。創建一個儀表板，清晰地顯示每個人與同事的對比。并且將這個結果用到會議中。
   • 創造競賽意識。對于大的項目，可以考慮給那些編寫出最高質量的代碼，表現出眾的員工頒獎。確保在開始的時候就宣布這個競賽，并且說明衡量標準。你會從中獲得很大樂趣。
   • 創造學習機會。邀請那些交付最好記錄的團隊成員參加午飯演講活動，讓他們分享創建高質量的方法、他們所做的設計決定和最近項目的一些產出。在準備這個演講時，鼓勵團隊成員展示在他們在某一個功能實施時如何與質量方法的連接，客戶、銷售代表或者高層領導如何體驗。

團隊

任何時候都需要團隊，需要這樣的團隊成員:

1.具有創新精神的測試人員
這類測試人員往往會較快的接受新生事物，他們喜歡探求從未使用過新奇工具、技術等。這些新的測試工具或新技術的發現，會帶動整個測試團隊技術上的推陳出新，讓本來墨守成規的測試工作充滿了新鮮的體驗。大家在交流新技能的同時也會帶動起較高的學習熱情。

2.有測試欲望并能夠持之以恒的測試人員
充滿測試熱情、善于發現隱藏的軟件缺陷、較真是這類軟件測試人員的共性。
往往枯燥的工作會讓人失去耐心，但這類測試人員會始終抱著最大的熱情投入到測試工作中。對于這樣的成員來說，發現軟件缺陷是他們最大的樂趣，工作上的每一個發現都會帶給他們源源不斷的自信。團隊中也正是有這樣的成員存在，正是有他們在關鍵時刻發現軟件產品的隱患才能避免事后補救的不必要的人力、物力資源的浪費。

3.富有經驗的軟件測試人員
不管情況如何，他們都可以找到正確的位置來運行程序以發現關鍵的缺陷。這正是富有經驗的軟件測試人員的寶貴之處。在很多情況下，根據對相似類型的項目的經驗，一個軟件測試工程師可能會準確知道在哪里找“致命缺陷”。

4.具有遠見性的測試人員
與具有創新精神的測試人員不同的是，具有遠見的軟件測試工程師往往會發現更高級的，策略性問題的解決方案。團隊需要一個能看清團隊發展方向的人——對如何進行軟件測試有廣泛認識，而且對團隊成員的具體程序有深入認識的人。這類測試人員會推動整個團動的不斷進步。