讀完需要

24

分鐘

速讀僅需 8 分鐘

? ?

00 引言

1. 三個(gè)層次聊測(cè)試體系

測(cè)試人員缺乏體系化思維？新建產(chǎn)品團(tuán)隊(duì)或者新啟項(xiàng)目，如何搭建質(zhì)量保障體系？

大家都接觸過不計(jì)其數(shù)的測(cè)試、質(zhì)量方面的文章或者培訓(xùn)課程，內(nèi)容不乏測(cè)試實(shí)踐、技術(shù)相關(guān)，但是卻很難構(gòu)建自己的測(cè)試體系。基于很多朋友類似的困惑，結(jié)合本人多年的團(tuán)隊(duì)實(shí)踐和咨詢經(jīng)驗(yàn)，從基礎(chǔ)、進(jìn)階和高級(jí)三個(gè)不同的層次來(lái)跟大家探討測(cè)試體系化思維的構(gòu)建。

• 《構(gòu)建測(cè)試的體系化思維（基礎(chǔ)篇）》

• 《構(gòu)建測(cè)試的體系化思維（進(jìn)階篇）》（本文）

• 《構(gòu)建測(cè)試的體系化思維（高級(jí)篇）》（待發(fā)布）

2. 基礎(chǔ)篇內(nèi)容回顧

2022 年 1 月份發(fā)布了《構(gòu)建測(cè)試的體系化思維（基礎(chǔ)篇）》（后文簡(jiǎn)稱《基礎(chǔ)篇》），從測(cè)試的五個(gè)基本職責(zé)出發(fā)，圍繞這五個(gè)基本職責(zé)介紹了相應(yīng)的實(shí)踐活動(dòng)和方法集。

• 理解和澄清業(yè)務(wù)需求

• 制定策略并設(shè)計(jì)測(cè)試

• 實(shí)現(xiàn)和執(zhí)行測(cè)試

• 缺陷管理與分析

• 質(zhì)量反饋與風(fēng)險(xiǎn)識(shí)別

3. 進(jìn)階篇內(nèi)容概要

本文為進(jìn)階篇，將跳出測(cè)試，從軟件質(zhì)量的角度來(lái)看體系化思維的構(gòu)建。

1）從測(cè)試到質(zhì)量：跳出測(cè)試，從質(zhì)量維度來(lái)看測(cè)試的體系化建設(shè)。

2）質(zhì)量保障與質(zhì)量?jī)?nèi)建：質(zhì)量是產(chǎn)品與生俱來(lái)的，質(zhì)量?jī)?nèi)建才是保障質(zhì)量的根本。

3）質(zhì)量?jī)?nèi)建深入實(shí)踐：質(zhì)量?jī)?nèi)建如何落地是大家最為關(guān)注的問題，深入質(zhì)量?jī)?nèi)建實(shí)踐介紹，供大家落地實(shí)踐參考。

? ?

01 從測(cè)試到質(zhì)量

1. 為什么要從測(cè)試轉(zhuǎn)變到質(zhì)量

在《基礎(chǔ)篇》中提到的五個(gè)測(cè)試基本職責(zé)，那是測(cè)試人員開展測(cè)試工作務(wù)必了解的方方面面，是做好測(cè)試工作的基礎(chǔ)。

但是，要做好軟件產(chǎn)品的質(zhì)量保障工作，光從做好測(cè)試的角度考慮是遠(yuǎn)遠(yuǎn)不夠的，原因主要有兩個(gè)方面：

• 軟件質(zhì)量不能通過測(cè)試來(lái)提高。著名質(zhì)量管理專家戴明提到：“質(zhì)量沒法檢測(cè)出來(lái)，軟件產(chǎn)品開發(fā)出來(lái)后質(zhì)量就已經(jīng)在那了。”

• 軟件測(cè)試可以驗(yàn)證軟件質(zhì)量是否滿足需求，但是隨著軟件生態(tài)的復(fù)雜性和不確定性增加，沒有辦法預(yù)知軟件行為，也就沒法通過測(cè)試來(lái)驗(yàn)證軟件質(zhì)量的方方面面。

