---

讀完需要

22

分鐘

速讀僅需 8 分鐘

之前寫過一篇文章《神圣的QA》，是面向想從事 QA 工作的畢業(yè)生同學(xué)的，文中有講到 QA 的五個(gè)基本職責(zé)：

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

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

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

• 缺陷管理與分析

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

最近有朋友希望我能分享體系化的測試需要關(guān)注哪些方面，我又想到了這五個(gè)基本職責(zé)。原文中基于“生產(chǎn)杯子”的需求對于五個(gè)職責(zé)有解釋，本文將展開每個(gè)職責(zé)，從測試實(shí)踐和方法集的角度來分析測試需要做什么和怎么做。

? ?

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

業(yè)務(wù)需求是軟件開發(fā)的源頭，正確理解需求的正確性不言而喻，理解和澄清需求也是測試工作至關(guān)重要的一部分。

1. 理解和澄清業(yè)務(wù)需求的維度

具體該如何去理解和澄清需求呢？我認(rèn)為測試人員可以從以下三個(gè)維度去理解和澄清業(yè)務(wù)需求：

關(guān)于這幾個(gè)維度的詳細(xì)內(nèi)容，在文章《敏捷測試如何優(yōu)化業(yè)務(wù)價(jià)值》中有介紹。

2. 需求的可測試性

正確理解業(yè)務(wù)需求以外，對需求的描述質(zhì)量也需要關(guān)注，其中需求的可測試性是最為重要的一個(gè)方面：

• 如果需求不可測，也就不可驗(yàn)收，沒辦法知道項(xiàng)目是否成功完成；

• 以可測試的方式編寫需求，才能確保需求能夠正確實(shí)現(xiàn)并驗(yàn)證。

需求的可測試性主要體現(xiàn)在下面三個(gè)維度：

完備性

需求的完備性主要指流程路徑需要考慮全面，要求邏輯鏈路完整，既要有正向路徑，也要包括異常場景。

比如：正確的用戶名密碼可以登錄，不正確的用戶名和密碼登錄會發(fā)生什么，這兩者都是需要清晰定義的。

客觀性

需求的描述不要用一些主觀性的詞語，而是需要客觀的數(shù)據(jù)和示例來說明。比如下面這段主觀性的描述是個(gè)非常糟糕的需求示例：

系統(tǒng)應(yīng)該易于有經(jīng)驗(yàn)的工程師使用，并且應(yīng)該使得用戶的出錯(cuò)盡可能少。

推薦采用“實(shí)例化需求” ( http://www.woshipm.com/pmd/4074396.html )的方式來編寫需求文檔，將業(yè)務(wù)規(guī)則通過實(shí)例表述出來，不僅易于團(tuán)隊(duì)不同角色的理解，而且不容易產(chǎn)生歧義。

獨(dú)立性

獨(dú)立性主要是針對單個(gè)業(yè)務(wù)功能點(diǎn)（敏捷開發(fā)中的用戶故事），要盡量的獨(dú)立，跟其他功能邊界清晰，減少因?yàn)橐蕾噷?dǎo)致的功能點(diǎn)不可測。

比如：輸入和輸出要在同一個(gè)功能點(diǎn)里可驗(yàn)證，A 功能點(diǎn)的輸入不能通過 B 功能點(diǎn)的輸出來驗(yàn)證。

