通常把編碼和測試統稱為實現

編碼：

1. 選擇程式設計語言

   1. 選擇標準：

      1. 系統使用者要求

      2. 可以使用的編譯程式

      3. 可以得到的軟體工具

      4. 工程規模

      5. 程式設計師的只是

      6. 軟體可移植性要求

      7. 軟體的應用領域
         

2. 編碼風格

   1. 應該遵循的標準：

      1. 程式內部的文件：包括恰當的識別符號，適當的註解和程式的視覺組織（通常在每個模組開始有一段序言性註解，簡要描述模組的功能，主要演算法，介面特點，重要資料以及開發簡史）

      2. 資料說明：

      3. 語句構造：每個語句應該簡單直接，適當拆分語句，避免複雜田間測試，避免大量迴圈巢狀條件巢狀，適當用括號

      4. 輸入輸出：

         1. 對所有輸入資料都進行檢驗

         2. 檢查輸入項重要組合的合法性

         3. 保持輸入格式簡單

         4. 使用資料結束標記，不要要求使用者指定資料的數目

         5. 明確提示互動式輸入的要求，詳細說明可用的選擇或邊界值

         6. 當程式設計語言對格式有嚴格要求是，應該保持輸入格式一致

         7. 設計良好的輸入報表

         8. 給所有輸出資料加標誌

      5. 效率：主要指處理機時間和儲存器容量兩個方面，屬於效能要求

         1. 程式執行時間

         2. 儲存器效率

         3. 輸入輸出效率

軟體測試基礎：

測試的根本目的：儘可能多地發現並排除軟體中潛藏的錯誤，最終把一個高質量的軟體系統交給使用者使用。

軟體測試的目標定義：

1. 測試時為了發現程式中的錯誤而執行程式的過程

2. 好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案

3. 成功的測試是發現了至今為止尚未發現的錯誤的測試

測試準則：

1. 所有測試都應該能追述到使用者的需求

2. 應該遠在測試開始之前就指定測試計劃。實際上在完成需求模型之後就可以著手製定測試計劃，在完成詳細設計之後，在編碼前就可以開始設計詳細的測試方案。

3. 把Pareto原理應用到軟體測試中。Pareto原理：測試發現的錯誤80%由程式中20%的模組造成

4. 應該從小規模測試，逐步進行大規模測試

5. 窮舉測試是不可能的。限於人力物力，把程式所有流程分支檢查測試是不可能的

6. 應該由第三方承擔測試工作。通常開發人員主要承擔模組測試

測試方法：

• 黑盒測試（功能測試）：完全不考慮程式內部結構和處理過程，只檢查程式功能是否能夠按照規格說明書的規定正常使用

• 白盒測試（結構測試）：按照程式內部的邏輯測試程式，檢測程式中的主要執行通路是否都能按預定的要求正確工作
  

測試步驟：

1. 模組測試

2. 子系統測試

3. 系統測試

4. 驗收測試：測試過程與系統測試基本類似，但需要使用者積極參與，使用實際資料測試

5. 平行執行：關係重大的軟體產品驗收之後往往並不立即投入生產性執行，而是經過一段平行執行時間的考驗，與舊系統同時執行，比較兩個系統處理結果

   1. 平行執行優點：

      1. 可以在準生產環境中執行新系統而又不冒風險

      2. 使用者能有一段熟悉新系統的時間

      3. 可以驗證使用者指南和使用手冊之類的文件

      4. 能夠以準生產模式對新系統進行全負荷測試，可以用測試結果驗證效能指標

測試階段的資訊流：

1. 軟體配置：包括需求說明書，設計說明書和源程式清單

2. 測試配置：包括測試計劃和測試方案。實際上測試配置是軟體配置的一個子集，最終交出的軟體配置應該包括上述測試配置以及測試的實際結果和除錯記錄

   1. 測試方案：包含測試用例，每組輸入資料和預定要檢驗的功能，以及每組輸入資料預期應該得到的正確輸出。

