做軟件測(cè)試要想保質(zhì)保量，就要做到測(cè)試充分，什么是測(cè)試充分，就是把所需要覆蓋的場(chǎng)景都要覆蓋到。

如何做到場(chǎng)景全面覆蓋，特別是在時(shí)間緊任務(wù)重的時(shí)候？

我把我這些年來(lái)工作的一點(diǎn)經(jīng)驗(yàn)總結(jié)一下分享給大家，希望對(duì)大家有點(diǎn)幫助：

No.1 提前介入測(cè)試

那么什么時(shí)候測(cè)試介入比較好？在需求明確下來(lái)進(jìn)入開(kāi)發(fā)之前，測(cè)試就可以介入了解需求的相關(guān)內(nèi)容了。

這塊一般有兩個(gè)階段：

第一個(gè)階段是需求澄清階段，這個(gè)階段就是需求接口人向開(kāi)發(fā)講解需求的詳細(xì)要求及實(shí)現(xiàn)功能，這個(gè)時(shí)候測(cè)試就可以參與進(jìn)來(lái)一起聽(tīng)，聽(tīng)過(guò)之后我們就對(duì)這個(gè)需求有了一個(gè)大概的了解，知道了這個(gè)功能的是要做什么，輸入輸出是什么，為后期了解詳細(xì)的實(shí)現(xiàn)方案做準(zhǔn)備。

第二個(gè)階段是開(kāi)發(fā)實(shí)現(xiàn)方案澄清階段，這個(gè)階段一般是相關(guān)的開(kāi)發(fā)人員把需求的功能實(shí)現(xiàn)方案和詳細(xì)邏輯跟需求提出人和接口人確認(rèn)，我們這個(gè)時(shí)候參與進(jìn)來(lái)，就可以根據(jù)開(kāi)發(fā)講的實(shí)現(xiàn)方案和邏輯了解相關(guān)的的內(nèi)容：比如算法判斷邏輯是啥，取值是啥，輸入值的類(lèi)型是啥，取的哪個(gè)表哪個(gè)字段的值，或者調(diào)取那個(gè)接口服務(wù)，異常輸入又是如何處理的，結(jié)果體現(xiàn)在哪里等等。

當(dāng)然有些小公司是沒(méi)有給這些階段的時(shí)間的，拿到需求就可能是口頭說(shuō)一下開(kāi)發(fā)就直接實(shí)現(xiàn)，不會(huì)再次的澄清，這個(gè)時(shí)候我們?cè)趺崔k，只有自己主動(dòng)找開(kāi)發(fā)溝通，遇到與開(kāi)發(fā)理解不一致的時(shí)候，還要找產(chǎn)品經(jīng)理或需求拉口人再次確認(rèn)，來(lái)避免需求不清晰導(dǎo)致的一些不必要的問(wèn)題，也為我們后期的測(cè)試用例編寫(xiě)找到明確的答案。

No.2 測(cè)試分析，測(cè)試用例設(shè)計(jì)

根據(jù)前期的了解，接下來(lái)我們就是要把這些存在于我們腦海中的信息轉(zhuǎn)化為文字形式列出來(lái)，并分析出我們的測(cè)試場(chǎng)景。

為啥要把這些信息轉(zhuǎn)化文字，不根據(jù)所想直接列測(cè)試場(chǎng)景，因?yàn)檫@些信息存在我們腦海中的很容易忘記，而且不是很清晰，只有通過(guò)有章法的梳理信息后，才能形成對(duì)我們有用的信息。

不知道大家有沒(méi)有這樣的情景，一個(gè)需求你看文檔或者聽(tīng)需求接口人和開(kāi)發(fā)都講過(guò)了，你也知道是啥了，感覺(jué)沒(méi)啥問(wèn)題了，可是當(dāng)你下去寫(xiě)測(cè)試用例的時(shí)候，你還是會(huì)有些地方模糊不清楚。

那么把我們了解的信息形成文字，就能很好的幫助我們解決這個(gè)問(wèn)題。

如何梳理這些信息呢，我一般是按照這樣的順序來(lái)的：

1）先分析需求的背景，業(yè)務(wù)要求。

把之前了解的需求背景都寫(xiě)出來(lái)，遇到不明確的及時(shí)詢問(wèn)相關(guān)人員，直到明確。

比如一個(gè)需求的背景是這樣的：業(yè)務(wù)人員在一線作業(yè)的時(shí)候發(fā)現(xiàn)某個(gè)模塊在一些國(guó)家是需要特殊型號(hào)的，而在系統(tǒng)訂單中默認(rèn)配置的是另外一個(gè)型號(hào)，他們希望配置這個(gè)國(guó)家訂單的時(shí)候，系統(tǒng)能自動(dòng)識(shí)別出來(lái)并把這個(gè)模塊替換成指定的型號(hào)。