敏捷開發(fā)中的用戶故事遵循INVEST原則( https://en.wikipedia.org/wiki/INVEST_(mnemonic) )，將可測試性和獨(dú)立性是分開描述的，我認(rèn)為獨(dú)立性也會影響可測試性，在這里把獨(dú)立性作為可測試性的一個(gè)因素。

? ?

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

制定策略并設(shè)計(jì)測試是五個(gè)職責(zé)里最為關(guān)鍵的一個(gè)，涵蓋的內(nèi)容較多?？瓷先ナ遣呗院蜏y試設(shè)計(jì)兩部分，但實(shí)際上包含了測試所需要考慮的方方面面。下面挑選我認(rèn)為比較有價(jià)值的內(nèi)容分別介紹。

1. 一頁紙測試策略

策略是方向，要做好軟件的測試工作，離不開測試策略的指導(dǎo)。測試策略通常對于經(jīng)驗(yàn)不是太豐富的測試人員來講，可能挑戰(zhàn)比較大。不過，我曾經(jīng)提出來的“一頁紙測試策略”可以很好地幫助測試人員去思考和制定自己項(xiàng)目適配的測試策略。一頁紙測試策略如下如所示：

在一頁紙測試策略里邊，清晰地定義了測試策略需要考慮的三個(gè)部分：

• 指導(dǎo)性原則：團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)

• 測什么：測試的內(nèi)容

• 怎么測：測試左移、測試右移和精益測試

更多詳情請參考我的文章《一頁紙測試策略》。

2. 測試流程與質(zhì)量門禁

我們經(jīng)常會發(fā)現(xiàn)有些團(tuán)隊(duì)的測試流程定義的也很清晰，但是每個(gè)環(huán)節(jié)要求做到什么效果并沒有嚴(yán)格的要求，很多質(zhì)量工作做的并不到位，導(dǎo)致后面測試階段測試人員的壓力巨大或者最終交付的質(zhì)量并不高。

前面一頁紙測試策略里已經(jīng)有包含測試流程部分，這里再次單獨(dú)提及主要是為了強(qiáng)調(diào)質(zhì)量門禁的重要性。測試流程每個(gè)項(xiàng)目或團(tuán)隊(duì)可能都不太一樣，但是不管測試流程包括哪些環(huán)節(jié)，每個(gè)環(huán)節(jié)的輸出結(jié)果要求務(wù)必定義清晰，也就是要清晰定義每個(gè)環(huán)節(jié)的質(zhì)量門禁，如下圖所示：

注意：此圖僅為示例，實(shí)際情況需要根據(jù)自身團(tuán)隊(duì)情況適配。

3. 典型測試類型

上面的流程圖示例中列出了多種不同的測試類型，而實(shí)際的測試類型遠(yuǎn)不止這些。由于篇幅有限且這部分內(nèi)容不是本文的重點(diǎn)，本文只介紹跟測試人員關(guān)系非常緊密的四種典型的測試類型。這四類測試的分類維度并不相同，這里不求詳盡。不清楚但又感興趣的同學(xué)，請自行網(wǎng)上搜索。

冒煙測試

冒煙測試來源于電路板的測試，也就是通電后看電路板是否冒煙，如果冒煙說明這塊電路板是不可能正常工作的，也就不用去驗(yàn)證其他功能了。

對應(yīng)到軟件的冒煙測試，就是驗(yàn)證軟件的最基本行為是否正常，例如：“程序是否運(yùn)行？”，“用戶界面是否打開？”或“單擊事件是否有效？”等。只有冒煙測試通過，才有進(jìn)一步開展驗(yàn)證軟件功能測試的必要，否則就需要先修復(fù)重新出新版本才可以。

我們發(fā)現(xiàn)有的團(tuán)隊(duì)只對新開發(fā)功能進(jìn)行冒煙測試，其實(shí)這是不太正確的，或者說這個(gè)測試就不叫冒煙測試。冒煙測試應(yīng)該是對整個(gè)系統(tǒng)級別的基本行為進(jìn)行驗(yàn)證，不區(qū)分什么新舊功能。

回歸測試

回歸測試的目的是驗(yàn)證新開發(fā)功能或者修復(fù) bug 的時(shí)候，是否對已有功能有破壞。因此，回歸測試的對象主要是針對已有功能，對于新功能的測試不叫回歸。

回歸測試的策略通常有四類：

• 全面回歸：這種就是不分青紅皂白，對所有已有功能進(jìn)行全面的測試，這種策略成本較高，但是覆蓋率較全，一般對質(zhì)量要求特別高的金融類產(chǎn)品采用全面回歸的方式較多。

