初學程式設計，我們往往會根據給出的要求，直接向目標發起「衝擊」，但這樣直接的程式設計很有可能會導致各種各樣的問題——bug頻出但找不到問題所在，找到bug並修改後卻又引發了更多的bug……程式猿們很有可能在找bug-改bug的迴圈中苦苦掙扎，正所謂**五分鐘，bug兩小時。那如何才能改變這一狀況呢，測試優先的程式設計應運而生。
測試優先的程式設計的中心思想就是：將在寫程式時通過合適的測試，確保程式的每個組成部分的bug數量降到盡可能低，減少程式整體的bug數量，從而減少程式編寫完成後返工的難度和工作量，提高工作效率。
下面我們就來了解一下測試與測試優先的程式設計。
一、靜態測試與動態測試：
靜態測試是靜態地分析**的語法的正確性，而不實際地執行程式；動態測試是給定測試用例，讓程式按照給定的輸入進行執行，將得到的執行結果與期望的執行結果進行比較，得出是否通過測試，從而判斷編寫的**是否滿足程式設計者和使用者的需求。
注：測試與除錯不同，測試是通過執行程式來判斷程式是否有錯誤，而除錯則是發現程式的錯誤後通過執行程式來尋找錯誤到底出現在什麼地方。通常來說，除錯是測試後的步驟。
二、黑盒測試與白盒測試
黑盒測試，顧名思義，在這種測試中，程式是對於測試者來說處於乙個黑盒狀態，測試者只知道從輸入到輸出的結果，而不知道程式對輸入的處理過程，因此黑盒測試是對程式外部表現出來的行為的測試。測試者可以通過程式的規約，在程式編寫前就完成黑盒測試的編寫，從而可以為程式猿在編寫**時起到指導作用。
白盒測試，與黑盒測試相反，是對程式內部**結構的測試，是已經編寫出程式後，對程式內部實現細節的測試，在程式編寫前是無法進行編寫的。
三、**測試的難度
**測試難嗎？難也不難。寫測試**的過程遠沒有編寫程式本身困難，但難在如何使構建出的測試用例用最少的**覆蓋更多的情況，檢查出更多的錯誤。我們知道，程式的bug往往出在最不引人注意的地方，bug的出現往往不符合特定概率的分布，邊界點往往使bug發生的「重災區」。因此選取合適的測試用例非常關鍵，也是測試的難點所在。什麼樣的測試用例才可以稱之為合適呢？應當滿足下面幾個標準：①最可能發現錯誤；②不重不漏；③測試效率高；④簡單易懂但要測試全面。
四、測試優先的程式設計
1、測試優先的程式設計的過程：
①為函式或者方法寫規約，明確要寫的內容的行為特徵，對什麼樣的輸入應該有什麼樣的輸出。
②編寫符合規約的測試用例，確保全面。
③編寫程式，執行測試，發現問題後改寫程式，在進行上述過程，直到通過用例。
通過了設計良好的測試用例的程式，我們幾乎可以保證，它是合格的了！
2、單元測試：針對軟體的最小單元模型開展測試，隔離各個模組，從而容易定位錯誤進行除錯。
五、選取測試用例
上文提到過，設計測試用例是測試的難點所在，那麼應該如何對測試用例進行設計呢？
我們可以將乙個程式看作乙個從輸入到輸出的對映，那麼我們可以將輸入域劃分為不同的等價類，其中程式對同乙個等價類中的輸入的行為是相同的，因此只要將輸入域劃分為不同的等價類，在每乙個等價類中選取乙個「代表」進行測試，就可以不重複地對程式的不同行為進行測試，減少測試量。同時由於輸入域的邊界是「事故高發區」，值得我們的格外照顧，應當對其進行分析。
當有多個維度的輸入時，應當對不同的可能進行組合，每個組合至少要進行一次測試，從而覆蓋到每一種可能的情況。
以上是黑盒測試的測試思路，其主要考慮的是覆蓋不同的輸入可能，而白盒測試主要的要求測試**盡可能地覆蓋程式所有的**。
以上是我對測試這一技術的理解，以後會寫一篇文章專門介紹一下junit的基本用法。
軟體構造課程心得（5）
最近做了lab3，對介面和繼承又有了種種新的認知，在這裡想和大家分享。首先是介面可以接收該介面的各種子類，由此來完成多個不同類的統一接收，如圖 這是乙個state介面 而下圖 以createdstate為例 是這個state介面的各種子類，createdstate,givedstate,blocke...
軟體構造課程心得（8）
在完成lab4之後，我對日誌有了很多自己的理解，這裡與大家分享一下。日誌的建立其實很簡單 首先定義乙個日誌類 然後輸出任意的字串，只需要這兩步操作我們就生成了日誌 但是，我們的日誌不能僅僅輸出，我們也要用txt檔案將每個日誌的詳細資訊記錄下來，所以我們就要進行下面的操作 首先建立filehandle...
軟體測試黑盒測試實驗心得 如何學習軟體測試
1.什麼是軟體測試 軟體測試是在測試中識別軟體產品和服務的準確性和質量的過程。顯然，它的誕生是為了驗證產品是否滿足客戶的特定先決條件 需求和需求。在一天的工作結束前，確定特定的最終目標並測試執行乙個框架或應用程式，以指出其錯誤 錯誤或缺陷。測試的職責是找到bug並指出問題問題，並給dev 開發人員 ...