那我們?cè)趯?xiě)需求背景的時(shí)候不僅僅是寫(xiě)上面那段話了，就要把“一些國(guó)家”中的國(guó)家給明確寫(xiě)出來(lái)，就是這些國(guó)家是哪幾個(gè)國(guó)家，國(guó)家名稱是啥，代碼是啥，同時(shí)模塊型號(hào)也要明確寫(xiě)出來(lái)，替換前的模塊是哪個(gè)？型號(hào)是啥？替換后的模塊是啥，型號(hào)又是啥？

2)分析需求實(shí)現(xiàn)方案和邏輯

這里就是把我們前期了解到的開(kāi)發(fā)實(shí)現(xiàn)方案和邏輯一一羅列出來(lái)，有必要的可以用圖畫(huà)出來(lái)如開(kāi)發(fā)的實(shí)現(xiàn)流程，邏輯判斷流程，數(shù)據(jù)走向等等。

就比如上面那個(gè)需求，開(kāi)發(fā)的實(shí)現(xiàn)方案是應(yīng)該包括這個(gè)國(guó)家是從訂單哪個(gè)信息里面取出來(lái)的，需要更換模塊型號(hào)的國(guó)家又是放在哪里的，是怎么取模塊型號(hào)的，更換后的結(jié)果在哪里體現(xiàn)等等

那我們?cè)谶@個(gè)分析模塊就要把這些都列出來(lái)，并一一明確。

3）分析測(cè)試要點(diǎn)，測(cè)試要素

根據(jù)前面兩項(xiàng)的分析，我們應(yīng)該很快的就理出我們的測(cè)試要點(diǎn)，重點(diǎn)關(guān)注項(xiàng)等內(nèi)容

就說(shuō)上面這個(gè)模塊型號(hào)更換吧，我們知道了：國(guó)家，指定模塊型號(hào)，更換后的模塊型號(hào)體現(xiàn)在哪里，都是我們的關(guān)注對(duì)象，同時(shí)我們還應(yīng)知道這個(gè)更換型號(hào)對(duì)于沒(méi)有不在指定國(guó)家的范圍內(nèi)的，型號(hào)是不受影響的。那么這些就是我們的測(cè)試要點(diǎn)和要素了。

4）列出測(cè)試場(chǎng)景

根據(jù)上面的分析，我們可以把我們所需要測(cè)試的場(chǎng)景以表格的形式寫(xiě)出來(lái)了

5）把測(cè)試場(chǎng)景轉(zhuǎn)化為測(cè)試用例

到此，我們就可以輸出測(cè)試用例了，那我們這個(gè)用例到底充分與否，結(jié)果輸出是否正確，我們的理解是否到位呢？

接下來(lái)我們就要請(qǐng)相關(guān)的人員對(duì)我們的文檔和用例進(jìn)行一個(gè)評(píng)審了。

No.3 測(cè)試用例評(píng)審

測(cè)試用例評(píng)審不僅僅評(píng)審的是測(cè)試用例，還有我們對(duì)這個(gè)需求的理解和我們的思路，所以在評(píng)審的時(shí)候我們應(yīng)該先把我們的測(cè)試分析文檔講一下，然后再把我們的測(cè)試用例拿出來(lái)給大家講一下，重點(diǎn)講測(cè)試的輸入和輸出結(jié)果。

這樣下來(lái)在開(kāi)發(fā)和系統(tǒng)設(shè)計(jì)人員的幫助下，我們就可以及早發(fā)現(xiàn)用例的不足以及我們忽略的測(cè)試點(diǎn)，及時(shí)補(bǔ)充測(cè)試用例，完善測(cè)試用例。

這個(gè)在以前的公司測(cè)試用例評(píng)審是要求很?chē)?yán)的，每個(gè)參于評(píng)審的人都必須要提出問(wèn)題點(diǎn)，就是為了避免有些參于評(píng)審的人員只參于不評(píng)審，導(dǎo)致一些問(wèn)題遺留到最后。

No.4 嚴(yán)格按照測(cè)試用例執(zhí)行測(cè)試

這一點(diǎn)很重要，為什么這么說(shuō)呢？因?yàn)槟銣y(cè)試用例設(shè)計(jì)的再好，你不按照它來(lái)執(zhí)行，你的測(cè)試就不可能做到充分。

還記得有一次我做好了一個(gè)需求的測(cè)試用例，評(píng)審?fù)耆y(cè)試的時(shí)候，我覺(jué)得自己記得差不多了就按自己記的開(kāi)始測(cè)試沒(méi)有按測(cè)試用例一個(gè)個(gè)的執(zhí)行，前面測(cè)試的很快，問(wèn)題也不多。

等后面回歸測(cè)試的時(shí)候，我就突然發(fā)現(xiàn)多出好幾個(gè)問(wèn)題，原因就是我沒(méi)按測(cè)試好的測(cè)試用例全面覆蓋漏測(cè)了兩個(gè)關(guān)聯(lián)點(diǎn)，打此以后，我再也不敢脫離測(cè)試用例，自己憑記憶測(cè)試了。

No.5 分解需求

有些需求接到的晚或著手測(cè)試的晚，功能又復(fù)雜，又要求按時(shí)上線，這個(gè)時(shí)候怎么辦？