• 選擇性回歸：這種一般是測試會跟開發(fā)進(jìn)行溝通，了解當(dāng)前代碼編寫可能影響到的范圍，選擇對這些受影響的功能模塊進(jìn)行回歸。這種形式可能漏掉沒有意識到但是關(guān)聯(lián)到的功能，有一定的風(fēng)險(xiǎn)，但是較為經(jīng)濟(jì)的一種做法。

• 指標(biāo)法回歸：這種一般是團(tuán)隊(duì)對回歸測試的覆蓋率有要求，比如要覆蓋 50%的已有功能測試用例，執(zhí)行回歸測試不能低于這個(gè)覆蓋率。這種光看指標(biāo)數(shù)字的做法是最不推薦的，雖然覆蓋率達(dá)標(biāo)了，但是有可能該測的沒有測到。

• 精準(zhǔn)回歸：精準(zhǔn)回歸就是當(dāng)下非常熱門的精準(zhǔn)測試，這是采用技術(shù)的手段將代碼改變所影響到的范圍跟測試用例關(guān)聯(lián)起來，精準(zhǔn)地執(zhí)行受影響的用例。這種質(zhì)量最為有保證，但是精準(zhǔn)測試實(shí)現(xiàn)成本是非常高的。

回歸測試可以手動進(jìn)行，也可以是自動化測試，但通常回歸測試的量都會比較大，以自動化的方式進(jìn)行會比較高效。

端到端測試

端到端測試基于測試覆蓋的粒度分類，是針對單元測試和接口測試等而言的。

端到端測試是從頭到尾驗(yàn)證整個(gè)軟件及其與外部接口的集成，其目的是測試整個(gè)軟件的依賴性、數(shù)據(jù)完整性以及與其他系統(tǒng)、接口和數(shù)據(jù)庫等的通信，以模擬完整的業(yè)務(wù)流程。因此，端到端測試是最能體現(xiàn)用戶真實(shí)業(yè)務(wù)行為的測試，有著非常重要的價(jià)值。

但是，由于端到端測試涉及到系統(tǒng)各個(gè)相關(guān)組件和外部依賴，其穩(wěn)定性和執(zhí)行成本相對都是比較高的。于是有了覆蓋范圍較小的接口測試和單元測試，這些測試一般都是通過隔離依賴來實(shí)現(xiàn)的測試，此處不再細(xì)述。

探索式測試

探索式測試由 Cem Kanner 博士于 1983 年提出，是針對腳本化測試而言的。

Cem Kanner 對探索式測試的定義如下：

“探索式測試是一種軟件測試風(fēng)格，它強(qiáng)調(diào)獨(dú)立測試人員的個(gè)人自由和職責(zé)，為了持續(xù)優(yōu)化其工作的價(jià)值，將測試相關(guān)學(xué)習(xí)、測試設(shè)計(jì)、測試執(zhí)行和測試結(jié)果分析作為相互支持的活動，在整個(gè)項(xiàng)目過程中并行地執(zhí)行?！?/p>

探索式測試的核心旨在將測試學(xué)習(xí)、測試設(shè)計(jì)、測試執(zhí)行和測試結(jié)果分析作為一個(gè)循環(huán)快速地迭代，以不斷收集反饋、調(diào)整測試、優(yōu)化價(jià)值。

探索式測試特別需要測試人員的主觀能動性，需要有較為寬松的鼓勵(lì)測試創(chuàng)新的環(huán)境才能較好地開展，如果對于測試指標(biāo)要求過高，測試人員主觀能動性難以發(fā)揮的情況下，探索式測試的效果也很有限。

探索式測試是一種相對自由的測試風(fēng)格，不建議被各種測試模型套住，也不建議嚴(yán)格規(guī)定探索式測試的執(zhí)行方式，這些都會影響到探索式測試的發(fā)揮。

