軟件質(zhì)量保證實(shí)踐綜述

軟件質(zhì)量保證的實(shí)踐

常見(jiàn)的SQA的架構

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

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

有幾種實(shí)踐方法，包括需求審核、代碼審核和演練、基于會(huì )議的測試、基于風(fēng)險的測試等.

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

而“代碼審核和演練”聽(tīng)起來(lái)像很簡(jiǎn)單，但代碼審核是軟件開(kāi)發(fā)中最有效的實(shí)踐之一。它對減少缺陷數量以及增強代碼和軟件設計的質(zhì)量具有直接影響。這消除了在未來(lái)的版本中執行重大的代碼重構和清理的需求。

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

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

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

這就像將測試人員放在一個(gè)測試房間一段時(shí)間，讓測試人員專(zhuān)注于查找特定軟件特性或功能的缺陷。在會(huì )議期間，測試由一組測試案例引導執行，測試人員也可以執行探索性測試。因此，基于會(huì )議的測試是正式測試方法與測試創(chuàng )新的一種組合，因為它提供了測試人員房間來(lái)進(jìn)行探索和獲得直覺(jué)思維，留出了時(shí)間和自由空間來(lái)發(fā)現不常見(jiàn)的缺陷，或者通過(guò)折騰軟件來(lái)進(jìn)一步了解它。

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

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

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

我們期望是

測試和開(kāi)發(fā)同時(shí)進(jìn)行。編寫(xiě)一些代碼，馬上進(jìn)行測試和構建。接著(zhù)，編寫(xiě)更多的代碼，繼續測試。更好的是，在你編碼的時(shí)候或者編碼之前，就計劃好你的測試。測試不是一個(gè)獨立分開(kāi)的過(guò)程，它是開(kāi)發(fā)的一部分。質(zhì)量不等同于測試；要想有高質(zhì)量的產(chǎn)品，就要把開(kāi)發(fā)和測試緊密捆綁在一起，直到不分彼此。

保證質(zhì)量，預防勝于檢查：

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

衡量軟件質(zhì)量的常用指標

軟件開(kāi)發(fā)實(shí)踐過(guò)程中常用的幾個(gè)衡量軟件質(zhì)量的指標，包括源代碼行數、代碼段/模塊/時(shí)間段內的平均Bug數、代碼覆蓋率、設計/開(kāi)發(fā)約束等

源代碼行數（SLOC）

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

代碼段/模塊/時(shí)間段內的Bug數

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

代碼覆蓋率

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

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

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

設計/開(kāi)發(fā)約束

在軟件開(kāi)發(fā)過(guò)程中，存在許多設計約束和準則，其中包括：

• 類(lèi)和方法的長(cháng)度
• 單個(gè)類(lèi)里方法和屬性的個(gè)數
• 方法或者構造函數的參數個(gè)數
• 代碼中的魔數、字符串用法等等
• 注釋行比例等

 

研發(fā)流程

整個(gè)研發(fā)做到了類(lèi)似于火車(chē)發(fā)車(chē)的發(fā)布過(guò)程：

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

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

質(zhì)量保證手段

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

1. 流程方面

1）創(chuàng )建了提測單、集成單、發(fā)布單等流程。建立了標準，并依托平臺自動(dòng)檢查，提高了交付的質(zhì)量。

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

3）建立線(xiàn)上線(xiàn)下監控分析體系。

2. 包穩定性方面：

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

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

3. 自動(dòng)化測試與測試工具方面

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

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

3）自動(dòng)化平臺方面也在根據測試經(jīng)驗不斷的進(jìn)化，在整個(gè)研發(fā)過(guò)程中自動(dòng)化測試一直在執行，不僅可以提高產(chǎn)品穩定性，也可以發(fā)現性能、電量等非功能問(wèn)題。

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

4. 線(xiàn)上線(xiàn)下監控分析

1）線(xiàn)下質(zhì)量數據、線(xiàn)上業(yè)務(wù)問(wèn)題、輿情反饋等信息統一匯集到平臺上進(jìn)行統一的分析告警，不僅能快速的發(fā)現問(wèn)題，而且能通過(guò)數據分析能夠幫助快速定位和解決問(wèn)題。

