雖然已經(jīng)2023年了，但還是有技術(shù)人員認(rèn)為，測(cè)試是不需要理解需求背景和設(shè)計(jì)方案，也不用參加需求評(píng)審、設(shè)計(jì)評(píng)審，只需要按照需求文檔，就可以編寫詳細(xì)全面的測(cè)試用例，甚至很多測(cè)試也是這么認(rèn)為的。也有很多純黑盒功能測(cè)試對(duì)自己熟練掌握“業(yè)務(wù)流程”而沾沾自喜。不理解業(yè)務(wù)流程背后的邏輯，僅依靠需求文檔和對(duì)業(yè)務(wù)的表面理解，真的可以做好測(cè)試工作嗎。
因?yàn)闇y(cè)試工作是針對(duì)一系列輸入，將輸出結(jié)果和預(yù)期進(jìn)行比較的過程。我們可以將代碼當(dāng)成一個(gè)函數(shù)y=f(x)。因?yàn)椴恢纼?nèi)部實(shí)現(xiàn)邏輯，我們不知道這是什么函數(shù)，只能設(shè)計(jì)一系列輸入，x1、x2、x3，看輸出的y1、y2、y3是否和需求文檔中說明的預(yù)期相同。而且由于不可能窮舉所有輸入，通常按照等價(jià)類邊界值等方式選取有代表性的值（或組合)作為輸入。
假設(shè)需求是x和y的乘積是10，我們可能會(huì)選x=1、2、1.5、2.5，測(cè)試結(jié)果確實(shí)無誤。但是，代碼中的設(shè)計(jì)是y=10/x，當(dāng)x為0時(shí)，程序就異常了。不理解函數(shù)，你能知道x是不能為0的嗎，你會(huì)剛好覆蓋到這個(gè)場(chǎng)景嗎。
你可能會(huì)說，x為0是特殊值，肯定會(huì)測(cè)試的，那假設(shè)函數(shù)為y=10/(x-1)呢，你保證一定會(huì)覆蓋到這個(gè)值嗎。
你可能會(huì)說，特殊情況應(yīng)該在文檔標(biāo)明，否則就是文檔疏漏。如果需求要求xy=10，只是程序設(shè)計(jì)成了y=10/x呢。
你可能又會(huì)說，那這就是需求和設(shè)計(jì)不符，開發(fā)沒有按照需求實(shí)現(xiàn)，噢，親愛的，你的工作就是要找出這些不一致吖，讓開發(fā)100%按照需求實(shí)現(xiàn)，你琢磨琢磨這個(gè)可能性有多大。
于是你退一步說，那開發(fā)應(yīng)該在設(shè)計(jì)文檔里標(biāo)明實(shí)現(xiàn)邏輯，或者在測(cè)試案例評(píng)審的時(shí)候跟測(cè)試提出需要增加這個(gè)情況的測(cè)試，有沒有可能開發(fā)寫的時(shí)候覺得這里肯定不會(huì)出問題。
你也可能會(huì)說，然后我不懂背后邏輯，但是我測(cè)試經(jīng)驗(yàn)豐富，根據(jù)以往錯(cuò)誤經(jīng)驗(yàn)，經(jīng)常能發(fā)現(xiàn)重要缺陷，看到上傳圖片我就能想到圖片類型、圖片大小限制，看到金額計(jì)算我就知道不能用float類型處理，你能確保每次都剛好選中特殊入?yún)帷?br> 開發(fā)說優(yōu)化了代碼，讓你回歸一下，比如原本函數(shù)是y=√x^2，改成了y=x，這兩個(gè)函數(shù)看起來相等，但是x的作用域其實(shí)不同，這并不真正是同一個(gè)函數(shù)，所以你真的不用知道開發(fā)的改動(dòng)點(diǎn)，只是拿幾個(gè)場(chǎng)景測(cè)一下主流程就覺得可以0 bug上線了嗎。
再舉一個(gè)常見的例子。借款申請(qǐng)?zhí)峤怀晒摃?huì)提示該客戶在我行未開卡，請(qǐng)聯(lián)系客戶經(jīng)理辦卡。測(cè)試同學(xué)認(rèn)為，測(cè)試數(shù)據(jù)默認(rèn)沒有開卡，這樣提示是正常的，當(dāng)要執(zhí)行有卡的情況的案例時(shí)，找開發(fā)同學(xué)拿測(cè)試數(shù)據(jù)，一提交果然提示已開卡，測(cè)試通過。
你有沒有思考過，校驗(yàn)客戶是否開卡的邏輯是什么，是某個(gè)服務(wù)提供了專門的查詢接口，檢驗(yàn)的要素是什么，或者是去某某庫中查詢的，這個(gè)庫的數(shù)據(jù)是怎么來的，是業(yè)務(wù)系統(tǒng)自己的數(shù)據(jù)還是從基礎(chǔ)數(shù)據(jù)導(dǎo)過來的，導(dǎo)數(shù)的邏輯是什么，會(huì)不會(huì)出現(xiàn)注銷了的卡也當(dāng)成已開卡，導(dǎo)數(shù)是T+0還是T+1，如果是T+1會(huì)不會(huì)有問題。當(dāng)你看到頁面上這個(gè)您已開卡/未開卡時(shí)，有思考過這些問題嗎，還是看到頁面有按照需求的不同結(jié)果展示，就認(rèn)為測(cè)試充分了。
功能測(cè)試不只是根據(jù)原型圖在頁面上點(diǎn)點(diǎn)點(diǎn)，能跳轉(zhuǎn)到相應(yīng)的頁面，返回相應(yīng)的數(shù)據(jù)，出現(xiàn)相應(yīng)的提示就是100%覆蓋了。你可以不看代碼，但是對(duì)你負(fù)責(zé)的系統(tǒng)，你需要知道業(yè)務(wù)流程、數(shù)據(jù)走向、表結(jié)構(gòu)、數(shù)據(jù)類型。否則即使你測(cè)完了，發(fā)現(xiàn)了多少缺陷，也順利通過了驗(yàn)收，測(cè)試質(zhì)量也是堪憂的，只是什么時(shí)候生產(chǎn)問題會(huì)暴露出來而已。
這里說的業(yè)務(wù)流程，不僅是操作流程，還包括系統(tǒng)交互、數(shù)據(jù)流，即使你熟練掌握該系統(tǒng)使用流程，用戶填寫××提交后，系統(tǒng)返回××，后臺(tái)生成代辦事項(xiàng)……是個(gè)使用過的人都可以說出來，你作為系統(tǒng)的測(cè)試和使用者的區(qū)別是什么，核心競(jìng)爭(zhēng)力是什么。你應(yīng)該知道，用戶填寫的信息，提交是用的什么接口，是什么服務(wù)調(diào)用什么服務(wù)，數(shù)據(jù)是落到什么表，哪些任務(wù)是通過調(diào)度觸發(fā)的。
現(xiàn)在我們經(jīng)常聽到測(cè)試質(zhì)量和測(cè)試效率，測(cè)試質(zhì)量不是單純靠時(shí)間堆砌能彌補(bǔ)的。就拿前面的y=10/(x-1)來說，你設(shè)計(jì)了1000個(gè)xn，如果你沒有剛好用x=1，顯然這1000個(gè)測(cè)試案例都可以測(cè)試通過并且發(fā)現(xiàn)不了缺陷，但是如果你知道這個(gè)邏輯，你就可以輕松找到讓系統(tǒng)出錯(cuò)的參數(shù)，而不必做無用功。
所以對(duì)測(cè)試而言，設(shè)計(jì)文檔和需求文檔是同等重要的，測(cè)試非常有必要參與設(shè)計(jì)評(píng)審。在設(shè)計(jì)測(cè)試用例階段，也要多和開發(fā)溝通設(shè)計(jì)實(shí)現(xiàn)細(xì)節(jié)，才能設(shè)計(jì)出針對(duì)性強(qiáng)的測(cè)試用例，避免遺漏測(cè)試點(diǎn)，并且能在這個(gè)階段通過設(shè)計(jì)方案提前發(fā)現(xiàn)開發(fā)的漏洞，發(fā)現(xiàn)系統(tǒng)風(fēng)險(xiǎn)是最好的了。同理，測(cè)試用例評(píng)審時(shí)，所有相關(guān)的開發(fā)也需要參與，除了補(bǔ)充測(cè)試用例中遺漏的重要測(cè)試場(chǎng)景，還可以給開發(fā)完善設(shè)計(jì)的思路。
你說，那這樣不是斃掉了不懂代碼的測(cè)試嗎。不是的，設(shè)計(jì)不等于代碼，你知道系統(tǒng)調(diào)用鏈路并不等于你需要知道代碼中的每個(gè)類。
你說，測(cè)試資源受限制，沒有這么多精力去理解，給測(cè)試的時(shí)間只剛好夠?qū)憸y(cè)試用例和執(zhí)行測(cè)試，哪里有時(shí)間去搞懂實(shí)現(xiàn)方式。首先這并不會(huì)花費(fèi)你什么額外時(shí)間，而且越是時(shí)間不夠，精準(zhǔn)測(cè)試就越重要不是嗎。