軟體質量保證的實踐

常見的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日常活動

從迭代到釋出，敏捷測試的生命週期各個階段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也提出了更高的要求，需要做到：

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

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

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

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

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

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

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

2. 採用敏捷測試思維

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

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

3.自動化迴歸測試

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

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

4.提供並獲取反饋

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

5.構建核心實踐的基礎

• 持續整合

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

• 測試環境

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

• 管理技術債務

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

• 增量工作

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

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

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

• 實踐之間的協作

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

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

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望對您公司IT軟體研發與質量管理有幫助。 其它您可能感興趣的文章：

如有想了解更多軟體研發 , 系統 IT整合 , 企業資訊化，專案管理，企業管理 等資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。