更多的關(guān)于探索式測試的內(nèi)容歡迎參考 Thoughtworks 同事劉冉的文章《探索式測試落地實(shí)踐》和史湘陽的文章《敏捷項(xiàng)目中的探索性測試》。

4. 自動化測試分層策略

前面介紹端到端測試的時(shí)候提到了不同覆蓋范圍的測試，可能有單元測試和接口測試等。自動化分層策略就是針對這些不同粒度的測試類型進(jìn)行分層，根據(jù)成本、穩(wěn)定性等因素建議自動化測試需要考慮不同層的覆蓋比例。

根據(jù)下圖谷歌測試定律，我們能夠很清晰的看到不同層的測試發(fā)現(xiàn)問題之后的修復(fù)成本的差異性，單元測試比端到端測試發(fā)現(xiàn)的問題修復(fù)成本要低得多，因此，通常建議測試分層應(yīng)該傾向于測試金字塔 ( https://martinfowler.com/bliki/TestPyramid.html )的模式，也就是下圖右側(cè)的樣子。Thoughtworks 同事 Ham Vocke 的文章《測試金字塔實(shí)戰(zhàn)》 ( https://insights.thoughtworks.cn/practical-test-pyramid/ )對此有很詳細(xì)的介紹。

需要注意的是測試金字塔不是銀彈，測試策略不是一成不變的，需要根據(jù)實(shí)際情況階段性調(diào)整、演進(jìn)，滿足當(dāng)下產(chǎn)品/項(xiàng)目質(zhì)量目標(biāo)才是關(guān)鍵。

更多的關(guān)于自動化測試分層的內(nèi)容，還可以參考下列文章：

• 《精益測試》

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

• 《測試金字塔不是銀彈》

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

5. 測試用例

設(shè)計(jì)測試用例是每一名測試人員必備的基本功，測試用例的好壞直接影響到測試的有效性，測試用例的重要性不言而喻，但是要設(shè)計(jì)好的測試用例也不是一件很簡單的事情。這里說的測試用例不區(qū)分手動用例和自動化用例。

好的測試用例

首先，我們有必要了解什么樣的測試用例算是好的用例。

好的測試用例應(yīng)該是正好能夠覆蓋所測軟件系統(tǒng)、能夠測出所有問題的。因此，好的測試用例需要具備下列特點(diǎn)：

• 整體完備性，且不過度設(shè)計(jì)：有效測試用例組成的集合，能夠完全覆蓋測試需求；同時(shí)也不會有用例超出測試需求。

• 等價(jià)類劃分的準(zhǔn)確性：每個(gè)等價(jià)類都能保證只要其中一個(gè)輸入測試通過，其他輸入也一定測試通過。

• 等價(jià)類集合的完備性：所有可能的邊界值和邊界條件都已經(jīng)正確識別。

當(dāng)然，因?yàn)檐浖到y(tǒng)的復(fù)雜性，不是所有測試用例都能做到正好 100%覆蓋，只能是做到盡量的完備。

測試用例設(shè)計(jì)方法

力求完備的測試用例，就需要了解相應(yīng)的測試用例設(shè)計(jì)方法。測試用例應(yīng)該是結(jié)合業(yè)務(wù)需求和系統(tǒng)特點(diǎn)，綜合起來考慮設(shè)計(jì)。通常建議的用例設(shè)計(jì)方法有如下幾種：

• 數(shù)據(jù)流法：基于業(yè)務(wù)流程中的數(shù)據(jù)流來切分測試場景的方法?？紤]業(yè)務(wù)流程中的數(shù)據(jù)流，在數(shù)據(jù)存儲或者發(fā)生變化的點(diǎn)進(jìn)行流程的切斷，形成多個(gè)用例場景。這個(gè)在我的文章《說起 BDD，你會想到什么》里有介紹。

• 等價(jià)類劃分法：把程序所有可能的輸入數(shù)據(jù)劃分為若干部分，然后從每個(gè)部分中選取少數(shù)有代表性的數(shù)據(jù)作為測試用例。等價(jià)類分有效等價(jià)類和無效等價(jià)類，根據(jù)等價(jià)類劃分方法設(shè)計(jì)測試用例要注意無冗余和完備性。