因此，測(cè)試是基本功，但只關(guān)注測(cè)試是不夠的。需要跳出測(cè)試，將視野調(diào)整到軟件開發(fā)全生命周期質(zhì)量的角度，關(guān)注質(zhì)量的各個(gè)維度，才能更好地建立體系化思維，才能更好地做好軟件產(chǎn)品的質(zhì)量保障工作。

在閱讀后面內(nèi)容之前，我希望讀者朋友們先花 10 秒鐘思考以下問題：

問題：跳出測(cè)試，從軟件質(zhì)量的角度思考，我們需要關(guān)注哪些方面？

這是一個(gè)老生常談的問題，答案似乎大家也都很清楚，但現(xiàn)實(shí)中又是很容易被忽視、被誤解的問題。

2. 軟件質(zhì)量的定義

在回答上面問題之前，我們先來(lái)看看維基百科對(duì)軟件質(zhì)量的定義 ( https://en.wikipedia.org/wiki/Software_quality )。如下圖所示：

維基百科對(duì)軟件質(zhì)量的定義包括兩個(gè)方面：

• 軟件功能質(zhì)量：基于功能需求規(guī)范看軟件是否提供了相應(yīng)的功能，這是用戶使用軟件的角度，是軟件外部的質(zhì)量。

• 軟件結(jié)構(gòu)質(zhì)量：對(duì)支持功能需求交付的非功能需求的滿足情況，比如健壯性、可維護(hù)性等，這是從軟件內(nèi)部結(jié)構(gòu)來(lái)看，是軟件內(nèi)部的質(zhì)量。

維基百科的這個(gè)定義跟咱平常提到的軟件質(zhì)量包含外部質(zhì)量和內(nèi)部質(zhì)量是一致的。外部質(zhì)量是從軟件外部可感知的，是從用戶角度對(duì)軟件感知到的使用質(zhì)量；內(nèi)部質(zhì)量則涉及到軟件的內(nèi)部形態(tài)，包括技術(shù)架構(gòu)和代碼質(zhì)量等，是從團(tuán)隊(duì)開發(fā)人員的角度感知到的。

相信大家對(duì)于外部質(zhì)量好理解，是用戶角度能夠感知到的質(zhì)量。而內(nèi)部質(zhì)量往往很容易被忽視，其實(shí)這也是因?yàn)槿藗兤毡槿菀鬃非蠖唐诶?#xff0c;看不到內(nèi)部質(zhì)量給軟件產(chǎn)品帶來(lái)的長(zhǎng)遠(yuǎn)影響，這里想給大家看個(gè)非常熟悉的圖，以增強(qiáng)對(duì)內(nèi)部質(zhì)量的重視。

不加整理的富含技術(shù)債的代碼，就如同圖中雜亂無(wú)章纏繞在一起的電線，嚴(yán)重影響著產(chǎn)品缺陷定位修復(fù)、后期功能擴(kuò)展等。

3. 容易忽視的質(zhì)量影響因素

理解了質(zhì)量的定義，在日常軟件開發(fā)工作中有哪些因素是會(huì)影響到軟件質(zhì)量的呢？其實(shí)，影響的因素特別的多，可能包括但不限于以下這些：

1）需求分析過程倉(cāng)促，或者參與人員角色比較單一，導(dǎo)致業(yè)務(wù)上下文了解不夠，關(guān)鍵場(chǎng)景缺乏考慮等；

2）忙于交付更多的特性，忽略了對(duì)代碼質(zhì)量的關(guān)注，該重構(gòu)的沒有重構(gòu)，在原本不太健康的代碼基礎(chǔ)上繼續(xù)增加更多的代碼，導(dǎo)致混亂，筑起高高的技術(shù)債；

3）沒有足夠的測(cè)試覆蓋，導(dǎo)致新增代碼容易破壞已有功能；

4）開發(fā)人員提交代碼后，就投入新代碼的開發(fā)，對(duì)所提交代碼缺乏關(guān)注，持續(xù)集成流水線上測(cè)試掛了不能及時(shí)修復(fù)，可能影響后面的測(cè)試進(jìn)度；

5）大面積的重構(gòu)發(fā)生在發(fā)布前夕，無(wú)法全面回歸，帶來(lái)很大的風(fēng)險(xiǎn)；

6）項(xiàng)目初期只考慮少量用戶的場(chǎng)景，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)功能難以擴(kuò)展，導(dǎo)致嚴(yán)重性能瓶頸；

