構(gòu)建測試的體系化思維（進(jìn)階篇）
讀完需要
速讀僅需 8 分鐘
? ?
00 引言
1. 三個(gè)層次聊測試體系
測試人員缺乏體系化思維？新建產(chǎn)品團(tuán)隊(duì)或者新啟項(xiàng)目，如何搭建質(zhì)量保障體系？
大家都接觸過不計(jì)其數(shù)的測試、質(zhì)量方面的文章或者培訓(xùn)課程，內(nèi)容不乏測試實(shí)踐、技術(shù)相關(guān)，但是卻很難構(gòu)建自己的測試體系?；诤芏嗯笥杨愃频睦Щ螅Y(jié)合本人多年的團(tuán)隊(duì)實(shí)踐和咨詢經(jīng)驗(yàn)，從基礎(chǔ)、進(jìn)階和高級三個(gè)不同的層次來跟大家探討測試體系化思維的構(gòu)建。
《構(gòu)建測試的體系化思維（進(jìn)階篇）》（本文）
《構(gòu)建測試的體系化思維（高級篇）》（待發(fā)布）
2. 基礎(chǔ)篇內(nèi)容回顧
2022 年 1 月份發(fā)布了《構(gòu)建測試的體系化思維（基礎(chǔ)篇）》（后文簡稱《基礎(chǔ)篇》），從測試的五個(gè)基本職責(zé)出發(fā)，圍繞這五個(gè)基本職責(zé)介紹了相應(yīng)的實(shí)踐活動和方法集。
理解和澄清業(yè)務(wù)需求
制定策略并設(shè)計(jì)測試
實(shí)現(xiàn)和執(zhí)行測試
缺陷管理與分析
質(zhì)量反饋與風(fēng)險(xiǎn)識別
3. 進(jìn)階篇內(nèi)容概要
本文為進(jìn)階篇，將跳出測試，從軟件質(zhì)量的角度來看體系化思維的構(gòu)建。
1）從測試到質(zhì)量：跳出測試，從質(zhì)量維度來看測試的體系化建設(shè)。
2）質(zhì)量保障與質(zhì)量內(nèi)建：質(zhì)量是產(chǎn)品與生俱來的，質(zhì)量內(nèi)建才是保障質(zhì)量的根本。
3）質(zhì)量內(nèi)建深入實(shí)踐：質(zhì)量內(nèi)建如何落地是大家最為關(guān)注的問題，深入質(zhì)量內(nèi)建實(shí)踐介紹，供大家落地實(shí)踐參考。
? ?
01 從測試到質(zhì)量
1. 為什么要從測試轉(zhuǎn)變到質(zhì)量
在《基礎(chǔ)篇》中提到的五個(gè)測試基本職責(zé)，那是測試人員開展測試工作務(wù)必了解的方方面面，是做好測試工作的基礎(chǔ)。
但是，要做好軟件產(chǎn)品的質(zhì)量保障工作，光從做好測試的角度考慮是遠(yuǎn)遠(yuǎn)不夠的，原因主要有兩個(gè)方面：
軟件質(zhì)量不能通過測試來提高。著名質(zhì)量管理專家戴明提到：“質(zhì)量沒法檢測出來，軟件產(chǎn)品開發(fā)出來后質(zhì)量就已經(jīng)在那了。”
軟件測試可以驗(yàn)證軟件質(zhì)量是否滿足需求，但是隨著軟件生態(tài)的復(fù)雜性和不確定性增加，沒有辦法預(yù)知軟件行為，也就沒法通過測試來驗(yàn)證軟件質(zhì)量的方方面面。
因此，測試是基本功，但只關(guān)注測試是不夠的。需要跳出測試，將視野調(diào)整到軟件開發(fā)全生命周期質(zhì)量的角度，關(guān)注質(zhì)量的各個(gè)維度，才能更好地建立體系化思維，才能更好地做好軟件產(chǎn)品的質(zhì)量保障工作。
在閱讀后面內(nèi)容之前，我希望讀者朋友們先花 10 秒鐘思考以下問題：
問題：跳出測試，從軟件質(zhì)量的角度思考，我們需要關(guān)注哪些方面？
這是一個(gè)老生常談的問題，答案似乎大家也都很清楚，但現(xiàn)實(shí)中又是很容易被忽視、被誤解的問題。
2. 軟件質(zhì)量的定義
在回答上面問題之前，我們先來看看維基百科對軟件質(zhì)量的定義 ( https://en.wikipedia.org/wiki/Software_quality )。如下圖所示：
維基百科對軟件質(zhì)量的定義包括兩個(gè)方面：
軟件功能質(zhì)量：基于功能需求規(guī)范看軟件是否提供了相應(yīng)的功能，這是用戶使用軟件的角度，是軟件外部的質(zhì)量。
軟件結(jié)構(gòu)質(zhì)量：對支持功能需求交付的非功能需求的滿足情況，比如健壯性、可維護(hù)性等，這是從軟件內(nèi)部結(jié)構(gòu)來看，是軟件內(nèi)部的質(zhì)量。
維基百科的這個(gè)定義跟咱平常提到的軟件質(zhì)量包含外部質(zhì)量和內(nèi)部質(zhì)量是一致的。外部質(zhì)量是從軟件外部可感知的，是從用戶角度對軟件感知到的使用質(zhì)量；內(nèi)部質(zhì)量則涉及到軟件的內(nèi)部形態(tài)，包括技術(shù)架構(gòu)和代碼質(zhì)量等，是從團(tuán)隊(duì)開發(fā)人員的角度感知到的。
相信大家對于外部質(zhì)量好理解，是用戶角度能夠感知到的質(zhì)量。而內(nèi)部質(zhì)量往往很容易被忽視，其實(shí)這也是因?yàn)槿藗兤毡槿菀鬃非蠖唐诶妫床坏絻?nèi)部質(zhì)量給軟件產(chǎn)品帶來的長遠(yuǎn)影響，這里想給大家看個(gè)非常熟悉的圖，以增強(qiáng)對內(nèi)部質(zhì)量的重視。
不加整理的富含技術(shù)債的代碼，就如同圖中雜亂無章纏繞在一起的電線，嚴(yán)重影響著產(chǎn)品缺陷定位修復(fù)、后期功能擴(kuò)展等。
3. 容易忽視的質(zhì)量影響因素
理解了質(zhì)量的定義，在日常軟件開發(fā)工作中有哪些因素是會影響到軟件質(zhì)量的呢？其實(shí)，影響的因素特別的多，可能包括但不限于以下這些：
1）需求分析過程倉促，或者參與人員角色比較單一，導(dǎo)致業(yè)務(wù)上下文了解不夠，關(guān)鍵場景缺乏考慮等；
2）忙于交付更多的特性，忽略了對代碼質(zhì)量的關(guān)注，該重構(gòu)的沒有重構(gòu)，在原本不太健康的代碼基礎(chǔ)上繼續(xù)增加更多的代碼，導(dǎo)致混亂，筑起高高的技術(shù)債；
3）沒有足夠的測試覆蓋，導(dǎo)致新增代碼容易破壞已有功能；
4）開發(fā)人員提交代碼后，就投入新代碼的開發(fā)，對所提交代碼缺乏關(guān)注，持續(xù)集成流水線上測試掛了不能及時(shí)修復(fù)，可能影響后面的測試進(jìn)度；
5）大面積的重構(gòu)發(fā)生在發(fā)布前夕，無法全面回歸，帶來很大的風(fēng)險(xiǎn)；
6）項(xiàng)目初期只考慮少量用戶的場景，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)功能難以擴(kuò)展，導(dǎo)致嚴(yán)重性能瓶頸；
7）技術(shù)選型失誤，開發(fā)困難，沒有及時(shí)改進(jìn)，一錯再錯，最后問題嚴(yán)重到無法彌補(bǔ)；
8）第三方組件評估不夠充分，導(dǎo)致線上環(huán)境無法承載等；
9）開發(fā)缺少對異常情況的處理，測試過程缺乏探索，只覆蓋到主干路徑，邊角用例可能引發(fā)問題；
10）開發(fā)或者測試都只考慮當(dāng)前功能模塊，缺乏更廣范圍的考慮；
11）缺乏跨功能需求的關(guān)注，導(dǎo)致嚴(yán)重的安全或者性能問題；
12）對線上環(huán)境了解不夠，而且沒有足夠日志信息記錄，線上問題難以定位，導(dǎo)致宕機(jī)時(shí)間過長；
13）等更多……
? ?
02 質(zhì)量保障與質(zhì)量內(nèi)建
1. 質(zhì)量如何保障
從質(zhì)量維度來看體系化思維的構(gòu)建，而質(zhì)量是產(chǎn)品與生俱來的，做好軟件產(chǎn)品的質(zhì)量保障工作更為有效的方式就是要將質(zhì)量構(gòu)建到軟件產(chǎn)品本身，提高軟件產(chǎn)品與生俱來的質(zhì)量。這也就是質(zhì)量內(nèi)建（Build Quality In）的概念。
這個(gè)還是太抽象，為了更清楚的解釋質(zhì)量內(nèi)建，先來看兩個(gè)概念：暴露缺陷與預(yù)防缺陷。
2. 暴露缺陷與預(yù)防缺陷
“暴露缺陷”的概念眾所周知，就是軟件所暴露出來的缺陷，通常在測試或使用過程中被發(fā)現(xiàn)。
如果能夠全面統(tǒng)計(jì)一個(gè)軟件產(chǎn)品的所有可能引起缺陷的地方，我們可以說該軟件存在缺陷的總量是一定的。當(dāng)然，現(xiàn)實(shí)情況是我們不可能全面考慮到所有的因素，缺陷是很難窮盡的。
如果這一定數(shù)量的缺陷中有一部分可以通過某些措施來預(yù)防，那么軟件在測試或最終用戶使用過程中所暴露出來的缺陷數(shù)量就會減少，這就是缺陷預(yù)防——減少暴露給用戶的缺陷。
軟件開發(fā)過程是個(gè)持續(xù)遞增的過程，預(yù)防缺陷也不是一蹴而就的事情，需要在整個(gè)軟件開發(fā)過程持續(xù)的進(jìn)行。當(dāng)然，盡早預(yù)防缺陷會更好，這樣可以顯著減少缺陷修復(fù)的成本，提高投入產(chǎn)出比。下圖曲線非常清晰地展示了修復(fù)不同階段暴露出來的缺陷所需成本的差異，修復(fù)成本是隨著軟件開發(fā)周期顯著增加的。
3. 質(zhì)量內(nèi)建如何做
將缺陷概念擴(kuò)展為軟件產(chǎn)品質(zhì)量相關(guān)的所有問題，那么做好了缺陷預(yù)防也就是做到了質(zhì)量內(nèi)建。
前文提到過容易被忽視的質(zhì)量影響因素，要做好質(zhì)量內(nèi)建這些因素都是需要重點(diǎn)關(guān)注的。
但是，由于軟件開發(fā)過程的復(fù)雜性，要一次性做對所有事情、預(yù)防所有的缺陷是不可能的。因此，質(zhì)量內(nèi)建并不是嚴(yán)格意義上的不能有任何缺陷暴露，而是需要在軟件開發(fā)生命周期中盡早地把事情做對，并且通過持續(xù)的獲取快速的反饋來糾偏。
我們都知道那個(gè)有名的 PDCA 環(huán)（也稱“戴明環(huán)”）：
將質(zhì)量管理分為四個(gè)階段，即 Plan(計(jì)劃)、Do(執(zhí)行)、Check(檢查) 和 Act(處理)。在質(zhì)量管理活動中，要求把各項(xiàng)工作按照作出計(jì)劃、計(jì)劃實(shí)施、檢查實(shí)施效果，然后將成功的納入標(biāo)準(zhǔn)，不成功的留待下一循環(huán)去解決。
質(zhì)量內(nèi)建可以理解為在軟件開發(fā)全生命周期中，從需求到線上頻繁地執(zhí)行 PDCA 環(huán)，小步前進(jìn)，持續(xù)反饋驗(yàn)證，及時(shí)調(diào)整改進(jìn)。如下圖所示：
? ?
03 質(zhì)量內(nèi)建深入實(shí)踐
前面主要從概念和理念層面介紹了質(zhì)量和質(zhì)量內(nèi)建，這些內(nèi)容對構(gòu)建體系化思維是至關(guān)重要的，有助于拓寬視野，形成全局觀。但光有這些內(nèi)容不夠，還得了解具體的落地實(shí)施方法。接下來就從質(zhì)量內(nèi)建相關(guān)實(shí)踐來探討質(zhì)量內(nèi)建在軟件開發(fā)生命周期的落地實(shí)施方案。
1. 質(zhì)量內(nèi)建的核心
在介紹具體的質(zhì)量內(nèi)建實(shí)踐之前，還是需要從抽象層面來理解質(zhì)量內(nèi)建的核心，其內(nèi)容可以分為四個(gè)方面：
測試左移
快速反饋
測試右移
全員參與
1.1 測試左移
傳統(tǒng)軟件開發(fā)會分成分析、設(shè)計(jì)、開發(fā)、測試、發(fā)布等幾個(gè)相對獨(dú)立的階段，而測試是其中發(fā)生在開發(fā)完成之后的一個(gè)階段。
測試左移是針對傳統(tǒng)這種獨(dú)立測試階段來說的，不再強(qiáng)調(diào)獨(dú)立的測試階段，而是要將測試活動左移到軟件開發(fā)生命周期的最早階段（最左邊）——需求階段，從需求階段開始做好缺陷預(yù)防的工作。
要特別提醒注意的是，測試左移不是測試人員左移，而是強(qiáng)調(diào)的測試活動左移：
左移到傳統(tǒng)獨(dú)立測試階段左側(cè)就叫左移，不一定是左移到需求階段。當(dāng)然，根據(jù)前面對質(zhì)量內(nèi)建的闡述，理想情況下肯定是越左邊越好。如果做不到徹底左移，能移一步也是進(jìn)步。
測試人員的確需要左移參與相應(yīng)的活動。但是，如果測試人員參與需求階段，卻沒有起到澄清需求、驗(yàn)證需求有效性的作用，那就不是有效的測試左移，關(guān)鍵要看成效。
不僅測試人員要左移，開發(fā)等其他角色也需要左移。因?yàn)樾枨笥行缘尿?yàn)證，需要不同角色的經(jīng)驗(yàn)，需要來自不同視角的輸入；不同角色都有責(zé)任參與到每個(gè)環(huán)節(jié)的測試活動中來。
只要能做到從需求階段開始就有相應(yīng)的測試活動，不一定都是測試人員參與。這里強(qiáng)調(diào)的是測試活動要有，哪個(gè)角色來做不是最關(guān)鍵的，角色其實(shí)就是戴了一定帽子而已。我們知道，有的團(tuán)隊(duì)是沒有測試人員的，但不代表這些團(tuán)隊(duì)沒有測試活動。
1.2 快速反饋
快速反饋，也就是頻繁持續(xù)地反饋，可以理解為一個(gè)持續(xù)測試的過程。
通?？焖俜答佇枰凶詣踊闹危热缱詣踊瘻y試、流水線上自動代碼掃描等；也可以是一些人工參與的實(shí)踐環(huán)節(jié)，比如手動測試、各類評審和驗(yàn)收等。通過這樣的一些實(shí)踐活動盡快地獲取相應(yīng)工作（可能是需求分析、開發(fā)等）的反饋，根據(jù)反饋結(jié)果進(jìn)行及時(shí)的修復(fù)、調(diào)整、或者優(yōu)化。
為了保障快速反饋/持續(xù)測試實(shí)踐活動的有效開展，通常需要增加質(zhì)量門禁，并確保質(zhì)量門禁的嚴(yán)格執(zhí)行。
1.3 測試右移
測試右移是跟測試左移對應(yīng)的，就是將測試活動從獨(dú)立測試階段右移到生產(chǎn)環(huán)境。
但因?yàn)樯a(chǎn)環(huán)境的特殊性，測試右移又不是測試活動的簡單右移，而是通過一些實(shí)踐活動獲取生產(chǎn)環(huán)境下用戶行為、日志等質(zhì)量相關(guān)信息，利用這些信息來給前期的需求、開發(fā)和測試工作提供反饋，促進(jìn)相應(yīng)工作的優(yōu)化改進(jìn)，以更好的做好質(zhì)量內(nèi)建。
測試右移本身不能直接內(nèi)建質(zhì)量，但是可以幫助更好地質(zhì)量內(nèi)建，所以我認(rèn)為測試右移也是質(zhì)量內(nèi)建不可或缺的核心內(nèi)容之一。
這部分的內(nèi)容比較多，之前有過詳細(xì)的介紹，此處不再贅述。歡迎參考文章《測試右移——生產(chǎn)環(huán)境下的 QA》閱讀更為詳細(xì)的內(nèi)容。
1.4 全員參與
測試左移、快速反饋和測試右移都不是某個(gè)單一角色/人員可以做到的，需要不同角色的不同技能和不同視角的輸入，質(zhì)量人人有責(zé)，需要全員參與并且能承擔(dān)起質(zhì)量職責(zé)才行。
全員參與不僅是很多實(shí)踐活動需要大家一起參與，還有很重要的一點(diǎn)是團(tuán)隊(duì)內(nèi)部需要有足夠的溝通和信息共享。只有信息足夠透明，每個(gè)人都清楚質(zhì)量目標(biāo)、質(zhì)量狀態(tài)和風(fēng)險(xiǎn)，才能真正發(fā)揮主人翁精神積極地參與，才能發(fā)揮團(tuán)隊(duì)每個(gè)人最大的價(jià)值。一定要警惕團(tuán)隊(duì)“蘑菇種植”。
這部分內(nèi)容之前也有過非常多的分享，歡迎參考：《團(tuán)隊(duì)對質(zhì)量負(fù)責(zé)，“我”可以不負(fù)責(zé)？》、《敏捷測試的指導(dǎo)性原則》、《說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢？》等文章。
2. 質(zhì)量內(nèi)建典型實(shí)踐
綜合來看，質(zhì)量內(nèi)建的典型實(shí)踐通常有（但不限于）下圖這些：
不管是傳統(tǒng)開發(fā)模式還是敏捷迭代式開發(fā)模式，軟件開發(fā)生命周期都會有需求分析、開發(fā)實(shí)現(xiàn)和線上使用三個(gè)階段，只是敏捷模式下需求和開發(fā)是迭代式進(jìn)行，在時(shí)間上不是界限清晰的階段。
這里為了描述方便，暫且將這些實(shí)踐分成三個(gè)階段來描述，事實(shí)上實(shí)踐活動跟階段也不是關(guān)聯(lián)非常緊密的，遵循測試左移、快速反饋、測試右移和全員參與這幾個(gè)核心思想才是關(guān)鍵所在。
2.1 需求分析
這里強(qiáng)調(diào)四個(gè)我認(rèn)為跟需求分析密切相關(guān)的典型質(zhì)量內(nèi)建實(shí)踐，分別是需求澄清、行為驅(qū)動開發(fā)（BDD）、實(shí)例化需求（SbE）和需求評審。
需求澄清：需求的理解和澄清作為測試基本職責(zé)之一，在《基礎(chǔ)篇》中有較為詳細(xì)的介紹，請移步參考。不過，在這里需要補(bǔ)充的是不僅測試要參與需求澄清，還需要其他相應(yīng)的角色協(xié)同參與，比如開發(fā)人員、技術(shù)負(fù)責(zé)人、技術(shù)架構(gòu)師等。
行為驅(qū)動開發(fā)（BDD）：關(guān)于 BDD，很多人誤認(rèn)為是一種測試方法，但其實(shí) BDD 主要是為了三方更好地對需求達(dá)成一致認(rèn)識，只不過通過 BDD 方式產(chǎn)生的需求能夠很好地指導(dǎo)自動化測試的開展。更多詳情，請參考我之前的文章《說起 BDD，你會想到什么？》。
實(shí)例化需求（SbE）：SbE 的核心思想跟 BDD 類似，但強(qiáng)調(diào)了一點(diǎn)要將需求描述通過實(shí)例來說明，以更好地發(fā)現(xiàn)漏掉的需求，讓需求更完整、更容易被多方理解和澄清。
需求評審：需要開發(fā)和測試跟業(yè)務(wù)分析人員一起討論確認(rèn)需求，可能是正式的會議針對某個(gè)特性（大塊需求）的評審，也可以是針對單個(gè)需求條目或敏捷用戶故事進(jìn)行線下評審。如果前期需求澄清過程中對需求的討論已經(jīng)比較透徹，這里的評審就會比較輕量級，由測試人員（開發(fā)按需參與）自行安排時(shí)間評審即可。
這些實(shí)踐都是為了更好地在需求分析階段讓團(tuán)隊(duì)對需求達(dá)成一致的理解，確保需求的質(zhì)量，減少后期因需求問題帶來的返工和浪費(fèi)。
2.2 開發(fā)實(shí)現(xiàn)
需求源頭的質(zhì)量控制好了，接下來就是在開發(fā)實(shí)現(xiàn)階段持續(xù)地通過快速反饋的方式確保每一步工作的質(zhì)量，下面的實(shí)踐都是為此服務(wù)的：
技術(shù)方案討論：不是要介紹這個(gè)實(shí)踐怎么做，而是要提醒在做技術(shù)方案討論的時(shí)候測試要盡量參與。一方面，測試清楚了解技術(shù)方案，才能更好地設(shè)計(jì)相應(yīng)的測試策略，更完備的進(jìn)行測試；另一方面，測試基于自己對系統(tǒng)的了解，可以給技術(shù)方案的討論提供輸入，比如系統(tǒng)重點(diǎn)需要考慮和關(guān)注的問題等?？赡苡腥藭X得測試技術(shù)水平跟不上，參與價(jià)值不大，但我想說的是不參與就不會有進(jìn)步，只要參與了就一定會有收獲，從長期來看，不管是對個(gè)人還是對團(tuán)隊(duì)整體都是非常有價(jià)值的。
需求條目啟動：也叫用戶故事啟動（Story kickoff）、開卡等。對于單個(gè)可開發(fā)需求，在開發(fā)人員要開始編碼前進(jìn)行的再次澄清和確認(rèn)，主要是確認(rèn)其中的驗(yàn)收標(biāo)準(zhǔn)是否不夠完備、是否大家都理解一致了。形式要求盡量輕量級，在開發(fā)人員電腦前完成即可，需要業(yè)務(wù)分析、開發(fā)和測試共同參與，時(shí)間一般不要超過 15 分鐘。
需求條目驗(yàn)收：跟啟動是配對的，也叫用戶故事驗(yàn)收（Desk check/Shoulder check/Story signoff）、結(jié)卡/驗(yàn)卡等。同樣在開發(fā)機(jī)器前面完成，一般由開發(fā)將功能演示給業(yè)務(wù)分析和測試人員，大家確認(rèn)需求中的正向路徑是否都已經(jīng)開發(fā)實(shí)現(xiàn)了。更多詳情可參考文章《高效用戶故事驗(yàn)收》。
測試用例設(shè)計(jì)：在《基礎(chǔ)篇》有對測試用例設(shè)計(jì)作詳細(xì)的介紹，從質(zhì)量內(nèi)建的角度來看主要是想說測試用例設(shè)計(jì)盡量早點(diǎn)做，而且對于用例設(shè)計(jì)的形式可以相對靈活些，列舉需要關(guān)注的測試點(diǎn)才是關(guān)鍵，從快速反饋的角度，不建議過于注重形式和流程。
測試驅(qū)動開發(fā)：TDD，常見的有單元測試驅(qū)動開發(fā)（UTDD）和驗(yàn)收測試驅(qū)動開發(fā)（ATDD），通過先寫測試的方式驅(qū)動設(shè)計(jì)的完備性。Thoughtworks 同事劉冉老師有多篇關(guān)于 TDD 的文章，請移步他的網(wǎng)站「劉冉的思辨悟 ( http://liuranthinking.com )」查閱參考。
代碼評審：Code review，也叫代碼回顧。有團(tuán)隊(duì)成員聚集在一起做回顧的，也有獨(dú)立線下評審的模式。Thoughtworks 同事伍斌道長的文章《Code Review: 超越“審、查、評”的代碼回顧》有關(guān)于 code review 非常詳細(xì)的講解，請移步參考。
自動化回歸測試：根據(jù)測試分層理論，自動化測試可能包括單元測試、接口集成測試和端到端測試。通常單元測試是開發(fā)人員編寫，而接口集成測試和端到端集成測試可以開發(fā)和測試協(xié)作完成。關(guān)于自動化測試相關(guān)文章比比皆是，這里推薦如下內(nèi)容供參考：
《精益測試》
Thoughtworks 洞見自動化測試文集 ( https://insights.thoughtworks.cn/?s=%25E8%2587%25AA%25E5%258A%25A8%25E5%258C%2596%25E6%25B5%258B%25E8%25AF%2595 )
劉冉老師網(wǎng)站的自動化測試文集 ( http://liuranthinking.com/automatedtesting/ )
單元測試評審：單元測試評審一般發(fā)生在需求條目驗(yàn)收環(huán)節(jié)，詳情參考文章《QA 評審底層測試的價(jià)值》。
持續(xù)集成：持續(xù)集成（CI）概念大家并不陌生，但是有效實(shí)施卻不是那么容易。常見的反例有：
光有持續(xù)集成流水線，但是流水線上啥也沒有，沒有代碼掃描、沒有自動化測試、沒有質(zhì)量門禁；
流水線有接入代碼掃描，但是掃描出問題沒有及時(shí)修復(fù)；
自動化測試沒有在流水線上頻繁執(zhí)行，或者執(zhí)行失敗不能及時(shí)修復(fù)；
代碼沒有頻繁提交；
……
更多內(nèi)容，推薦參考 Thoughtworks 洞見文章《持續(xù)集成理論和實(shí)踐的新進(jìn)展》和《對于持續(xù)集成實(shí)踐的常見問題的解答》。
自動化/持續(xù)部署：自動化部署在提高效率的同時(shí)還可以減少手工部署引入的問題，讓部署能夠更頻繁更持續(xù)地發(fā)生。這部分內(nèi)容可以參考 Thoughtworks 洞見文章《持續(xù)集成和交付流水線的反模式》。
技術(shù)債管理：還記得前面那個(gè)布滿雜亂無章電線的圖嗎？軟件開發(fā)過程中引入的技術(shù)債如果沒有得到有效管理，軟件內(nèi)部也會亂成那個(gè)樣子。關(guān)于技術(shù)債管理，推薦 Thoughtworks 同事麻廣廣的文章《軟件架構(gòu)治理之技術(shù)債的前世今生》。
探索式測試：探索式測試有助于發(fā)現(xiàn)一些潛在的不易察覺的缺陷，是非常推薦的一個(gè)實(shí)踐。具體做法和建議在《基礎(chǔ)篇》中對探索式測試有詳細(xì)介紹。
客戶驗(yàn)收：英文叫 Showcase，就是給客戶、業(yè)務(wù)方演示開發(fā)實(shí)現(xiàn)的特性。Showcase 也有很多常見誤區(qū)，請移步文章《敏捷實(shí)踐 Showcase 的七宗罪》。
缺陷分析：缺陷分析對質(zhì)量內(nèi)建的幫助主要是通過分析找出問題根因，在后續(xù)的開發(fā)工作中提前避免以預(yù)防更多的缺陷暴露。如何做好缺陷管理和分析？請參考下列文章：
質(zhì)量狀態(tài)報(bào)告和質(zhì)量風(fēng)險(xiǎn)分析：請參考《基礎(chǔ)篇》中“測試職責(zé)之五：質(zhì)量反饋與風(fēng)險(xiǎn)識別”部分的介紹。
回顧會議：回顧會議通過總結(jié)和分析過去一段時(shí)間團(tuán)隊(duì)發(fā)生的事情，是關(guān)于團(tuán)隊(duì)整體健康狀態(tài)的。我之所以將回顧會議列為質(zhì)量內(nèi)建的典型實(shí)踐，是因?yàn)樵蹅兦懊嬗懻撨^了影響質(zhì)量的因素涉及到方方面面，自然就跟團(tuán)隊(duì)的健康有著很大的關(guān)系。利用好回顧會議這個(gè)實(shí)踐，及時(shí)發(fā)現(xiàn)問題并采取對應(yīng)的改進(jìn)舉措，將是非常有價(jià)值的。關(guān)于回顧會議的高效開展，可以參考 Thoughtworks 洞見文章《高效回顧會議的七步議程》。
2.3 線上使用
軟件產(chǎn)品發(fā)布到線上，質(zhì)量內(nèi)建相關(guān)實(shí)踐就都是跟測試右移有關(guān)的，這是一個(gè)很大的主題，之前有過系列文章的介紹，相關(guān)實(shí)踐可以參考下列文章：
? ?
04 寫在最后
測試基本職責(zé)是測試人員必備之基礎(chǔ)技能，但測試的體系化思維構(gòu)建不能僅局限于測試工作本身，當(dāng)我們跳出測試，從質(zhì)量的角度來看，又是另一番景象。
希望本《進(jìn)階篇》能夠幫助各位測試同仁從質(zhì)量的角度拓寬視野，增加大局觀，讓質(zhì)量保障工作做得更順暢。