• 邊界值法：邊界值分析方法是對等價(jià)類劃分的補(bǔ)充，通常取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，包括對輸入輸出的邊界值進(jìn)行測試和來自等價(jià)類邊界的用例。

• 探索式測試模型法：推薦史亮和高翔兩位老師的著作《探索式測試實(shí)踐之路》 ( https://book.douban.com/subject/11591962/ )，書中將探索式測試按測試對象不同分為系統(tǒng)交互測試、交互特性測試和單個(gè)特性測試三個(gè)層次，每個(gè)層次都分別介紹了不同的探索模型。雖然我不認(rèn)為探索式測試需要嚴(yán)格按照這些模型來做，但是這些模型是可以幫助測試人員在探索過程中進(jìn)行思考的，同時(shí)也是設(shè)計(jì)測試用例非常有價(jià)值的參考。

關(guān)于用例設(shè)計(jì)，還可以參考下列文章：

• 《業(yè)務(wù)需求與系統(tǒng)功能》

• 《敏捷 QA 需要寫測試用例嗎？》

• 《測試用例的編寫和管理》

? ?

03 實(shí)現(xiàn)和執(zhí)行測試

實(shí)現(xiàn)和執(zhí)行測試就是以測試策略為指導(dǎo)、根據(jù)設(shè)計(jì)的測試來落地執(zhí)行的相應(yīng)的測試活動。這部分內(nèi)容相對比較簡單，從手動測試和自動化測試兩個(gè)維度來簡單介紹。

1. 手動測試

手動測試，顧名思義就是手工執(zhí)行的測試，根據(jù)是否有提前設(shè)計(jì)好的測試用例（腳本）可以分為腳本化測試和探索式測試。

腳本化測試的執(zhí)行，在有成熟測試用例的前提下，相對比較簡單。但是，有些測試可能準(zhǔn)備工作較為復(fù)雜，比如要通過長鏈路來準(zhǔn)備測試數(shù)據(jù)、或者讓系統(tǒng)到達(dá)測試觸發(fā)的狀態(tài)等，還有可能要考慮不同的環(huán)境對應(yīng)的配置調(diào)整，同時(shí)也會包括環(huán)境的準(zhǔn)備和管理。這些都是測試人員要做好手工測試可能需要涉及的內(nèi)容。

關(guān)于探索式測試，在《探索式測試實(shí)踐之路》 ( https://book.douban.com/subject/11591962/ )中有詳細(xì)介紹基于測程的測試管理（Session Based Test Management，SBTM）方法來執(zhí)行探索式測試：將測試章程分解成一系列測程，測試人員在測程中完成一個(gè)特定測試章程的設(shè)計(jì)、執(zhí)行和記錄。

同樣，這個(gè)方法對探索式測試有一定的指導(dǎo)意義，但是不建議嚴(yán)格規(guī)定必須按照這個(gè)模式來執(zhí)行，不然的話就破壞了探索式測試的本質(zhì)，達(dá)不到相應(yīng)的效果。

2. 自動化測試

前面部分介紹了自動化測試的分層策略，把自動化測試的實(shí)現(xiàn)和執(zhí)行放到這里介紹。

工具選型

自動化測試的實(shí)現(xiàn)依賴于自動化測試工具，對于工具的選型非常關(guān)鍵。通常在工具選型時(shí)需要考慮如下幾個(gè)因素：

• 滿足需求：不同的項(xiàng)目有不同的需求，根據(jù)需求來選擇，不求最好，只求適合就好。

• 易于使用：常見的易用性，以及跟寫測試的人技能匹配的易用性，都是需要考慮的。同時(shí)需要易于上手，如果一款工具對于新人不友好、很難上手的話，就很難動員大家都來積極地使用。

• 支持的語言：較好的做法是使用與項(xiàng)目開發(fā)相同的語言編寫自動化腳本，讓開發(fā)人員能夠靈活地添加測試。

• 兼容性：包括瀏覽器、平臺和操作系統(tǒng)之間的兼容。

• 報(bào)告機(jī)制：自動化測試的結(jié)果報(bào)告至關(guān)重要，優(yōu)先選擇能夠提高完備的報(bào)告機(jī)制的工具。

• 測試腳本易于維護(hù)：測試代碼跟產(chǎn)品代碼一樣重要，對測試的維護(hù)不可忽視，需要一款易于維護(hù)的工具。

• 工具的穩(wěn)定性：不穩(wěn)定性會導(dǎo)致測試有效性降低，首先要保證工具本身的穩(wěn)定性，不然得不償失。

• 代碼執(zhí)行速度：測試代碼的執(zhí)行速度直接影響到測試效率，比如 Selenium 和 Cypress 編寫的測試代碼執(zhí)行速度就有很大差別。

測試實(shí)現(xiàn)

關(guān)于自動化測試的文章隨處可見，這里強(qiáng)調(diào)一點(diǎn)，不要把測試數(shù)據(jù)寫死在測試腳本里，要將數(shù)據(jù)獨(dú)立出來，做到數(shù)據(jù)驅(qū)動，以提高測試代碼的可復(fù)用性。

自動化測試的執(zhí)行

是不是覺得自動化測試實(shí)現(xiàn)以后，執(zhí)行就是簡單的跑起來就可以呢？也不是。測試的執(zhí)行也需要一定的策略，例如：對不同的測試按需設(shè)置不同的執(zhí)行頻率，將自動化測試跟流水線集成做到持續(xù)地測試，以持續(xù)反饋，最大化發(fā)揮自動化測試的價(jià)值。

關(guān)于自動化測試，推薦閱讀以下文章：

• 《新一代支持 BDD 的測試框架 Gauge+Taiko》

• 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/ )

? ?

04 缺陷管理與分析

缺陷對軟件質(zhì)量、軟件測試來講是非常寶貴的，好的缺陷管理和分析將會帶來很大的價(jià)值，但是往往容易被忽略。

缺陷管理很重要的一個(gè)部分是搞清楚缺陷的生命周期是什么樣的。往往大家覺得缺陷從發(fā)現(xiàn)到修復(fù)并驗(yàn)證通過了就可以了，其實(shí)并不止這些。我認(rèn)為缺陷的生命周期應(yīng)該包括如下階段：

發(fā)現(xiàn)缺陷：這個(gè)比較簡單，就是發(fā)現(xiàn)跟期望行為不一致的系統(tǒng)行為，或者性能、安全等非功能性問題。缺陷可能是在測試過程中發(fā)現(xiàn)，也可能由用戶報(bào)告，還可以是例行日志分析或日志監(jiān)控報(bào)警等等通過日志來發(fā)現(xiàn)。

定位和信息收集：發(fā)現(xiàn)缺陷之后，需要收集相應(yīng)的缺陷信息并做初步定位。其中，缺陷相關(guān)信息要盡可能收集全，包括完整的重現(xiàn)步驟、影響范圍、用戶、平臺、數(shù)據(jù)、屏幕截圖、日志信息等。這一步有的時(shí)候可能需要開發(fā)或者運(yùn)維人員幫忙。

記錄缺陷：就是將收集到的日志信息記錄在日志管理系統(tǒng)，關(guān)聯(lián)相應(yīng)的功能模塊，并定義嚴(yán)重性。

Triage/排優(yōu)先級：對于記錄的缺陷也不是所有的都要修復(fù)，所以要先對缺陷進(jìn)行分類整理，確定缺陷是否有效、對有效缺陷的優(yōu)先級排序，并且確定哪些是要修復(fù)以及在什么時(shí)間修復(fù)。這一步可能需要跟業(yè)務(wù)和開發(fā)人員一起來完成。

修復(fù)缺陷：這一步就交給開發(fā)人員來完成，對缺陷進(jìn)行修復(fù)。

測試缺陷修復(fù)：對開發(fā)修復(fù)的缺陷進(jìn)行驗(yàn)證，確保缺陷本身已經(jīng)修復(fù)，并且需要對相關(guān)功能進(jìn)行適當(dāng)?shù)幕貧w測試。