7）技術(shù)選型失誤，開發(fā)困難，沒有及時(shí)改進(jìn)，一錯(cuò)再錯(cuò)，最后問題嚴(yán)重到無(wú)法彌補(bǔ)；

8）第三方組件評(píng)估不夠充分，導(dǎo)致線上環(huán)境無(wú)法承載等；

9）開發(fā)缺少對(duì)異常情況的處理，測(cè)試過程缺乏探索，只覆蓋到主干路徑，邊角用例可能引發(fā)問題；

10）開發(fā)或者測(cè)試都只考慮當(dāng)前功能模塊，缺乏更廣范圍的考慮；

11）缺乏跨功能需求的關(guān)注，導(dǎo)致嚴(yán)重的安全或者性能問題；

12）對(duì)線上環(huán)境了解不夠，而且沒有足夠日志信息記錄，線上問題難以定位，導(dǎo)致宕機(jī)時(shí)間過長(zhǎng)；

13）等更多……

? ?

02 質(zhì)量保障與質(zhì)量?jī)?nèi)建

1. 質(zhì)量如何保障

從質(zhì)量維度來(lái)看體系化思維的構(gòu)建，而質(zhì)量是產(chǎn)品與生俱來(lái)的，做好軟件產(chǎn)品的質(zhì)量保障工作更為有效的方式就是要將質(zhì)量構(gòu)建到軟件產(chǎn)品本身，提高軟件產(chǎn)品與生俱來(lái)的質(zhì)量。這也就是質(zhì)量?jī)?nèi)建（Build Quality In）的概念。

這個(gè)還是太抽象，為了更清楚的解釋質(zhì)量?jī)?nèi)建，先來(lái)看兩個(gè)概念：暴露缺陷與預(yù)防缺陷。

2. 暴露缺陷與預(yù)防缺陷

“暴露缺陷”的概念眾所周知，就是軟件所暴露出來(lái)的缺陷，通常在測(cè)試或使用過程中被發(fā)現(xiàn)。

如果能夠全面統(tǒng)計(jì)一個(gè)軟件產(chǎn)品的所有可能引起缺陷的地方，我們可以說該軟件存在缺陷的總量是一定的。當(dāng)然，現(xiàn)實(shí)情況是我們不可能全面考慮到所有的因素，缺陷是很難窮盡的。

如果這一定數(shù)量的缺陷中有一部分可以通過某些措施來(lái)預(yù)防，那么軟件在測(cè)試或最終用戶使用過程中所暴露出來(lái)的缺陷數(shù)量就會(huì)減少，這就是缺陷預(yù)防——減少暴露給用戶的缺陷。

軟件開發(fā)過程是個(gè)持續(xù)遞增的過程，預(yù)防缺陷也不是一蹴而就的事情，需要在整個(gè)軟件開發(fā)過程持續(xù)的進(jìn)行。當(dāng)然，盡早預(yù)防缺陷會(huì)更好，這樣可以顯著減少缺陷修復(fù)的成本，提高投入產(chǎn)出比。下圖曲線非常清晰地展示了修復(fù)不同階段暴露出來(lái)的缺陷所需成本的差異，修復(fù)成本是隨著軟件開發(fā)周期顯著增加的。

3. 質(zhì)量?jī)?nèi)建如何做

將缺陷概念擴(kuò)展為軟件產(chǎn)品質(zhì)量相關(guān)的所有問題，那么做好了缺陷預(yù)防也就是做到了質(zhì)量?jī)?nèi)建。

前文提到過容易被忽視的質(zhì)量影響因素，要做好質(zhì)量?jī)?nèi)建這些因素都是需要重點(diǎn)關(guān)注的。

但是，由于軟件開發(fā)過程的復(fù)雜性，要一次性做對(duì)所有事情、預(yù)防所有的缺陷是不可能的。因此，質(zhì)量?jī)?nèi)建并不是嚴(yán)格意義上的不能有任何缺陷暴露，而是需要在軟件開發(fā)生命周期中盡早地把事情做對(duì)，并且通過持續(xù)的獲取快速的反饋來(lái)糾偏。

我們都知道那個(gè)有名的 PDCA 環(huán)（也稱“戴明環(huán)”）：

