軟件工程實現階段

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

編碼：

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. 分別測試法：標記已知錯誤的代碼，與未標記代碼的比例