上文提到，靜者為測。讓我們想想軟件都在什么時候是“靜”的。
我們看一個自然的流程：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.k11sc111.com/