將質(zhì)量管理分為四個(gè)階段，即 Plan(計(jì)劃)、Do(執(zhí)行)、Check(檢查) 和 Act(處理)。在質(zhì)量管理活動(dòng)中，要求把各項(xiàng)工作按照作出計(jì)劃、計(jì)劃實(shí)施、檢查實(shí)施效果，然后將成功的納入標(biāo)準(zhǔn)，不成功的留待下一循環(huán)去解決。

質(zhì)量?jī)?nèi)建可以理解為在軟件開發(fā)全生命周期中，從需求到線上頻繁地執(zhí)行 PDCA 環(huán)，小步前進(jìn)，持續(xù)反饋驗(yàn)證，及時(shí)調(diào)整改進(jìn)。如下圖所示：

? ?

03 質(zhì)量?jī)?nèi)建深入實(shí)踐

前面主要從概念和理念層面介紹了質(zhì)量和質(zhì)量?jī)?nèi)建，這些內(nèi)容對(duì)構(gòu)建體系化思維是至關(guān)重要的，有助于拓寬視野，形成全局觀。但光有這些內(nèi)容不夠，還得了解具體的落地實(shí)施方法。接下來(lái)就從質(zhì)量?jī)?nèi)建相關(guān)實(shí)踐來(lái)探討質(zhì)量?jī)?nèi)建在軟件開發(fā)生命周期的落地實(shí)施方案。

1. 質(zhì)量?jī)?nèi)建的核心

在介紹具體的質(zhì)量?jī)?nèi)建實(shí)踐之前，還是需要從抽象層面來(lái)理解質(zhì)量?jī)?nèi)建的核心，其內(nèi)容可以分為四個(gè)方面：

• 測(cè)試左移

• 快速反饋

• 測(cè)試右移

• 全員參與

1.1 測(cè)試左移

傳統(tǒng)軟件開發(fā)會(huì)分成分析、設(shè)計(jì)、開發(fā)、測(cè)試、發(fā)布等幾個(gè)相對(duì)獨(dú)立的階段，而測(cè)試是其中發(fā)生在開發(fā)完成之后的一個(gè)階段。

測(cè)試左移是針對(duì)傳統(tǒng)這種獨(dú)立測(cè)試階段來(lái)說的，不再?gòu)?qiáng)調(diào)獨(dú)立的測(cè)試階段，而是要將測(cè)試活動(dòng)左移到軟件開發(fā)生命周期的最早階段（最左邊）——需求階段，從需求階段開始做好缺陷預(yù)防的工作。

要特別提醒注意的是，測(cè)試左移不是測(cè)試人員左移，而是強(qiáng)調(diào)的測(cè)試活動(dòng)左移：

• 左移到傳統(tǒng)獨(dú)立測(cè)試階段左側(cè)就叫左移，不一定是左移到需求階段。當(dāng)然，根據(jù)前面對(duì)質(zhì)量?jī)?nèi)建的闡述，理想情況下肯定是越左邊越好。如果做不到徹底左移，能移一步也是進(jìn)步。

• 測(cè)試人員的確需要左移參與相應(yīng)的活動(dòng)。但是，如果測(cè)試人員參與需求階段，卻沒有起到澄清需求、驗(yàn)證需求有效性的作用，那就不是有效的測(cè)試左移，關(guān)鍵要看成效。

• 不僅測(cè)試人員要左移，開發(fā)等其他角色也需要左移。因?yàn)樾枨笥行缘尿?yàn)證，需要不同角色的經(jīng)驗(yàn)，需要來(lái)自不同視角的輸入；不同角色都有責(zé)任參與到每個(gè)環(huán)節(jié)的測(cè)試活動(dòng)中來(lái)。

• 只要能做到從需求階段開始就有相應(yīng)的測(cè)試活動(dòng)，不一定都是測(cè)試人員參與。這里強(qiáng)調(diào)的是測(cè)試活動(dòng)要有，哪個(gè)角色來(lái)做不是最關(guān)鍵的，角色其實(shí)就是戴了一定帽子而已。我們知道，有的團(tuán)隊(duì)是沒有測(cè)試人員的，但不代表這些團(tuán)隊(duì)沒有測(cè)試活動(dòng)。

