軟件測試淺悟妄語

妄語：
 
　　軟件是不可測試的，因為我們的眼界不是無限的、手段不是無限的；
　　軟件是可以測試的，因為軟件的用戶是有限的，用戶的操是有限的。
 
小序：
 
　　近日有朋友抱怨說自己因為寫不出測試Case、報不出Bug而壓力很大，以致經常夢到豬籠草及殺蟲劑，或者在廚房中遭遇不長眼的小強并將其拍死后竟條件反射地打開電腦想報個Bug給Lead。朋友問我怎么辦，其實我也是一臉苦笑——抓Bug有時是要看運氣的——如果Version是在寅時Build出來，興許Bug會多一些，如果是在申時Build出來，興許Bug會少很多（如果開發團隊在國外，別忘記倒時差）。
　　這些當然是說笑。我想說的是，目前市面上大多數軟件測試類書籍都是國外作者寫成，雖然也有不少著作是我們中國測試專家寫成，但里面引經據典了很多國外作品，使測試思想沿習了歐美的思路。
　　一個民族最偉大的東西是什么？是文化和思想。那么我們能不能用中國的文化和思想去重新審視軟件測試的方法，創新出自己的思路來呢？本文就是一次斗膽嘗試。
 
正文：
 
　　測試中的文化

　　西方人善于推理，因此他們的測試流程是——
　　1. Test Plan
　　2. Test Case
　　3. Find Bug
　　4. Review fixed bug
　　以上這4個環節是用推理的辦法逐步細化，并隨著軟件版本的更新而迭代前行的。
 
　　中國人善于歸納，按照上面的這個流程做測試時，最大的困難是第一步到第二步的跨越——依Test Plan去正推Test Case是件很痛苦的事情，很容易陷入兩個誤區：一個誤區是寫了一大堆不疼不癢的Case，把測試變成了跑龍套；另一個誤區是過分追求要抓到Bug，結果產生很多疏漏。
　　為什么會出現這種情況呢？原因在于文化。Test Plan本身是按“邏輯”將軟件的功能分組，然后進行測試，老外的邏輯思維能力是比較強的，基本上能夠比較輕松地把符合Test Plan中某個分枝的操作都挑出來、Fill進Test Plan里，而這在我們中國人看來，這是對軟件操作的一種“割裂”，因此心里會感覺很亂、無從下手——于是測試就成了一個怎么也走不出去的迷宮。
　　我的辦法是：先寫Test Plan，但不以Test Plan為指導方針；按照軟件的Functions寫Test Case，然后把Test Case分門別類填充到Test Plan的框架中去——這一步就是歸納——有時候對于特殊的軟件，甚至可以歸納出不同尋常的測試分支來。
　　你可能會問：不按Test Plan怎么寫Case??？？那不成了胡寫八寫了？
　　下面我就來說說我是怎么分析功能、寫Case的。
 
從“測試”二字說起
 
　　一個民族的文化能夠得以保存，是因為有了語言和文字。其中尤以文字最為厲害，因為語言難以記錄（錄音機、MP3和DV那是近幾年的事兒），在千萬年的口耳相傳中難免產生訛變和失傳，而文字是相當穩定的東西，即使發生訛變和誤用，機率也比語言要小得多。
　　特別是中國的方塊字，那就是一座寶藏。古人在造字之初的含義就蘊含在這方寸之間，雖歷經甲骨鐘鼎、篆圓楷正，卻幾乎一點不變地穿越時空，把祖先想表達的意思直接帶到我們面前。拉丁文等拼音文字就差一些了，它沒有“形狀”，只能依靠字母的排列組合來作為遺傳的DNA了。
　　中國人把Test翻譯成測試，妙哉！
　　先看“測”字。從“水”、從“則”?！皠t”為何物？我們常說的“規則”，規是用來畫圓的、矩是用來畫直角的，則最早是用“刀”把章法刻在“鼎”上讓人們遵守的——后引申為“尺度”。這下，圓規、直尺、三角板都齊了，呵呵。拿尺子伸到水里，不就是測量水的深度嗎？這就是“測”的本意——亙古未變。再進一步，其實測量不光能測水深吧，凡是與被測對象的屬性打交道、進行量化的行為，都應該算作“測”。秦始皇下大力氣統一“度”（長度）“量”（體積）“衡”（貨幣），不都是為了方便測試行業在全國的統一發展嗎。請大家注意，“測”字為我們傳遞了一個非常重要的信息，那就是“靜態”?；旧峡梢哉f，如果被測對象不是相對靜態的，那么就無法測量了。量子物理中的“測不準原理”中的測，也正是說明這一點。
　　再看“試”字。從“言”從“式”。 試，用也——《說文》。毋庸多言，“試”字為我們傳遞的重要理念是“動態”——使用，當然是動態的。而且，軟件測試在國際范圍內的公共定義就是“為了找到軟件缺陷而進行的使用”。引申一步，“試”字從“言”，又有“考試”一個含義?？磥?，這個考試是口試了，呵呵。既然是考試，那么問答就是必要的了，所以會有一個言字，其實這一“問”和一“答”就是軟件的“輸入”與“輸出”。
　　軟件的Build從拿到我們手里開始，就是處在“動”與“靜”的交替狀態。既然是動靜交替，我們非要先把靜的挑出來寫成Case、再把固定某一種“動”挑出來寫成Case（而不管它在什么時候出現），當然是件很麻煩的事情。那么我們應該怎么辦呢？
 
對軟件的“測”
 