把需求測(cè)試用例完成后，按功能分成幾個(gè)小功能點(diǎn)，分配給多個(gè)組員測(cè)試（當(dāng)然這個(gè)在給參與測(cè)試的人員之前要把需求功能詳細(xì)的講解一下），在測(cè)試的過(guò)程中要保持經(jīng)常溝通，做到寧可交叉重復(fù)測(cè)試也不脫節(jié)測(cè)試。

我記得當(dāng)時(shí)有一個(gè)web系統(tǒng)的功能，前期的時(shí)候因?yàn)槊χ鴳?yīng)對(duì)其他緊急的需求，就把它放在一邊了，后面提上日程的時(shí)候發(fā)現(xiàn)留給我的時(shí)間不多了，我一個(gè)人測(cè)試肯定測(cè)試不全，這時(shí)我就主動(dòng)找主管溝通，多調(diào)兩個(gè)同事來(lái)和我一起測(cè)試，然后在兩個(gè)同事的協(xié)助下，才順利完成了這個(gè)功能的測(cè)試。

No.6 交叉測(cè)試

對(duì)于大的需求或都功能復(fù)雜的需求要做到多人交叉測(cè)試，這種測(cè)試在系統(tǒng)測(cè)試的時(shí)候就可以進(jìn)行，以前我所在公司的項(xiàng)目每到系統(tǒng)測(cè)試都會(huì)進(jìn)行這樣的安排，這樣就可以避免到后期回歸測(cè)試出現(xiàn)更多的問(wèn)題。

No.7 重點(diǎn)功能要及時(shí)跟蹤進(jìn)行測(cè)試充分性分析

對(duì)于那些功能復(fù)雜，風(fēng)險(xiǎn)性高的項(xiàng)目，我們要在每進(jìn)行完一輪測(cè)試，進(jìn)行一次測(cè)試充分性分析以便及時(shí)做出調(diào)整。

有一次我們有一個(gè)比較大的改動(dòng)，而這個(gè)改動(dòng)涉及到了我們這個(gè)軟件流程中的一個(gè)核心點(diǎn)，也就是涉及到的內(nèi)容比較多，然而留給測(cè)試的時(shí)間卻不是很多只有兩周，怎么辦呢？組長(zhǎng)首先把這個(gè)改動(dòng)按影響到的功能點(diǎn)細(xì)化分了一下，分給了三個(gè)人進(jìn)行測(cè)試，每天她都跟進(jìn)統(tǒng)計(jì)測(cè)試進(jìn)度，分析問(wèn)題分布點(diǎn)，跟進(jìn)問(wèn)題修改情況，然后再根據(jù)這些及時(shí)調(diào)整測(cè)試策略，經(jīng)過(guò)兩周緊張的有序的測(cè)試，這個(gè)功能最終穩(wěn)當(dāng)?shù)纳暇€。

以上筆者的經(jīng)歷更像一張橫向的知識(shí)網(wǎng)，創(chuàng)建了一個(gè)交流平臺(tái) 914172719 ，群內(nèi)有各種技術(shù)同行交流、學(xué)習(xí)資料、面試經(jīng)驗(yàn)等。其中用到j(luò)enkins、docker、moutebank、python編程等，還需要花更多的精力去深入學(xué)習(xí)，當(dāng)每項(xiàng)技能都能掌握到一定深度，才能稱為一個(gè)完整的知識(shí)體系。

最后： 可以關(guān)注公眾號(hào)：傷心的辣條 ！ 進(jìn)去有許多資料共享！資料都是面試時(shí)面試官必問(wèn)的知識(shí)點(diǎn)，也包括了很多測(cè)試行業(yè)常見(jiàn)知識(shí)，其中包括了有基礎(chǔ)知識(shí)、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫(kù)、抓包工具專(zhuān)題、接口測(cè)試工具、測(cè)試進(jìn)階-Python編程、Web自動(dòng)化測(cè)試、APP自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試、測(cè)試高級(jí)持續(xù)集成、測(cè)試架構(gòu)開(kāi)發(fā)測(cè)試框架、性能測(cè)試、安全測(cè)試等。

如果我的博客對(duì)你有幫助、如果你喜歡我的博客內(nèi)容，請(qǐng) “點(diǎn)贊” “評(píng)論” “收藏” 一鍵三連哦！

好文推薦

轉(zhuǎn)行面試，跳槽面試，軟件測(cè)試人員都必須知道的這幾種面試技巧！

面試經(jīng)：一線城市搬磚！又面軟件測(cè)試崗，5000就知足了…

面試官：工作三年，還來(lái)面初級(jí)測(cè)試？恐怕你的軟件測(cè)試工程師的頭銜要加雙引號(hào)…

什么樣的人適合從事軟件測(cè)試工作？

那個(gè)準(zhǔn)點(diǎn)下班的人，比我先升職了…

測(cè)試崗反復(fù)跳槽，跳著跳著就跳沒(méi)了…