在對測試結果進行收集和評價的時候，軟體可靠性所達到的定性指標已經有所顯現。如果經常出現要求修改設計的嚴重錯誤，那麼軟體的質量和可靠性是值得懷疑的，應該進一步仔細測試。反之若極少錯誤，則應該考慮測試配置是否不足。

單元測試：主要使用白盒測試技術

1. 測試重點：

   1. 模組介面

   2. 區域性資料結構

   3. 重要的執行桐廬

   4. 出錯處理通路

   5. 邊界條件
      

2. 程式碼審查：可以編寫者本人，也可以由審查小組進行

   1. 審查小組最好由4人組成：

      1. 組長，很有能力的程式設計師

      2. 設計者

      3. 編寫者

      4. 測試者
         

3. 計算機測試（自動化測試）：把以人為驅動的測試行為轉化為機器執行的一種過程。

整合測試：測試和組裝軟體的系統化技術

1. 非漸增式測試：分別測試模組，再把所有模組按設計要求放在一起結合成所要的程式

2. 漸增式測試（目前普遍採用）：把下一個要測試的模組同已經測試好的模組結合進行測試，依次遞增

   1. 自頂向下整合

   2. 自底向下整合

確認測試（驗收測試）：驗證軟體有效性，必須有使用者積極參與，或以使用者為主進行

1. 確認測試範圍

2. 軟體配置複查：保證軟體配置的所有成分都齊全，質量符合要求，文件與程式完全一致，具有完成軟體維護所必須的細節，而且已經編好目錄

3. Alpha和Beta測試：Alpha測試指使用者在開發者場所，經開發者指導下的測試，Beta則是使用者場所下進行的測試
   

白盒測試技術：

1. 邏輯覆蓋

   1. 語句覆蓋

   2. 判定覆蓋

   3. 條件覆蓋

   4. 判定/條件覆蓋

   5. 條件組合覆蓋：選取足夠多地測試資料，使得每個判定表示式中條件的各種可能組合都至少出現一次

   6. 點覆蓋
      

   7. 邊覆蓋

   8. 路徑覆蓋

2. 控制結構測試

   1. 基本路徑測試

      1. 根據過程設計結果畫出相應的流圖

      2. 計算流圖的環形複雜度

      3. 確定線性獨立路徑的基本集合

      4. 設計可強制執行基本集合中每條路徑的測試用例

   2. 條件測試

   3. 迴圈測試

      1. 簡單迴圈：

         1. 跳過迴圈

         2. 只通過迴圈一次

         3. 通過迴圈兩次

         4. 通過迴圈m次，其中m<n-1    

         5. 通過迴圈n-1,n,n+1次

      2. 巢狀迴圈

      3. 串接迴圈
         

黑盒測試技術：著重測試軟體功能，白盒測試在測試過程的早期階段進行，而黑盒測試主要用於測試過程的後期

黑盒測試力圖發現如下型別錯誤：

1. 功能不正確或遺漏了功能

2. 介面錯誤

3. 資料結構錯誤或外部資料庫訪問錯誤

4. 效能錯誤

5. 初始化和終止錯誤 

設計黑盒測試方案應該考慮：

1. 怎樣測試功能的有效性

2. 哪些型別的輸入可以構成好的測試用例

3. 系統是否對特定的輸入值特別敏感

4. 怎樣劃定資料庫的邊界

5. 系統能夠承受什麼樣的資料率和資料量

6. 資料的特定組合對系統執行產生什麼影響

黑盒測試技術：

1. 等價劃分：把程式的輸入域劃分成若干個資料類，據此匯出測試用例。一個理想的測試用例能獨自發現一類錯誤

2. 邊界值分析：選取測試資料應該剛好等於，剛剛小於，剛剛大於邊界值

3. 錯誤推測

