上一篇關(guān)于測試用例設(shè)計的博文《設(shè)計測試用例的四條原則》中，介紹了設(shè)計測試用例的四條原則。本篇結(jié)合最近工作遇到的一個小插曲，介紹一下測試用例本身Passed和Failed的有效性問題。
我所在的團隊上個 Sprint有一項很重要的工作，就是進行Stress 測試，需要編寫自動化用例測試模擬程序長時間的執(zhí)行，并觀察其內(nèi)存消耗是否呈現(xiàn)合理的增長趨勢，以及有沒有內(nèi)存的泄漏等問題。同事很快編寫好了測試用例， 并執(zhí)行了個把個小時，得出了初步的數(shù)據(jù)。數(shù)據(jù)顯示程序的表現(xiàn)相當(dāng)完美，不僅內(nèi)存沒有陡峭的突變，甚至連大斜率的線性增長也木有，基本呈現(xiàn)為一條略有波動的 水平直線。非常讓人振奮，這樣的表現(xiàn)打消團隊之前的擔(dān)心，完成這項工作所需的時間也將大大小于之前的預(yù)估。
我對這項測試也非常感興趣， 并和同事進行了一些交流，想深入了解一些更詳細的情況，比如測試數(shù)據(jù)規(guī)模、執(zhí)行的時間長短、測試數(shù)據(jù)分布等，隨著交流的深入同事突然意識到似乎測試代碼似 乎有些不大合乎常理的表現(xiàn)，進一步調(diào)試發(fā)現(xiàn)代碼中一段生成數(shù)據(jù)的代碼并沒有正確生成數(shù)據(jù)，雖然測試仍在執(zhí)行但輸入的數(shù)據(jù)沒有，測試只是在空轉(zhuǎn)，并沒有真正 執(zhí)行被測程序的邏輯，所以整個曲線才呈現(xiàn)為一條水平線。
這件事本身是個小問題，但其背后隱藏著一個值得我們深究的問題：當(dāng)你的測試用例Passed的時候，被測產(chǎn)品果真是正確的嗎？仔細想想這個問題，可以得到一些對我們的測試工作有意的思考：
1. 自動化測試需要有詳細的日志輸出，以便于診斷測試的確切執(zhí)行情況。
自動化測試用例的執(zhí)行過程對我們來說是一個黑盒過程，我們一般只是看到它的結(jié)果是Passed或者Failed。如果這個黑盒過程本身就是錯誤的，如本 文一開始所給出的例子，結(jié)果是Passed就沒有任何意義了。而且這樣的Passed只會是給問題雪上加霜，減少了發(fā)現(xiàn)問題的可能性。
2. 測試人員特別是自動化測試工程師，應(yīng)該對那些看似完美的東東多些疑問，多些探究精神，在經(jīng)過客觀途徑驗證之前時刻保持謹慎的樂觀。
從某個角度講，經(jīng)常Failed測試用例并不值得你太擔(dān)心，而那些從來都是Passed的用例，應(yīng)該是值得你抽時間檢查的對象。
3. 測試用例要么Passed要么 Failed，看似簡單的結(jié)果，但其中還是有些值得深究的內(nèi)容的。
任何一個測試用例實際上是肩負著雙重責(zé)任： 其一，保證在被測功能正確的情況下，測試用例應(yīng)該是Passed；其二，則是在被測功能異常的情況下，測試返回Failed。一般的情況下，我們只是驗證 了第一種情況后就算完成，并將用例提交到用例管理庫或者代碼庫中。很少真正有人去驗證一下在被測試功能異常的情況下，測試用例確實Failed。這樣的用 例驗證可以總結(jié)為如下的模式：
| Passed –> Passed –> Passed –> …-> Passed? or Failed? |
之所以會有這樣的情況，首先，是因為從意識上講，大多數(shù)人都認為測試中對被測功能行為的判斷以足夠強壯，但其實這種沒有客觀佐證的判斷并不可靠；其次， 很多用例的實現(xiàn)和執(zhí)行多是在被測功能實現(xiàn)之后才開始，這時的被測功能剛實現(xiàn)出來，并經(jīng)過開發(fā)人員反復(fù)調(diào)試修改，絕大多數(shù)情況下都是正確的，由于產(chǎn)品代碼已 經(jīng)提交，此時很難再有簡單的途徑模擬出錯誤的功能行為，以驗證測試用例Failed的情況。
解決的辦法有兩種：一、盡可能尋找途徑去模擬被測功能的異常；二、再就是合理選擇實現(xiàn)測試用例的時間。很多情況我們的用例是為了覆蓋已有的Bug而添加的，以避免回歸缺陷。這樣的測試用例最好是在Bug修復(fù)之前就實現(xiàn)，那么它一定是Failed，這個機會就可以驗證出Failed情況。
擴展一下這個話題，從用例Failed/Passed路徑這角度上看，測試驅(qū)動開發(fā)（Test Driven Development，TDD）的模型更為合理和自然。因為，TDD強調(diào)先有測試用例，再實現(xiàn)產(chǎn)品功能代碼，先實現(xiàn)的測試用例必然是經(jīng)過一系列的Failed之后，最終達到Passed，其模型可以總結(jié)如下：
| Failed –> Failed –> Failed –> …–> Passed |
TDD的原理保證了測試用例一定是由Failed開始，到Passed結(jié)束，所以不用費心去模擬功能異常以得到Failed結(jié)果，同時保證了用例對Failed和Passed都一定進行了驗證。
4. 產(chǎn)品的質(zhì)量有測試來監(jiān)控，那么誰來監(jiān)控測試本身的質(zhì)量呢？人、過程和工具。
人－測試人員需要更有責(zé)任心，保持對任何問題的謹慎樂觀和探究精神；過程－測試計劃和用例的交叉評審，測試代碼也要進行review，同時選擇合理的時機實現(xiàn)測試；工具 – 利用代碼覆蓋來探究測試用例有效性。
總之，我們在編寫和實現(xiàn)測試用例的時候，除了實現(xiàn)基本功能之外，還要多留意的用例（特別是自動化用例）Passed和Failed有效性，經(jīng)常容易被忽略地是Failed有效性，所以要盡可的尋找途徑來驗證其有效性。