1.2 快速反饋

快速反饋，也就是頻繁持續(xù)地反饋，可以理解為一個(gè)持續(xù)測(cè)試的過程。

通常快速反饋需要有自動(dòng)化的支撐，比如自動(dòng)化測(cè)試、流水線上自動(dòng)代碼掃描等；也可以是一些人工參與的實(shí)踐環(huán)節(jié)，比如手動(dòng)測(cè)試、各類評(píng)審和驗(yàn)收等。通過這樣的一些實(shí)踐活動(dòng)盡快地獲取相應(yīng)工作（可能是需求分析、開發(fā)等）的反饋，根據(jù)反饋結(jié)果進(jìn)行及時(shí)的修復(fù)、調(diào)整、或者優(yōu)化。

為了保障快速反饋/持續(xù)測(cè)試實(shí)踐活動(dòng)的有效開展，通常需要增加質(zhì)量門禁，并確保質(zhì)量門禁的嚴(yán)格執(zhí)行。

1.3 測(cè)試右移

測(cè)試右移是跟測(cè)試左移對(duì)應(yīng)的，就是將測(cè)試活動(dòng)從獨(dú)立測(cè)試階段右移到生產(chǎn)環(huán)境。

但因?yàn)樯a(chǎn)環(huán)境的特殊性，測(cè)試右移又不是測(cè)試活動(dòng)的簡(jiǎn)單右移，而是通過一些實(shí)踐活動(dòng)獲取生產(chǎn)環(huán)境下用戶行為、日志等質(zhì)量相關(guān)信息，利用這些信息來(lái)給前期的需求、開發(fā)和測(cè)試工作提供反饋，促進(jìn)相應(yīng)工作的優(yōu)化改進(jìn)，以更好的做好質(zhì)量?jī)?nèi)建。

測(cè)試右移本身不能直接內(nèi)建質(zhì)量，但是可以幫助更好地質(zhì)量?jī)?nèi)建，所以我認(rèn)為測(cè)試右移也是質(zhì)量?jī)?nèi)建不可或缺的核心內(nèi)容之一。

這部分的內(nèi)容比較多，之前有過詳細(xì)的介紹，此處不再贅述。歡迎參考文章《測(cè)試右移——生產(chǎn)環(huán)境下的 QA》閱讀更為詳細(xì)的內(nèi)容。

1.4 全員參與

測(cè)試左移、快速反饋和測(cè)試右移都不是某個(gè)單一角色/人員可以做到的，需要不同角色的不同技能和不同視角的輸入，質(zhì)量人人有責(zé)，需要全員參與并且能承擔(dān)起質(zhì)量職責(zé)才行。

全員參與不僅是很多實(shí)踐活動(dòng)需要大家一起參與，還有很重要的一點(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ì)對(duì)質(zhì)量負(fù)責(zé)，“我”可以不負(fù)責(zé)？》、《敏捷測(cè)試的指導(dǎo)性原則》、《說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢？》等文章。

2. 質(zhì)量?jī)?nèi)建典型實(shí)踐

綜合來(lái)看，質(zhì)量?jī)?nèi)建的典型實(shí)踐通常有（但不限于）下圖這些：

不管是傳統(tǒng)開發(fā)模式還是敏捷迭代式開發(fā)模式，軟件開發(fā)生命周期都會(huì)有需求分析、開發(fā)實(shí)現(xiàn)和線上使用三個(gè)階段，只是敏捷模式下需求和開發(fā)是迭代式進(jìn)行，在時(shí)間上不是界限清晰的階段。

這里為了描述方便，暫且將這些實(shí)踐分成三個(gè)階段來(lái)描述，事實(shí)上實(shí)踐活動(dòng)跟階段也不是關(guān)聯(lián)非常緊密的，遵循測(cè)試左移、快速反饋、測(cè)試右移和全員參與這幾個(gè)核心思想才是關(guān)鍵所在。

2.1 需求分析

這里強(qiáng)調(diào)四個(gè)我認(rèn)為跟需求分析密切相關(guān)的典型質(zhì)量?jī)?nèi)建實(shí)踐，分別是需求澄清、行為驅(qū)動(dòng)開發(fā)（BDD）、實(shí)例化需求（SbE）和需求評(píng)審。