添加相應(yīng)的自動化測試：對于已經(jīng)發(fā)現(xiàn)的缺陷，最好添加自動化測試，下次如果再發(fā)生類似的問題可以通過自動化測試及時(shí)地發(fā)現(xiàn)。自動化測試可以是單元測試、接口測試或者 UI 測試，根據(jù)實(shí)際情況結(jié)合自動化測試分層策略來定。這一步可能跟上一步順序倒過來。

統(tǒng)計(jì)和分析缺陷：對缺陷的數(shù)量和嚴(yán)重程度進(jìn)行統(tǒng)計(jì)分析其同比/環(huán)比趨勢，用魚骨圖和 5 Why 法等分析缺陷發(fā)生的根因，定位缺陷引入的階段，并且分析之前缺陷預(yù)防舉措的執(zhí)行效果等。

制定改進(jìn)舉措預(yù)防缺陷：根據(jù)第 8 步分析的結(jié)果，制定相應(yīng)的可以落地的改進(jìn)舉措，以預(yù)防缺陷的發(fā)生。

定期回顧和檢查改進(jìn)情況：結(jié)合缺陷的統(tǒng)計(jì)分析，定期回顧缺陷管理的系列活動，并檢查改進(jìn)舉措的執(zhí)行情況，以持續(xù)優(yōu)化缺陷管理流程，更好的預(yù)防缺陷。