　　上文提到，靜者為測。讓我們想想軟件都在什么時候是“靜”的。
　　我們看一個自然的流程：Build下載à下載完成à安裝à安裝完成à開啟à使用à關閉à卸載。哪些是靜？哪些是動？讓我們一一剖析。
1.         下載 ：     全部屬性處在動態而不可測中。
2.         完成：      靜態。此時可測量軟件的大小、Hash驗證碼等。
3.         安裝：      全部屬性處在動態而不可測中。
4.         完成：      靜態。此時可測量軟件各文件大小，目錄，COM注冊情況，注冊表情況等屬性。
5.         開啟：      動態。全部屬性處在動態而不可測中。
6.         使用：      半動態。哈！怎么是半動態呢？因為這時候軟件已經從硬盤Load進內存了，在內存中是相對靜態的。你可以觀察內存占用是否穩定、有否泄漏。這就叫“靜中有動，動中有靜”，這才是咱們中國人的哲學。
7.         關閉：      靜態。檢查運行后的生成物（如聊天記錄、Log文件、temp文檔）是應該存在還是被刪除。
8.         卸載：      靜態。檢查有沒有遺留物，硬盤、注冊表，都找找看。
 
　　看，這樣理順下來，是不是寫Case就輕松多了？如果要是按照Test Plan的架構來寫Case，這些Case應該分布在至少是“內存檢驗”“注冊表檢驗”“安裝測試”“文件完整性測試”……等等分支里?？傊?，在軟件處在相對靜態的時候，你能深入想出軟件的多少屬性，那么就能寫多少Case。進而，你能想出多少直接和間接影響軟件這些屬性的環境因素，就又有多少Case出現……然而，我們的思考能力是有限的，我們幾乎不可能把軟件的所有屬性都想到，我們也不可能把所有可能影響軟件靜態屬性的環境因素都找出來——即使是使用各種靜態測試工具，比如內存跟蹤工具等——也不可以完全做到。因此，有了我開篇的妄語。
 
對軟件的“試”
 
　　上文說過，“試”是動態的。對軟件的動態測試比較復雜，一是要時刻提醒自己要識別一些相對靜止的屬性，把對它們的觀測提出來，二是動態測試要分析的東西也比較多——但并不是沒有章法。
　　軟件動態測試之“道”，只有兩個字，那就是——宇宙。
　　古往今來謂之“宇”，它強調一個時序關系。我們在動態測試的時候，特別要注意軟件操作的時序，因為每一步的操作都在直接和間接地影響著后面的操作。
　　上下四方謂之“宙”，它強調一個空間關系。如果我們把軟件看作一個系統，那么“宙”就是這個系統的環境。
　　舉個簡單例子，我們觀察上面的測試流程中的第3步“安裝”：
　　它的“宇”就是前兩步和后幾步，如果“宇”中的第2步出了問題——下載的時候文件出了問題，那么安裝肯定要失敗的。
　　它的“宙”中有一項是硬盤空間，如果硬盤空間不足，那么安裝也是要失敗的。
　　所以，我們在做軟件的動態測試時，要把測試中的“宇”和“宙”想周全。
　　那么，怎樣才能把“宇”和“宙”想周全呢？

軟件測試的生命之圖
 
　　如果把軟件從啟動到關閉看作是一次生命的話，那么軟件的生命會是一張非常美麗的生命之圖——這張圖的起點是軟件的Start，然后每一步你都有一個或者若干選擇，從而讓用戶可以有多個達到下一步的通路，這些通路有的是可逆的，有的是單行的，有些是可跳過的……總之，我們最后會達到軟件生命的另一端——關閉。
　　雖然這是一個“圖”數據結構，但是對每個通路的遍歷卻是一條線（我是說線性的步驟），其中包含一些可以回溯的步驟。而每條線又是由有限個線段構成的。
每條線段由兩個端點和一條連線構成。兩個端點，一個是起點（我稱它為“起點場景”），一個是終點（我稱它為“終點場景”），中間的連線是從起點到終點的“動作”。（目前CSDN沒法上傳圖片，過幾天我補上圖）
　　那么有個問題：這條小線段有幾種走法？OK，讓我們來分析一下——
1.         起點à正確操作à終點。（基線測試）
2.         起點à錯誤操作à終點。
3.         起點à正確操作à終點à正確操作à起點。
4.         起點à錯誤操作à終點à正確操作à起點。
5.         起點à正確操作à終點à錯誤操作à起點。
6.         起點à錯誤操作à終點à錯誤操作à起點。
7.         起點à部分正確操作à放棄à起點。
8.         起點à部分錯誤操作à放棄à起點。

　　別忘記還有“宇”的問題，操作的上一步、下一步組合起來會如何？如果這一線段之前的“宇”都是正確的，那么這樣的測試是常規的。如果此前的“宇”已經在某步出了問題（我稱之為“錯誤傳遞”）那這對軟件的質量就是考驗了：我認為，凡是能在“宇”中傳遞下來的數據，都是正確的；如果有錯誤被在“宇”中傳遞，那么這就是軟件的缺陷。有了這一點，情況似乎簡單多了——我們只需要檢查這幾項就足夠了：
1.         起點狀態的正確性。
2.         操作輸入的正確性（小到簡單的鼠標點擊，大到多項數據的組合輸入，邊界檢驗，默認值等）。
3.         終點的正確性（如果有錯誤，軟件是否通過報錯而阻止錯誤在“宇”向下中傳遞）。
4.         可返回性。
5.         返回操作的輸入。
6.         返回起點后狀態正確性的檢查。


 

原文轉自：http://www.kjueaiud.com