2）根據平臺中的數據，可以用經(jīng)驗推動(dòng)流程的優(yōu)化、補充測試用例、添加掃描規則、增加自動(dòng)化場(chǎng)景、催生新的測試工具等，這樣可以使經(jīng)驗形成閉環(huán)，使質(zhì)量保障工作更加高效。

在敏捷開(kāi)發(fā)過(guò)程下質(zhì)量保證

對于目前的開(kāi)發(fā)架構來(lái)說(shuō)，一個(gè)用戶(hù)故事，涉及這四個(gè)點(diǎn)，可以從這四個(gè)點(diǎn)入手來(lái)進(jìn)行質(zhì)量保證。如何做呢？單元測試就開(kāi)發(fā)人員處理了；代碼審查，測試人員可以參與和監督，其實(shí)就是要保證：將開(kāi)發(fā)任務(wù)與提交到Git的代碼進(jìn)行關(guān)聯(lián)。這樣一來(lái)，當測試人員檢查開(kāi)發(fā)任務(wù)的時(shí)候，就可以找到改變過(guò)的代碼。我曾經(jīng)試過(guò)從這些代碼里面查看邏輯，找到分支場(chǎng)景，補充到測試用例里面。

Scrum中測試人員價(jià)值應當體現在：

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

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

3. 隨著(zhù)版本任務(wù)的增加，每個(gè)版本回歸測試的成本增加，可以適當考慮部分穩定功能進(jìn)行自動(dòng)化測試。當然，這是遠景。

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

敏捷中的QA日?；顒?dòng)

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

QA通常不是僅僅工作在某個(gè)迭代，而是并行的同時(shí)工作在多個(gè)迭代：要對當前迭代的故事進(jìn)行驗收測試、探索性測試，和開(kāi)發(fā)人員結對實(shí)現測試自動(dòng)化；還要和業(yè)務(wù)人員結對分析下一個(gè)迭代的故事，編寫(xiě)驗收標準和測試用例。

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

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

正如前面提到的，在每個(gè)階段，QA除了要獨立進(jìn)行測試，通常還需要跟不同的角色結對，包括業(yè)務(wù)分析人員、開(kāi)發(fā)人員、以及客戶(hù)。

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

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

敏捷QA與傳統測試人員有何不同。我們分別從團隊構成、測試階段、工作方式、關(guān)注點(diǎn)、業(yè)務(wù)知識來(lái)源以及發(fā)布計劃制定幾個(gè)方面，來(lái)看看敏捷QA與傳統測試人員有哪些不同：

傳統測試人員	敏捷QA
單獨的測試團隊	多角色開(kāi)發(fā)團隊的一員
在開(kāi)發(fā)流程后期才開(kāi)始測試	測試貫穿于整個(gè)開(kāi)發(fā)流中
通常是獨立工作	QA和不同角色進(jìn)行結對
被當作最后也是唯一的質(zhì)量保證	關(guān)注并強調風(fēng)險
缺乏與業(yè)務(wù)人員的直接溝通	和業(yè)務(wù)人員直接溝通
沒(méi)有機會(huì )參與發(fā)布計劃制定	參與發(fā)布計劃的制定

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

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

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

• 具有豐富的產(chǎn)品知識和對用戶(hù)業(yè)務(wù)目標的準確了解
• 對不同系統和數據庫所用到的技術(shù)知識的了解
• 和不同角色以及客戶(hù)進(jìn)行有效溝通
• 主動(dòng)驗證質(zhì)量目標并及時(shí)說(shuō)出自己的想法
• 編寫(xiě)測試計劃，列出需要執行的活動(dòng)并進(jìn)行估算
• 自動(dòng)化測試的能力和對測試工具的基本了解
• 在團隊內部進(jìn)行知識分享，協(xié)助整個(gè)團隊參與到測試活動(dòng)中來(lái)
• 持續提供并獲取反饋

敏捷軟件測試的七個(gè)關(guān)鍵成功要素

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

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