關(guān)于缺陷的管理和分析，我之前有寫過相應(yīng)的文章，朋友們歡迎移步閱讀：

• 《軟件缺陷的有效管理》

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

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

? ?

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

測試對產(chǎn)品質(zhì)量狀態(tài)需要有清晰的認(rèn)識，能夠及時(shí)識別質(zhì)量風(fēng)險(xiǎn)，并反饋給整個(gè)團(tuán)隊(duì)。

前面講到缺陷的統(tǒng)計(jì)分析，與質(zhì)量相關(guān)的除了有缺陷信息以外，可能還有很多其他的數(shù)據(jù)，將這些數(shù)據(jù)進(jìn)行收集和統(tǒng)計(jì)，并且可視化展示給團(tuán)隊(duì)，將會幫助團(tuán)隊(duì)不同角色更好地做到為質(zhì)量負(fù)責(zé)。在對質(zhì)量數(shù)據(jù)的統(tǒng)計(jì)和分析過程中可以識別到相關(guān)的質(zhì)量風(fēng)險(xiǎn)，將風(fēng)險(xiǎn)也一并反饋給團(tuán)隊(duì)很有必要。

質(zhì)量狀態(tài)信息可能包括測試覆蓋率、缺陷相關(guān)數(shù)據(jù)、代碼凍結(jié)期長度、測試等待時(shí)間等內(nèi)容，具體需要收集哪些信息還得根據(jù)項(xiàng)目實(shí)際的質(zhì)量需求來定制化。

質(zhì)量反饋建議周期性的進(jìn)行，由測試人員主導(dǎo)定義需要收集的數(shù)據(jù)有哪些，開發(fā)人員協(xié)同測試人員一起收集相關(guān)數(shù)據(jù)，后面的分析過程可能也需要開發(fā)人員的參與。

? ?

06 寫在最后

本文為構(gòu)建測試的體系化思維的基礎(chǔ)篇，主要是從測試的基本職責(zé)出發(fā)展開，介紹了相關(guān)的方法、工具和實(shí)踐，適合初級測試人員；當(dāng)然，對于中高級測試人員，也可以對照著看看是不是這些基本職責(zé)平常都做到了，在自身的測試體系里邊是否涵蓋了相關(guān)內(nèi)容。

總結(jié)

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

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