目錄
測試基礎知識
測試原則
動態測試
靜態測試
測試策略
測試階段
測試用例設計
黑盒測試用例設計
白盒測試用例設計
McCabe度量法
魯棒性測試
缺陷探測率(Defect Detection Percentage,DDP)
調試
系統維護基礎
系統轉換
系統維護指標
軟件容錯技術
嵌入式安全關鍵系統
項目管理
進度(時間)管理
質量管理
配置管理
風險管理
測試基礎知識
測試原則
系統測試原則包括如下幾項：
(1)軟件測試最根本的目的是發現軟件的錯誤。
(2)應盡早并不斷地進行測試。
(3)測試工作應該避免由原開發軟件的人或小組承擔。
(4)在設計測試方案時，不僅要確定輸入數據，而且要根據系統功能確定預期的輸出結果。
(5)既包含有效、合理的測試用例，也包含不合理、失效的用例。
(6)檢驗程序是否做了該做的事，且是否做了不該做的事。
(7)嚴格按照測試計劃進行。
(8)妥善保存測試計劃和測試用例。
(9)測試用例可以重復使用或追加測試。
動態測試
動態測試也稱動態分析，主要特征是計算機必須真正運行被測試的程序，通過輸入測試用例，對其運行情況進行分析，判斷期望結果和實際結果是否一致。動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等。在動態分析中，通過最大資源條件進行系統的壓力測試，以判斷系統的實際承受能力，在通信比較復雜的系統中尤為重要。
黑盒測試法：功能性測試，不了解軟件代碼結構，根據功能設計用例，測試軟件功能。
白盒測試法：結構性測試，明確代碼流程，根據代碼邏輯設計用例，進行用例覆蓋。
灰盒測試法：既有黑盒，也有白盒。
靜態測試
靜態測試也稱靜態分析，主要特征是在用計算機測試源程序時，計算機并不真正運行被測試的程序。靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行。
桌前檢查：在程序編譯后，單元測試前，程序員檢查自己編寫的程序。
代碼審查：由若干個程序員和測試人員組成評審小組，通過召開程序評審會來進行審查。
代碼走查：也是采用開會來對代碼進行審查，但并非簡單的檢查代碼，而是由測試人員提供測試用例，讓程序員扮演計算機的角色，手動運行測試用例，檢查代碼邏輯。
測試策略
自底向上：從最底層模塊開始測試，需要編寫驅動程序，而后開始逐一合并模塊，最終完成整個系統的測試。優點是較早地驗證了底層模塊。
自頂向下：先測試整個系統，需要編寫樁程序，而后逐步向下直至最后測試最底層模塊。優點是較早地驗證了系統的主要控制點和判斷點。
三明治：既有自底向上也有自頂向下的測試方法，兼有二者的優點，缺點是測試工作量大。
測試階段
單元測試：對單個模塊進行測試，由程序員自己測試模塊內部的接口、信息、功能，測試依據是軟件詳細說明書。在單元測試中，驅動模塊(上層)用來調用被測模塊，自頂向下的單元測試中不需要另外編寫驅動模塊。樁模塊(底層)用來模擬被測模塊所調用的子模塊。
集成測試：將模塊組合起來進行測試，分為一次性組裝(簡單，節約時間，發現錯誤少，只適合于小項目)和增量式組裝(能夠發現更多錯誤，耗時長，又可分為：自頂向下、自底向上、混合式)。
確認測試：對已完成的軟件進行功能上的測試，分為內部確認測試(無用戶情況)、Alpha測試(用戶在開發環境下進行測試)、Beta測試(用戶在實際使用時進行的測試)、驗收測試(用戶根據SRS對項目進行驗收)。
系統測試：對軟件進行性能測試，主要測試三個方面，即負載測試(在極限情況下，系統各項性能指標)、強度測試(系統資源特別低的情況下)、容量測試(并發測試，系統可以處理的同時在線的最大用戶數量)。其他還有可靠性等性能測試，系統測試采用的是黑盒測試方法。
回歸測試：軟件修改錯誤或變更后，進行回歸測試以驗證之前正確的代碼是否引入了錯誤。
測試用例設計
黑盒測試用例設計
將程序看做一個黑盒子，只知道輸入輸出，不知道內部代碼，由此設計出測試用例，分為下面幾類。
等價類劃分：把所有的數據按照某種特性進行歸類，而后在每類的數據里選取一個即可。等價類測試用例的設計原則為設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。
邊界值劃分：將每類的邊界值作為測試用例，邊界值一般為范圍的兩端值以及在此范圍之外的與此范圍間隔最小的兩個值，如年齡范圍為0～150,邊界值為(0,150,-1,151)四個。
錯誤推測：沒有固定的方法，憑經驗而言，來推測有可能產生問題的地方，作為測試用例進行測試。
因果圖：由一個結果來反推原因的方法，具體結果具體分析，沒有固定方法。
白盒測試用例設計
知道程序的代碼邏輯，按照程序的代碼語句來設計覆蓋代碼分支的測試用例，覆蓋級別從低至高分類如下。
語句覆蓋：邏輯代碼中的所有語句都要被執行一遍，覆蓋層級最低，因為執行了所有的語句，不代表執行了所有的條件判斷。
判定覆蓋：邏輯代碼中的所有判斷語句的條件的真假分支都要覆蓋一次。
條件覆蓋：對于代碼中的一個條件，可能是組合的，如a>0&&b<0,判定覆蓋只針對此組合條件的真假分支做兩個測試用例，而條件覆蓋是對每個獨立的條件都要做真假分支的測試用例，共可有四個測試用例，層級更高。注意區別條件覆蓋和判定覆蓋。條件覆蓋是針對每個條件都要真假覆蓋；判定覆蓋是只針對一個條件判斷語句。
MC/DC(判定/條件)覆蓋率指在一個程序中每一種輸入輸出至少應出現一次，在程序中的每一個條件必須產生所有可能的輸出結果至少一次，并且每個判定中的每個條件必須能夠獨立影響一個判定的輸出，即在其他條件不變的前提下僅改變這個條件的值，而使判定結果改變。
路徑覆蓋：邏輯代碼中的所有可行路徑都覆蓋了，覆蓋層級最高。
McCabe度量法
McCabe度量法又稱為圈復雜度，有以下三種方法計算圈復雜度。
(1)沒有流程圖的算法。基數為1,碰到以下項加1:
1)分支數(如if、for、while和do while);switch中的case語句數。
2)如果條件是兩個復合條件，則加2,否則加1。
(2)給定流程圖G的圈復雜度V(G),定義為V(G)=E-N+2,E是流圖中邊的數量，N是流圖中結點的數量。
(3)給定流程圖G的圈復雜度V(G),定義為V(G)=P+1,P是流程圖G中判定結點的數量。
魯棒性測試
魯棒是Robust的音譯，也就是健壯或強壯的意思。它是在異常和危險情況下系統生存的關鍵。比如說，計算機軟件在輸入錯誤、磁盤故障、網絡過載或有意攻擊情況下，不死機、不崩潰，就是該軟件的魯棒性。所謂“魯棒性”,是指控制系統在一定(結構、大小)的參數攝動下，維持其他某些性能的特性。魯棒測試是對各個模塊的功能和系統進行容錯性的測試。
缺陷探測率(Defect Detection Percentage,DDP)
DDP=Bugs(tester)/[Bugs(tester)+Bugs(customer)]
其中，Bugs(tester)為軟件開發方測試者發現的Bugs數目；Bugs(customer)為客戶方發現并反饋技術支持人員進行修復的Bugs數目。
DDP越高，說明測試者發現的Bugs數目越多，發布后客戶發現的Bugs就越少，降低了外部故障不一致成本，達到了節約總成本的目的，可獲得較高的測試投資回報率(Return on Investment,ROI)。
調試
測試是發現錯誤，調試是找出錯誤的代碼和原因。調試需要確定錯誤的準確位置；確定問題的原因并設法改正；改正后要進行回歸測試。
調試的方法如下。
(1)蠻力法：又稱為窮舉法或枚舉法，窮舉出所有可能的方法一一嘗試。
(2)回溯法：又稱為試探法，按選優條件向前搜索，以達到目標，當發現原先選擇并不優或達不到目標時，就退回一步重新選擇，這種走不通就退回再走的技術為回溯法。
(3)演繹法：是由一般到特殊的推理方法，與“歸納法”相反，從一般性的前提出發。得出具體陳述或個別結論的過程。
(4)歸納法：是由特殊到一般的推理方法，從測試所暴露的問題出發，收集所有正確或不正確的數據，分析它們之間的關系，提出假想的錯誤原因，用這些數據來證明或反駁，從而查出錯誤所在。
系統維護基礎
系統轉換
系統轉換是指新系統開發完畢、投入運行，取代現有系統的過程，需要考慮多方面的問題，以實現與老系統的交接，有以下三種轉換計劃：
(1)直接轉換：現有系統被新系統直接取代了，風險很大，適用于新系統不復雜，或者現有系統已經不能使用的情況。優點是節省成本。
(2)并行轉換：新系統和老系統并行工作一段時間，新系統經過試運行后再取代，若新系統在試運行過程中有問題，也不影響現有系統的運行，風險極小，在試運行過程中還可以比較新老系統的性能，適用于大型系統。缺點是耗費人力和時間資源，難以控制兩個系統間的數據轉換。
(3)分段轉換：分期分批逐步轉換，是直接和并行轉換的集合，將大型系統分為多個子系統，依次試運行每個子系統，成熟一個子系統，就轉換一個子系統。同樣適用于大型項目，只是更耗時，而且現有系統和新系統間混合使用，需要協調好接口等問題。
系統維護指標
系統可維護性的評價指標包含以下四種。
(1)易測試性：指為確認經修改軟件所需努力有關的軟件屬性。
(2)易分析性：指為診斷缺陷或失效原因，或為判定待修改的部分所需努力有關的軟件屬性。
(3)易改變性：指與進行修改、排錯或適應環境變換所需努力有關的軟件屬性。
(4)穩定性：指與修改造成未預料效果的風險有關的軟件屬性。
軟件維護類型包含以下四種
(1)正確性維護：發現了bug而進行的修改。
(2)適應性維護：由于外部環境發生了改變，被動進行的對軟件的修改和升級。
(3)完善性維護：基于用戶主動對軟件提出更多的需求，修改軟件，增加更多的功能，使其比之前的軟件功能更好、性能更高，更加完善。
(4)預防性維護：對未來可能發生的bug進行預防性的修改。
軟件容錯技術
容錯就是軟件遇到錯誤的處理能力，實現容錯的手段主要是冗余，包括下面四種冗余技術。
(1)結構冗余：分為靜態、動態、混合冗余三種，當錯誤發生時對錯誤進行備份處理。
(2)信息冗余：為檢錯和糾錯在數據中加上一段額外的信息，例如校驗碼原理。
(3)時間冗余：遇到錯誤時重復執行，例如回滾，重復執行還有錯，則轉入錯誤處理邏輯。
(4)冗余附加技術：冗余附加技術是指為實現結構、信息和時間冗余技術所需的資源和技術，包括程序、指令、數據、存放和調動它們的空間和通道等。在屏蔽硬件錯誤的容錯技術中，冗余附加技術包括關鍵程序和數據的冗余及調用；檢測、表決、切換、重構和復算的實現。在屏蔽軟件錯誤的容錯技術中，冗余附加技術包括冗余備份程序的存儲及調用；實現錯誤檢測和錯誤恢復的程序；實現容錯軟件所需的固化程序。
容錯技術可以提高計算機系統的可靠性，利用元件冗余保證在局部故障情況下系統還可工作，其中帶有熱備份的系統稱為雙重系統。雙重系統中，兩個子系統同時同步運行，當聯機子系統出錯時，由備份子系統接替。
計算機系統容錯技術主要研究系統對故障的檢測、定位、重構和恢復等。典型的容錯結構有兩種，即單通道計算機加備份計算機結構和多通道比較監控系統結構。
從硬件余度設計角度出發，系統通常采用相似余度或非相似余度實現系統容錯，從軟件設計角度出發，實現容錯常用的有恢復塊技術和N版本技術等。
嵌入式安全關鍵系統
安全關鍵系統是指其不正確的功能或失效會導致人員傷亡、財產損失等嚴重后果的計算機系統。可見，由于嵌入式安全關鍵系統失效的后果非常嚴重，所以，安全關鍵系統有一條原則：任何情況下決不放棄!這要求不僅對符合規范要求的外部狀態和輸入有正確的處理，而且要求在不符合規范要求的情況，也能適當處理，讓系統處于安全的狀態。
關于健壯性，是指存在意外的擾動情況下系統保持可接受水平的服務的能力。即，健壯性是關于系統在意外狀態下的行為，只有當系統偏離其規范時才可看出它的健壯性或者脆弱性。
項目管理
進度(時間)管理
(1)關鍵路徑-雙代號圖(PERT圖)。類似于前趨圖，是有向圖，反映活動之間的依賴關系，有向邊上標注活動運行的時間，但無法反映活動之間的并行關系。關鍵路徑相關計算概念如下。
1)最早開始時間(ES):取所有前驅活動最早完成時間EF的最大值。
2)最早完成時間(EF):最早開始時間(ES)+活動本身時間(DU)。
3)關鍵路徑(項目總工期):項目中耗時最長的一條線路。
4)最晚完成時間(LF):取后續活動最晚開始時間的最小值。
5)最晚開始時間(LS):最晚完成(LF)-活動本身時間(DU)。
6)松弛時間(總時差):某活動的最晚開始時間-最早開始時間(或最晚完成時間-最早完成時間),也即該活動最多可以晚開始多少天。
7)虛路徑：在圖中用虛線表示的路徑，既不消耗資源也不消耗時間，僅用于表示依賴關系。
例：某軟件項目的活動圖如圖3-6-2所示。圖中頂點表示項目里程碑，連接頂點的邊表示包含的活動，則里程碑??????在關鍵路徑上，活動FG的松弛時間為???????
解析：關鍵路徑就是從起點到終點的最長路徑，為S-D-F-H-FI(將開始START簡寫為S,結束FINISH簡寫為FI),長度為48;松弛時間為FG的最晚開始時間-最早開始時間；從第0天開始計算，基于網絡計劃圖的前推法，活動FG的最早開始時間為第18,最遲開始時間為第38。因此，活動FG的松弛時間為20。具體表格法計算關鍵路徑的過程如下表所示。
(2)甘特(Gantt)圖。又稱為橫道圖，橫軸表示時間，縱軸表示活動，以時間順序表示活動，能反映活動間的并行關系，但無法反映活動之間的依賴關系，因此也難以清晰地確定關鍵任務和關鍵路徑。
質量管理
質量規劃：識別項目及其產品的質量要求和標準，并書面描述項目將如何達到這些要求和標準的過程。
質量保證：一般是每隔一定時間(例如，每個階段末)進行的，主要通過系統的質量審計(軟件評審)和過程分析來保證項目的質量。
質量控制：實時監控項目的具體結果，以判斷它們是否符合相關的質量標準，制訂有效方案，以消除產生質量問題的原因。
一定時間內質量控制的結果也是質量保證的質量審計對象。質量保證的成果又可以指導下一階段的質量工作，包括質量控制和質量改進。
配置管理
軟件配置管理是貫穿整個軟件生存周期的一項技術。它的主要功能是控制軟件生存周期中軟件的改變，減少各種改變所造成的影響，確保軟件產品的質量。
配置管理是指以技術和管理的手段來監督和指導開展如下工作的規程：
(1)識別和記錄配置項的物理特性和功能特性。
(2)管理和控制上述特性的變更。
(3)記錄和報告變更過程和相應的配置項狀態。
(4)驗證配置項是否與需求一致。
基線：軟件開發過程中特定的點，是項目生存期各開發階段末尾的特定點，又稱為里程碑，反應階段性成果。配置管理至少應有以下三個基線。
功能基線：是指在系統分析與軟件定義階段結束時，經過正式批準、簽字的系統規格說明書、項目任務書、合同書或協議書中所規定的對待開發軟件系統的規格說明。
分配基線：是指在需求分析階段結束時，經過正式評審和批準的需求規格說明。分配基線是最初批準的分配配置標識。
產品基線：是指在綜合測試階段結束時，經過正式評審和批堆的有關所開發的軟件產品的全部配置項的規格說明。產品基線是最終批準產品配置標識。
配置項：配置管理的基本單位。軟件開發過程中的所有文檔、代碼、工具都可作為配置項，主要包括六種類型：環境類(系統開發環境)、定義類(需求分析與系統定義階段)、設計類(設計階段)、編碼類(編碼及單元測試階段)、測試類(系統測試完成后的工作)、維護類(維護階段)。即產品組成部分的工作成果+項目管理和機構支撐過程域產生的文檔。
檢查點：指在規定的時間間隔內對項目進行檢查，比較實際與計劃之間的差異，并根據差異進行調整。
里程碑：里程碑就是在項目過程中管理者或其他利益相關方需要關注的項目狀態時間點。完成階段性工作的標志，不同類型的項目里程碑不同。
軟件配置項的版本控制，配置項有三個狀態：草稿、正式、修改，如下圖所示。
配置項規則如下：
處于草稿狀態的配置項的版本號格式為：0.YZ,其中YZ數字范圍為01～99。隨著草稿的不斷完善，YZ的取值應遞增。YZ的初值和增幅由開發者自己把握。
處于正式發布狀態的配置項的版本號格式為：X.Y。其中X為主版本號，取指范圍為1～9;Y為次版本號，取值范圍為1～9。配置項第一次正式發布時，版本號為1.0。
如果配置項的版本升級幅度比較小，一般只增大Y值，X值保持不變。只有當配置項版本升級幅度比較大時，才允許增大X值。
處于正在修改狀態的配置項的版本號格式為：X.YZ。在修改配置項時，一般只增大Z值，X.Y值保持不變。
配置庫：一般軟件項目開發過程采取開發庫、受控庫和產品庫的管理方法，且采取三庫物理隔離的策略。
開發庫存放項目確定的軟件配置項集合，以及項目組需要存放的其他文件或過程記錄。
受控庫存放在軟件開發過程中達到相對穩定、可以作為后續開發活動輸入的軟件工作產品(或稱為配置項)。軟件工作產品(配置項)通常分為文檔和代碼兩大類，文檔納入受控庫的條件通常規定為“通過評審且評審問題已歸零或變更驗證已通過，已完成文檔簽署”;代碼納入受控庫的條件通常規定為“通過了項目規定的測試或回歸測試，或通過了產品用戶認可”的代碼狀態。
產品庫存放作為軟件產品的受控庫中各階段基線或產品基線對應的文檔、源程序和可執行代碼。
風險管理
風險的分類有如下幾種。
(1)項目風險：威脅到項目計劃，如果項目風險發生，有可能拖延項目的進度和增加項目的成本。指預算、進度、人員、資源、利益相關者、需求等方面的潛在問題以及它們對軟件項目的影響。項目復雜度、規模及結構不確定性也屬于項目風險因素。
(2)技術風險：威脅到要開發軟件的質量和交付時間，如果技術風險發生，開發工作就變得很困難或者不可能，指設計、實現、接口、驗證和維護等方面的潛在問題。此外，規格說明的歧義性、技術的不確定性、技術陳舊以及“前沿”技術也是技術風險因素。
(3)商業風險：威脅到要開發軟件的生存能力，包括以下五種。
1)市場風險。開發了一個沒有人真正需要的優良產品或系統。
2)策略風險。開發的產品不再符合公司的整體商業策略。
3)銷售風險。開發了一個銷售部門不知道如何去銷售的產品。
4)管理風險。由于重點的轉移或人員的變動而失去了高級管理層的支持。
5)預算風險。沒有得到預算或人員的保證。
風險曝光度=風險發生的可能性×風險發生會帶來的損失。