經驗表明，在一段程式中已經發現的錯誤數目往往和尚未發現的錯誤數成正比。

除錯：目標都是尋找錯誤原因並改正錯誤

軟體錯誤的特徵：

1. 症狀與產生症狀的原因可能在程式中相距甚遠，緊耦合的程式更是如此

2. 當改正了另一個錯誤之後，症狀可能暫時消失

3. 症狀可能不是由於錯誤引起的，而是一些精度問題

4. 症狀可能是由不易跟蹤的人為錯誤引起

5. 症狀可能是由定時問題導致，而不是由處理問題引起

6. 症狀可能時有時無，這種情況在嵌入式系統中比較常見

7. 症狀可能是多執行緒引起

除錯途徑：

1. 蠻幹法

2. 回溯法

3. 原因排除法：

   1. 對分查詢法：

   2. 歸納法：從個別現象推斷出一般性解餓論

   3. 演繹法：設想所有可能的出錯原因，然後用測試來排除精化
      

一旦找到錯誤，在動手改正錯誤之前，工程師要考慮3個問題：

1. 是否同樣的錯誤也在程式其他位置出現

2. 修改之後，是否引入新錯誤，是什麼

3. 為防止今後出現類似的錯誤，應該作什麼

軟體可靠性：程式在給定的時間間隔內，按照規格說明書的規定成功地執行的概率

軟體的可用性：程式在給定的時間點，按照規格說明書的規定，成功執行的概率

估算平均無故障時間：平均無故障時間與單位長度程式中的剩餘錯誤數成反比 MTTF=1  /  K（單位長度程式中的剩餘錯誤數）     K為常熟，典型值為200

根據對軟體平均無故障時間的要求，估計需要改正多少個錯誤之後，測試工作才能結束

估計錯誤總數方法：

1. 植入錯誤法：植入錯誤引發錯誤與原有錯誤引發錯誤的比例

2. 分別測試法：標記已知錯誤的程式碼，與未標記程式碼的比例
   

通常把編碼和測試統稱為實現

編碼：

1. 選擇程式設計語言

   1. 選擇標準：

      1. 系統使用者要求

      2. 可以使用的編譯程式

      3. 可以得到的軟體工具

      4. 工程規模

      5. 程式設計師的只是

      6. 軟體可移植性要求

      7. 軟體的應用領域
         

2. 編碼風格

   1. 應該遵循的標準：

      1. 程式內部的文件：包括恰當的識別符號，適當的註解和程式的視覺組織（通常在每個模組開始有一段序言性註解，簡要描述模組的功能，主要演算法，介面特點，重要資料以及開發簡史）

      2. 資料說明：

      3. 語句構造：每個語句應該簡單直接，適當拆分語句，避免複雜田間測試，避免大量迴圈巢狀條件巢狀，適當用括號

      4. 輸入輸出：

         1. 對所有輸入資料都進行檢驗

         2. 檢查輸入項重要組合的合法性

         3. 保持輸入格式簡單

         4. 使用資料結束標記，不要要求使用者指定資料的數目

         5. 明確提示互動式輸入的要求，詳細說明可用的選擇或邊界值

         6. 當程式設計語言對格式有嚴格要求是，應該保持輸入格式一致

         7. 設計良好的輸入報表

         8. 給所有輸出資料加標誌

      5. 效率：主要指處理機時間和儲存器容量兩個方面，屬於效能要求

         1. 程式執行時間

         2. 儲存器效率

         3. 輸入輸出效率

軟體測試基礎：

測試的根本目的：儘可能多地發現並排除軟體中潛藏的錯誤，最終把一個高質量的軟體系統交給使用者使用。

軟體測試的目標定義：

1. 測試時為了發現程式中的錯誤而執行程式的過程

2. 好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案

3. 成功的測試是發現了至今為止尚未發現的錯誤的測試

測試準則：

1. 所有測試都應該能追述到使用者的需求