需求澄清：需求的理解和澄清作為測(cè)試基本職責(zé)之一，在《基礎(chǔ)篇》中有較為詳細(xì)的介紹，請(qǐng)移步參考。不過，在這里需要補(bǔ)充的是不僅測(cè)試要參與需求澄清，還需要其他相應(yīng)的角色協(xié)同參與，比如開發(fā)人員、技術(shù)負(fù)責(zé)人、技術(shù)架構(gòu)師等。

行為驅(qū)動(dòng)開發(fā)（BDD）：關(guān)于 BDD，很多人誤認(rèn)為是一種測(cè)試方法，但其實(shí) BDD 主要是為了三方更好地對(duì)需求達(dá)成一致認(rèn)識(shí)，只不過通過 BDD 方式產(chǎn)生的需求能夠很好地指導(dǎo)自動(dòng)化測(cè)試的開展。更多詳情，請(qǐng)參考我之前的文章《說起 BDD，你會(huì)想到什么？》。

實(shí)例化需求（SbE）：SbE 的核心思想跟 BDD 類似，但強(qiáng)調(diào)了一點(diǎn)要將需求描述通過實(shí)例來(lái)說明，以更好地發(fā)現(xiàn)漏掉的需求，讓需求更完整、更容易被多方理解和澄清。

需求評(píng)審：需要開發(fā)和測(cè)試跟業(yè)務(wù)分析人員一起討論確認(rèn)需求，可能是正式的會(huì)議針對(duì)某個(gè)特性（大塊需求）的評(píng)審，也可以是針對(duì)單個(gè)需求條目或敏捷用戶故事進(jìn)行線下評(píng)審。如果前期需求澄清過程中對(duì)需求的討論已經(jīng)比較透徹，這里的評(píng)審就會(huì)比較輕量級(jí)，由測(cè)試人員（開發(fā)按需參與）自行安排時(shí)間評(píng)審即可。

這些實(shí)踐都是為了更好地在需求分析階段讓團(tuán)隊(duì)對(duì)需求達(dá)成一致的理解，確保需求的質(zhì)量，減少后期因需求問題帶來(lái)的返工和浪費(fèi)。

2.2 開發(fā)實(shí)現(xiàn)

需求源頭的質(zhì)量控制好了，接下來(lái)就是在開發(fā)實(shí)現(xiàn)階段持續(xù)地通過快速反饋的方式確保每一步工作的質(zhì)量，下面的實(shí)踐都是為此服務(wù)的：

技術(shù)方案討論：不是要介紹這個(gè)實(shí)踐怎么做，而是要提醒在做技術(shù)方案討論的時(shí)候測(cè)試要盡量參與。一方面，測(cè)試清楚了解技術(shù)方案，才能更好地設(shè)計(jì)相應(yīng)的測(cè)試策略，更完備的進(jìn)行測(cè)試；另一方面，測(cè)試基于自己對(duì)系統(tǒng)的了解，可以給技術(shù)方案的討論提供輸入，比如系統(tǒng)重點(diǎn)需要考慮和關(guān)注的問題等。可能有人會(huì)覺得測(cè)試技術(shù)水平跟不上，參與價(jià)值不大，但我想說的是不參與就不會(huì)有進(jìn)步，只要參與了就一定會(huì)有收獲，從長(zhǎng)期來(lái)看，不管是對(duì)個(gè)人還是對(duì)團(tuán)隊(duì)整體都是非常有價(jià)值的。

需求條目啟動(dòng)：也叫用戶故事啟動(dòng)（Story kickoff）、開卡等。對(duì)于單個(gè)可開發(fā)需求，在開發(fā)人員要開始編碼前進(jìn)行的再次澄清和確認(rèn)，主要是確認(rèn)其中的驗(yàn)收標(biāo)準(zhǔn)是否不夠完備、是否大家都理解一致了。形式要求盡量輕量級(jí)，在開發(fā)人員電腦前完成即可，需要業(yè)務(wù)分析、開發(fā)和測(cè)試共同參與，時(shí)間一般不要超過 15 分鐘。

