前面兩章主要籠統地從軟體構造的角度回答了什麼是「高質量的軟體」以及從三個維度（階段、動態、構造物件層次）刻畫軟體，並且闡述了軟體構造的基本流程。對於本章所要學習的抽象資料型別（adt）和物件導向程式設計（oop），將是更為具體的學習。在本章的第一節資料型別與型別檢驗的學習後，我對於資料型別檢測的方式有了初步的了解，下面**一下在學習了本講以及結合先前對測試的學習收穫。
一、靜態檢查和動態檢查
一種語言能夠提供的自動檢查方式大致分為三種：即靜態檢查（static checking)、動態檢查（dynamic checking)以及及其少見的不做檢查。
靜態檢查發生在**編譯的過程中，一般出現的bug多為一些不易發現卻又相對容易修改的編譯錯誤：例如語法錯誤、類名/函式名錯誤、引數數目錯誤、引數型別錯誤、返回值型別錯誤等等，一般這種錯誤僅僅依靠ide就可完成檢測並修改。動態檢查則不同，它發生在**執行時，主要針對的是那些對於程式正常執行存在威脅的極端資料輸入、輸出及呼叫等：如超出規定範圍的引數值、返回值非法、陣列越界、出現空指標等等情況。
由此可以看出兩種檢查的側重點不同，靜態檢查強調的是對於資料型別結構的一致與準確，對於實際執行程式時使用的數值不做要求，而動態檢測則對程式的輸入輸出以及其他所有的數值負責。基於盡早發現bug為上的測試心理，由靜態檢查發現bug對於程式的改進似乎更有益。（當然，兩種檢查方式都是必要的）
二、動態測試具體實施的步驟
根據上文，我們已經知道，靜態測試可以由開發工具自動完成，那麼通過執行來檢驗軟體執行結果正確性的動態檢查又具體是如何實施的呢？這裡就聯絡到了先前學過的關於測試的知識。
動態檢查由動態測試來實現，大體分為五個步驟：單元測試、整合測試、系統測試、驗收測試以及回歸測試。
⚪單元測試
單元測試是對軟體中的基本組成單位進行測試，其目的是檢驗軟體基本組成單位的正確性。顯然該測試需要設計測試用例者清楚地知曉**與軟體執行的原理與工作實現，因此這一部分為白盒測試，這也意味著測試用例將從程式的實現邏輯著手，力求覆蓋面。
⚪整合測試
整合測試主要關心軟體的各單位之間的介面匹配，通常被分成為組裝測試和確認測試。前者可以看作是單元測試的延續，將單體正確的單元依照設計要求組裝為系統進行測試，以此來發現一些單元呼應上可能存在的問題。後者則是對於前者結果的檢驗，力求盡可能排除錯誤。由於要兼顧**設計結構以及客戶需求實現，因此整合測試應為黑盒測試與白盒測試兼具。
⚪系統測試
系統測試是對已經整合好的軟體系統進行徹底的測試，主要比對軟體的輸入輸出與規約之間是否存在差異。由於系統已經封裝完成，此測試為黑盒測試，不關心**的實現方法，而僅對軟體對於規約的實現與完備程度進行全面檢查。
⚪驗收測試
驗收測試是軟體投入使用前的最後測試，一般採用顧客試用等方式進行，為黑盒測試。使用者對於自己的實際樣例使用軟體進行處理時即對軟體進行測試。
⚪回歸測試
經過了如此多輪的測試，在投入使用後若軟體還是出現了問題，那麼就會用到回歸測試，這也被稱為軟體維護階段，常見的客戶投訴的反饋就屬於這一階段。
三、總結
對於本講的檢測發現bug的時機的學習，我對於先前所學的測試及測試用例的知識有了不一樣的理解，前後串連的學習更為重要。軟體在其生命週期中經理了無數次的重寫，更新，測試，依然會出現各種各樣的問題，這也印證了盡早發現錯誤與問題的重要性。
Pytorch學習記錄（二） 關於Gradient
在bp的時候，pytorch是將variable的梯度放在variable物件中的，我們隨時都可以使用variable.grad得到對應variable的grad。剛建立variable的時候，它的grad屬性是初始化為0.0的。import torch from torch.autograd im...
GIT 學習筆記（二） 關於修改
git checkout file可以丟棄工作區的修改 git reset head可以把暫存區修改撤銷掉 unstage 重新放回工作區 運用版本回退的方法 git log可以檢視提交歷史，以便確定要回退到哪個版本,再使用git reset hard commit id回退到想要的版本 用rm命令...
Linux學習（二）關於檔案基本操作
兩層規範 1 下面各個目錄存放什麼檔案資料？etc 存設定檔案 bin sbin 存可執行檔案 2 針對 usr var子目錄定義 var log usr share 2 fhs標準文件 3 目錄路徑 cd 切換目錄 表示當前目錄 上一級目錄 ls a 檢視隱藏檔案 上一次所在目錄 當前使用者hom...