2. 應該遠在測試開始之前就指定測試計劃。實際上在完成需求模型之後就可以著手製定測試計劃，在完成詳細設計之後，在編碼前就可以開始設計詳細的測試方案。

3. 把Pareto原理應用到軟體測試中。Pareto原理：測試發現的錯誤80%由程式中20%的模組造成

4. 應該從小規模測試，逐步進行大規模測試

5. 窮舉測試是不可能的。限於人力物力，把程式所有流程分支檢查測試是不可能的

6. 應該由第三方承擔測試工作。通常開發人員主要承擔模組測試

測試方法：

• 黑盒測試（功能測試）：完全不考慮程式內部結構和處理過程，只檢查程式功能是否能夠按照規格說明書的規定正常使用

• 白盒測試（結構測試）：按照程式內部的邏輯測試程式，檢測程式中的主要執行通路是否都能按預定的要求正確工作
  

測試步驟：

1. 模組測試

2. 子系統測試

3. 系統測試

4. 驗收測試：測試過程與系統測試基本類似，但需要使用者積極參與，使用實際資料測試

5. 平行執行：關係重大的軟體產品驗收之後往往並不立即投入生產性執行，而是經過一段平行執行時間的考驗，與舊系統同時執行，比較兩個系統處理結果

   1. 平行執行優點：

      1. 可以在準生產環境中執行新系統而又不冒風險

      2. 使用者能有一段熟悉新系統的時間

      3. 可以驗證使用者指南和使用手冊之類的文件

      4. 能夠以準生產模式對新系統進行全負荷測試，可以用測試結果驗證效能指標

測試階段的資訊流：

1. 軟體配置：包括需求說明書，設計說明書和源程式清單

2. 測試配置：包括測試計劃和測試方案。實際上測試配置是軟體配置的一個子集，最終交出的軟體配置應該包括上述測試配置以及測試的實際結果和除錯記錄

   1. 測試方案：包含測試用例，每組輸入資料和預定要檢驗的功能，以及每組輸入資料預期應該得到的正確輸出。

在對測試結果進行收集和評價的時候，軟體可靠性所達到的定性指標已經有所顯現。如果經常出現要求修改設計的嚴重錯誤，那麼軟體的質量和可靠性是值得懷疑的，應該進一步仔細測試。反之若極少錯誤，則應該考慮測試配置是否不足。

單元測試：主要使用白盒測試技術

1. 測試重點：

   1. 模組介面

   2. 區域性資料結構

   3. 重要的執行桐廬

   4. 出錯處理通路

   5. 邊界條件
      

2. 程式碼審查：可以編寫者本人，也可以由審查小組進行

   1. 審查小組最好由4人組成：

      1. 組長，很有能力的程式設計師

      2. 設計者

      3. 編寫者

      4. 測試者
         

3. 計算機測試（自動化測試）：把以人為驅動的測試行為轉化為機器執行的一種過程。

整合測試：測試和組裝軟體的系統化技術

1. 非漸增式測試：分別測試模組，再把所有模組按設計要求放在一起結合成所要的程式

2. 漸增式測試（目前普遍採用）：把下一個要測試的模組同已經測試好的模組結合進行測試，依次遞增

   1. 自頂向下整合

   2. 自底向下整合

確認測試（驗收測試）：驗證軟體有效性，必須有使用者積極參與，或以使用者為主進行

1. 確認測試範圍

2. 軟體配置複查：保證軟體配置的所有成分都齊全，質量符合要求，文件與程式完全一致，具有完成軟體維護所必須的細節，而且已經編好目錄

3. Alpha和Beta測試：Alpha測試指使用者在開發者場所，經開發者指導下的測試，Beta則是使用者場所下進行的測試
   

白盒測試技術：