需求條目驗(yàn)收：跟啟動(dòng)是配對(duì)的，也叫用戶故事驗(yàn)收（Desk check/Shoulder check/Story signoff）、結(jié)卡/驗(yàn)卡等。同樣在開發(fā)機(jī)器前面完成，一般由開發(fā)將功能演示給業(yè)務(wù)分析和測(cè)試人員，大家確認(rèn)需求中的正向路徑是否都已經(jīng)開發(fā)實(shí)現(xiàn)了。更多詳情可參考文章《高效用戶故事驗(yàn)收》。

測(cè)試用例設(shè)計(jì)：在《基礎(chǔ)篇》有對(duì)測(cè)試用例設(shè)計(jì)作詳細(xì)的介紹，從質(zhì)量?jī)?nèi)建的角度來(lái)看主要是想說測(cè)試用例設(shè)計(jì)盡量早點(diǎn)做，而且對(duì)于用例設(shè)計(jì)的形式可以相對(duì)靈活些，列舉需要關(guān)注的測(cè)試點(diǎn)才是關(guān)鍵，從快速反饋的角度，不建議過于注重形式和流程。

測(cè)試驅(qū)動(dòng)開發(fā)：TDD，常見的有單元測(cè)試驅(qū)動(dòng)開發(fā)（UTDD）和驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)（ATDD），通過先寫測(cè)試的方式驅(qū)動(dòng)設(shè)計(jì)的完備性。Thoughtworks 同事劉冉老師有多篇關(guān)于 TDD 的文章，請(qǐng)移步他的網(wǎng)站「劉冉的思辨悟 ( http://liuranthinking.com )」查閱參考。

代碼評(píng)審：Code review，也叫代碼回顧。有團(tuán)隊(duì)成員聚集在一起做回顧的，也有獨(dú)立線下評(píng)審的模式。Thoughtworks 同事伍斌道長(zhǎng)的文章《Code Review: 超越“審、查、評(píng)”的代碼回顧》有關(guān)于 code review 非常詳細(xì)的講解，請(qǐng)移步參考。

自動(dòng)化回歸測(cè)試：根據(jù)測(cè)試分層理論，自動(dòng)化測(cè)試可能包括單元測(cè)試、接口集成測(cè)試和端到端測(cè)試。通常單元測(cè)試是開發(fā)人員編寫，而接口集成測(cè)試和端到端集成測(cè)試可以開發(fā)和測(cè)試協(xié)作完成。關(guān)于自動(dòng)化測(cè)試相關(guān)文章比比皆是，這里推薦如下內(nèi)容供參考：

《精益測(cè)試》

《微服務(wù)測(cè)試的思考與實(shí)踐》

《測(cè)試金字塔不是銀彈》

《一個(gè)遺留系統(tǒng)自動(dòng)化測(cè)試的七年之癢》

Thoughtworks 洞見自動(dòng)化測(cè)試文集 ( https://insights.thoughtworks.cn/?s=%25E8%2587%25AA%25E5%258A%25A8%25E5%258C%2596%25E6%25B5%258B%25E8%25AF%2595 )

劉冉老師網(wǎng)站的自動(dòng)化測(cè)試文集 ( http://liuranthinking.com/automatedtesting/ )

單元測(cè)試評(píng)審：單元測(cè)試評(píng)審一般發(fā)生在需求條目驗(yàn)收環(huán)節(jié)，詳情參考文章《QA 評(píng)審底層測(cè)試的價(jià)值》。

持續(xù)集成：持續(xù)集成（CI）概念大家并不陌生，但是有效實(shí)施卻不是那么容易。常見的反例有：

光有持續(xù)集成流水線，但是流水線上啥也沒有，沒有代碼掃描、沒有自動(dòng)化測(cè)試、沒有質(zhì)量門禁；

流水線有接入代碼掃描，但是掃描出問題沒有及時(shí)修復(fù)；

自動(dòng)化測(cè)試沒有在流水線上頻繁執(zhí)行，或者執(zhí)行失敗不能及時(shí)修復(fù)；

代碼沒有頻繁提交；

……

更多內(nèi)容，推薦參考 Thoughtworks 洞見文章《持續(xù)集成理論和實(shí)踐的新進(jìn)展》和《對(duì)于持續(xù)集成實(shí)踐的常見問題的解答》。

自動(dòng)化/持續(xù)部署：自動(dòng)化部署在提高效率的同時(shí)還可以減少手工部署引入的問題，讓部署能夠更頻繁更持續(xù)地發(fā)生。這部分內(nèi)容可以參考 Thoughtworks 洞見文章《持續(xù)集成和交付流水線的反模式》。

技術(shù)債管理：還記得前面那個(gè)布滿雜亂無(wú)章電線的圖嗎？軟件開發(fā)過程中引入的技術(shù)債如果沒有得到有效管理，軟件內(nèi)部也會(huì)亂成那個(gè)樣子。關(guān)于技術(shù)債管理，推薦 Thoughtworks 同事麻廣廣的文章《軟件架構(gòu)治理之技術(shù)債的前世今生》。

探索式測(cè)試：探索式測(cè)試有助于發(fā)現(xiàn)一些潛在的不易察覺的缺陷，是非常推薦的一個(gè)實(shí)踐。具體做法和建議在《基礎(chǔ)篇》中對(duì)探索式測(cè)試有詳細(xì)介紹。

客戶驗(yàn)收：英文叫 Showcase，就是給客戶、業(yè)務(wù)方演示開發(fā)實(shí)現(xiàn)的特性。Showcase 也有很多常見誤區(qū)，請(qǐng)移步文章《敏捷實(shí)踐 Showcase 的七宗罪》。

缺陷分析：缺陷分析對(duì)質(zhì)量?jī)?nèi)建的幫助主要是通過分析找出問題根因，在后續(xù)的開發(fā)工作中提前避免以預(yù)防更多的缺陷暴露。如何做好缺陷管理和分析？請(qǐng)參考下列文章：

《軟件缺陷的有效管理》

《缺陷分析如何幫助質(zhì)量?jī)?nèi)建》