當整個(gè)開(kāi)發(fā)團隊負責測試和質(zhì)量問(wèn)題，你會(huì )擁有很多不同的技能集合和經(jīng)驗等級來(lái)處理測試可能發(fā)生的問(wèn)題。測試自動(dòng)化對于技能高超的開(kāi)發(fā)人員來(lái)說(shuō)不是大問(wèn)題。當測試置于團隊的優(yōu)先權，任何人都參與測試任務(wù)，團隊才會(huì )設計可測試的代碼。使測試人員真正成為開(kāi)發(fā)團隊的一部分意味著(zhù)向他們提供支持和訓練他們適應敏捷開(kāi)發(fā)的快節奏。他們需要時(shí)間掌握新技能以便與開(kāi)發(fā)和客戶(hù)團隊緊密協(xié)作。

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

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

2. 采用敏捷測試思維

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

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

3.自動(dòng)化回歸測試

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

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

4.提供并獲取反饋

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

5.構建核心實(shí)踐的基礎

• 持續集成

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

• 測試環(huán)境

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

• 管理技術(shù)債務(wù)

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

• 增量工作

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

• 編碼和測試是同一個(gè)過(guò)程的組成部分

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

• 實(shí)踐之間的協(xié)作

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

6.與客戶(hù)合作

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

7.保持大局觀(guān)

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

互聯(lián)網(wǎng)產(chǎn)品下質(zhì)量保障

質(zhì)量保障的核心目標是質(zhì)量 & 效率并重，對于互聯(lián)網(wǎng)產(chǎn)品來(lái)說(shuō)詮釋如下：

質(zhì)量

i.不僅僅是功能可用性層面，需要關(guān)注用戶(hù)體驗。

ii.不僅僅是上線(xiàn)前的質(zhì)量保證，需要延伸至把關(guān)上線(xiàn)中、線(xiàn)上的質(zhì)量。

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

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

v.不僅僅只局限自身產(chǎn)品的質(zhì)量，也需要關(guān)心競品。

效率

i.加快產(chǎn)品迭代，唯快不破。

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

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

“以質(zhì)量為中心，以數據為驅動(dòng)”為宗旨貫穿整個(gè)流程，將各種測試工具和方法融入進(jìn)來(lái)，構筑一套全流程質(zhì)量保障體系，如下圖所示:

 

二、測試技術(shù)

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

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

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

三、專(zhuān)項質(zhì)量保障

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

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

（2）多機房 & P2P 流量架構：流量 diff 系統 & 實(shí)網(wǎng)系統 & 眾測測速，傳輸速度體驗

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

三、最終

從質(zhì)量標準、質(zhì)量防線(xiàn)和質(zhì)量閉環(huán)三個(gè)維度進(jìn)行質(zhì)量建設。首先對產(chǎn)品建立一套完善的產(chǎn)品質(zhì)量標準體系，并將其度量化，固定成 benchmark。緊緊圍繞質(zhì)量數據，組建從用戶(hù)（輿情熱點(diǎn)）、端（產(chǎn)品體驗）、服務(wù)器（穩定性）到基礎網(wǎng)絡(luò )（SLA）的實(shí)時(shí)防線(xiàn)，最后通過(guò)“上線(xiàn)管理—報警中心—智能定位—故障通報”的質(zhì)量閉環(huán)環(huán)節落地，不斷迭代優(yōu)化。

文化價(jià)值驅動(dòng)質(zhì)量

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

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

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

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

團隊

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

1.具有創(chuàng )新精神的測試人員
這類(lèi)測試人員往往會(huì )較快的接受新生事物，他們喜歡探求從未使用過(guò)新奇工具、技術(shù)等。這些新的測試工具或新技術(shù)的發(fā)現，會(huì )帶動(dòng)整個(gè)測試團隊技術(shù)上的推陳出新，讓本來(lái)墨守成規的測試工作充滿(mǎn)了新鮮的體驗。大家在交流新技能的同時(shí)也會(huì )帶動(dòng)起較高的學(xué)習熱情。

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

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

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

原文轉自：https://www.cnblogs.com/wintersun/p/5297352.html