1. 邏輯覆蓋

   1. 語句覆蓋

   2. 判定覆蓋

   3. 條件覆蓋

   4. 判定/條件覆蓋

   5. 條件組合覆蓋：選取足夠多地測試資料，使得每個判定表示式中條件的各種可能組合都至少出現一次

   6. 點覆蓋
      

   7. 邊覆蓋

   8. 路徑覆蓋

2. 控制結構測試

   1. 基本路徑測試

      1. 根據過程設計結果畫出相應的流圖

      2. 計算流圖的環形複雜度

      3. 確定線性獨立路徑的基本集合

      4. 設計可強制執行基本集合中每條路徑的測試用例

   2. 條件測試

   3. 迴圈測試

      1. 簡單迴圈：

         1. 跳過迴圈

         2. 只通過迴圈一次

         3. 通過迴圈兩次

         4. 通過迴圈m次，其中m<n-1    

         5. 通過迴圈n-1,n,n+1次

      2. 巢狀迴圈

      3. 串接迴圈
         

黑盒測試技術：著重測試軟體功能，白盒測試在測試過程的早期階段進行，而黑盒測試主要用於測試過程的後期

黑盒測試力圖發現如下型別錯誤：

1. 功能不正確或遺漏了功能

2. 介面錯誤

3. 資料結構錯誤或外部資料庫訪問錯誤

4. 效能錯誤

5. 初始化和終止錯誤 

設計黑盒測試方案應該考慮：

1. 怎樣測試功能的有效性

2. 哪些型別的輸入可以構成好的測試用例

3. 系統是否對特定的輸入值特別敏感

4. 怎樣劃定資料庫的邊界

5. 系統能夠承受什麼樣的資料率和資料量

6. 資料的特定組合對系統執行產生什麼影響

黑盒測試技術：

1. 等價劃分：把程式的輸入域劃分成若干個資料類，據此匯出測試用例。一個理想的測試用例能獨自發現一類錯誤

2. 邊界值分析：選取測試資料應該剛好等於，剛剛小於，剛剛大於邊界值

3. 錯誤推測

經驗表明，在一段程式中已經發現的錯誤數目往往和尚未發現的錯誤數成正比。

除錯：目標都是尋找錯誤原因並改正錯誤

軟體錯誤的特徵：

1. 症狀與產生症狀的原因可能在程式中相距甚遠，緊耦合的程式更是如此

2. 當改正了另一個錯誤之後，症狀可能暫時消失

3. 症狀可能不是由於錯誤引起的，而是一些精度問題

4. 症狀可能是由不易跟蹤的人為錯誤引起

5. 症狀可能是由定時問題導致，而不是由處理問題引起

6. 症狀可能時有時無，這種情況在嵌入式系統中比較常見

7. 症狀可能是多執行緒引起

除錯途徑：

1. 蠻幹法

2. 回溯法

3. 原因排除法：

   1. 對分查詢法：

   2. 歸納法：從個別現象推斷出一般性解餓論

   3. 演繹法：設想所有可能的出錯原因，然後用測試來排除精化
      

一旦找到錯誤，在動手改正錯誤之前，工程師要考慮3個問題：

1. 是否同樣的錯誤也在程式其他位置出現

2. 修改之後，是否引入新錯誤，是什麼

3. 為防止今後出現類似的錯誤，應該作甚惡魔

軟體可靠性：程式在給定的時間間隔內，按照規格說明書的規定成功地執行的概率

軟體的可用性：程式在給定的時間點，按照規格說明書的規定，成功執行的概率

估算平均無故障時間：平均無故障時間與單位長度程式中的剩餘錯誤數成反比 MTTF=1  /  K（單位長度程式中的剩餘錯誤數）     K為常熟，典型值為200

根據對軟體平均無故障時間的要求，估計需要改正多少個錯誤之後，測試工作才能結束

估計錯誤總數方法：

1. 植入錯誤法：植入錯誤引發錯誤與原有錯誤引發錯誤的比例

2. 分別測試法：標記已知錯誤的程式碼，與未標記程式碼的比例