《都是臟數(shù)據(jù)惹的禍》

質(zhì)量狀態(tài)報(bào)告和質(zhì)量風(fēng)險(xiǎn)分析：請(qǐng)參考《基礎(chǔ)篇》中“測(cè)試職責(zé)之五：質(zhì)量反饋與風(fēng)險(xiǎn)識(shí)別”部分的介紹。

回顧會(huì)議：回顧會(huì)議通過總結(jié)和分析過去一段時(shí)間團(tuán)隊(duì)發(fā)生的事情，是關(guān)于團(tuán)隊(duì)整體健康狀態(tài)的。我之所以將回顧會(huì)議列為質(zhì)量?jī)?nèi)建的典型實(shí)踐，是因?yàn)樵蹅兦懊嬗懻撨^了影響質(zhì)量的因素涉及到方方面面，自然就跟團(tuán)隊(duì)的健康有著很大的關(guān)系。利用好回顧會(huì)議這個(gè)實(shí)踐，及時(shí)發(fā)現(xiàn)問題并采取對(duì)應(yīng)的改進(jìn)舉措，將是非常有價(jià)值的。關(guān)于回顧會(huì)議的高效開展，可以參考 Thoughtworks 洞見文章《高效回顧會(huì)議的七步議程》。

2.3 線上使用

軟件產(chǎn)品發(fā)布到線上，質(zhì)量?jī)?nèi)建相關(guān)實(shí)踐就都是跟測(cè)試右移有關(guān)的，這是一個(gè)很大的主題，之前有過系列文章的介紹，相關(guān)實(shí)踐可以參考下列文章：

• 《測(cè)試右移——生產(chǎn)環(huán)境下的 QA》

• 《測(cè)試右移之日志收集與監(jiān)控》

• 《測(cè)試右移：QA 與 Ops 通力合作打造反脆弱的軟件系統(tǒng)》

? ?

04 寫在最后

測(cè)試基本職責(zé)是測(cè)試人員必備之基礎(chǔ)技能，但測(cè)試的體系化思維構(gòu)建不能僅局限于測(cè)試工作本身，當(dāng)我們跳出測(cè)試，從質(zhì)量的角度來(lái)看，又是另一番景象。

希望本《進(jìn)階篇》能夠幫助各位測(cè)試同仁從質(zhì)量的角度拓寬視野，增加大局觀，讓質(zhì)量保障工作做得更順暢。

總結(jié)

以上是生活随笔為你收集整理的构建测试的体系化思维（进阶篇）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。