第一篇：軟件測試復習

軟件測試的定義:

軟件測試是為了發現錯誤而執行程序的過程”，明確提出了“尋找錯誤”是測試的目的。

使用人工或自動手段運行或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是弄清楚預期結果與實際結果之間的差別”。軟件測試是一種重要的軟件質量保證活動，包括“分析”軟件和“運行”軟件，是軟件質量保證的關鍵步驟。測試用例: 測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果；測試用例是執行測試的最小實體。為什么要設計測試用例：

1.在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。2.測試用例的使用令軟件測試的實施重點突出、目的明確。3.在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。4.功能模塊的通用化和復用化使軟件易于開發，而相對于功能模塊的測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升

軟件測試的對象: 需求規格說明 概要設計規格說明 詳細設計規格說明 源程序

軟件測試的目的（1）測試是程序的執行過程，目的在于發現錯誤；不能證明程序的正確性，除非僅處理有限種情況。2）檢查系統是否滿足需求也是測試的期望目標。（3）一個好的測試用例在于能發現還未曾發現的錯誤；一次成功的測試則是發現了至今未發現的錯誤的測試。

軟件測試模型: V模型、W模型、H模型、X模型

軟件缺陷的定義：最終產品同用戶的期望不一致。功能錯誤 功能遺漏 超出需求的部分

性能不符合要求 軟件測試人員認為軟件難以理解、不易使用，或者最終用戶認為該軟件使用效果不良。

軟件缺陷產生的原因:軟件產品說明書（需求）56% 編寫代碼7% 設計27% 其他10%

缺陷的管理:缺陷嚴重程度；嚴重、較大、較小、輕微 缺陷優先級；立即、排隊、不緊急缺陷狀態；提交、打開、拒絕、解決、關閉

黑盒測試法的概念

黑盒測試被稱為功能測試或數據驅動測試。在測試時，把被測程序視為一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下進行。

黑盒測試主要根據規格說明書設計測試用例，并不涉及程序內部構造和內部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例，檢查程序功能是否按照規格說明書的規定正常使用。

如何劃分等價類:

1)如果輸入條件規定了取值范圍或值的個數就可確定一個有效等價類和兩個無效等價類

(2)輸入條件規定了輸入值的集合,或是規定了“必須如何”的條件，則可確定一個有效等價類和一個無效等價類

(3)如果輸入條件是一個布爾量,則可以確立一個有效等價類和一個無效等價類。

(4)如果規定了輸入數據的一組值, 且程序要對每一個輸入值分別進行處理, 要對每一個規定的輸入值確立一個有效等價類,而對于這組值之外的所有值確立一個無效等價類。

(5)如果規定了輸入數據必須遵循的規則，可確定一個有效等價類和若干個無效等價類（從不同角度違反規則)。

（6）如已劃分的等價類各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類。

用等價類設計測試用例步驟

(1)劃分等價類，形成等價類表(2)設計一新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類，重復這一步驟，直到所有的有效等價類都被覆蓋為止；(3)設計一新測試用例，使其只覆蓋一個無效等價類，重復這一步驟直到所有無效等價類均被覆蓋；

等價類測試的分類: 單缺陷與多缺陷假設產生弱等價類與強等價類測試之分；是否進行無效數據的處理產生健壯與一般等價類測試之分；

等價類測試的分類：弱一般等價類測試 強一般等價類測試 弱健壯等價類測試 強健壯等價類測試

邊界值分析法:對輸入或輸出的邊界值進行測試的一種黑盒測試方法。

邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

邊界值測試方案分兩種方案:五點法： min、min+、nom、max-和max七點法： min-、min、min+、nom、max-和max、max+ 選擇測試用例的原則

(1)如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界值以及剛剛超過這個范圍邊界的值作為測試輸入數據。

(2)如果輸入條件規定了值的個數，則用最大個數、最小個數和比最大個數多1個、比最小個數少1個的數作為測試數據。

(3)根據程序規格說明的每個輸出條件，使用原則(1)。

(4)根據程序規格說明的每個輸出條件，使用原則(2)。

(5)如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合中的第一個和 最后一個元素作為測試用例。

(6)如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。

(7)分析程序規格說明，找出其它可能的邊界條件。

判定表,叫決策表,分析和表達多邏輯條件下執行不同操作的工具。

條件樁:出問題的所有條件;動作樁:可能采取的操作 條件項:列出條件樁的取值；動作項：列出條件項各種取值下應該采取的動作；規則：在判定表中貫穿條件項和動作項的一列就是一條規則；

判定表建立步驟①列出所有的條件樁和動作樁；②確定規則的個數；③填入條件項；④填入動作項，得到初始決策表；⑤簡化，合并相似規則（相同動作）。

因果圖法：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。因果圖基本符號(ppt34)

程序插樁技術：軟件動態測試中，程序插樁是一種基本的測試手段；借助于往被測程序中插入操作來實現測試目的方法，最簡單的插樁：在程序中插入打印語句printf(“…”)語句

基本路徑測試

通過分析程序控制流圖的環路的復雜性，導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次。獨立路徑：至少沿一條新的邊移動的路徑

單元測試：又稱模塊測試，是針對軟件設計的最小單位——程序模塊，進行正確性檢驗的測試工作，是代碼級的測試。基本單元本身不是一個獨立的程序，自己不能運行，要靠其它部分來調用和驅動。

驅動模塊：被測基本單元的主程序，它接收測試數據，并把數據傳送給被測單元，最后輸出實測結果。

樁模塊──存根模塊，用來代替被測基本單元調用的其他基本單元。

單元測試的內容：主要對模塊的五個基本特性進行評價(模塊接口 局部數據結構 邊界條件 重要的執行路徑 錯誤處理)單元測試策略: 自頂向下的單元測試 自底向上的單元測試 孤立單元測試

集成測試:叫組裝測試或聯合測試，集成測試遵循特定的策略和步驟將已經通過單元測試的各個軟件單元（或模塊）按照設計要求逐步集成為系統或子系統，并進行測試，以期望通過測試發現各軟件單元接口之間存在的問題，驗證程序和概要設計說明的一致性

集成測試對象:理論上凡是兩個單元（如函數單元）的組合測試都可以叫做集成測試。實際操作中，通常集成測試的對象為模塊級的集成和子系統間的集成，其中子系統集成測試稱為組件測試。

集成測試內容: 集成功能測試 接口測試 全局數據結構測試 資源測試 任務優先級沖突測試 性能和穩定性測試

集成測試方法: 基于功能分解的集成 非漸增式集成 漸增式集成;基于調用圖的集成有兩種：成對集成 相鄰集成 其他集成 客戶/服務器集成: 分層集成 高頻集成增量式集成測試兩種方法的比較

自頂向下增量式測試的主要優點在于它可以自然地做到逐步求精，一開始便能讓測試者看到系統的框架。它的主要缺點是需要提供被調用模擬子模塊，被調用模擬子模塊可能不能反映真實情況，因此測試有可能不充分。

自底向上測試的優點在于，由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，生成測試數據也沒有困難。它的缺點在于，直到最后一個模塊被加入進去之后才能看到整個程序（系統）的框架。

系統測試：是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起，在實際運行環境下，為了發現缺陷并度量產品質量，按照系統的功能和性能需求進行的一系列組裝測試和確認測試。

系統測試的依據: 開發人員提供的“需求規格說明書”，凡是和規格書不一致的地方都可以認為是問題。當然也不排除規格書有誤的地方，這些也需要提出來要求開發人員改正，以保證資料的正確性和權威性。

系統測試類型

web系統測試：功能測試、性能測試、安全性測試、兼容性測試、易用性測試、配置測試；

通訊類系統：功能測試、可靠性測試、鑒權測試、產品許可測試、多終端測試；

單機版系統：功能測試、安裝測試、容量測試、界面測試、恢復測試；

自動化測試: 通過測試工具或其他手段來部分替代手工測試，并按照測試工程師預定計劃進行自動測試的活動，它是軟件測試的一個重要組成部分，能夠完成許多手工無法完成或者難以實現的一些測試工作。

正確、合理地實施自動化測試，能夠快速、全面地對軟件進行測試，從而提高軟件質量,節省經費、縮短產品發布周期。自動化測試的基本原理: 錄制 腳本編輯 回放 運行腳本 分析結果

自動化測試的優點：

1、對程序的回歸測試更方便。

2、可以運行更多更繁瑣的測試

3、可以執行一些手工測試困難或不可能進行的測試。

4、更好地利用資源，將繁瑣的任務自動化，將測試技術人員解脫出來投入更多精力設計更好的測試用例。

5、測試具有一致性和可重復性

6、測試具有復用性，自動化測試的腳本技術可在不同的測試過程重用。

7、增加軟件信任度。自動化測試的缺點：

1、不能取代手工測試；

2、手工測試比自動測試發現的缺陷更多；

3、對測試質量的依賴性極大；

4、測試自動化不能提高有效性；

5、測試自動化可能會制約軟件開發。由于自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟件的開發。

6、工具本身并無想像力。

測試工具分類: 白盒測試工具： JUnit 黑盒測試工具:QuickTest 性能測試工具： LoadRunner 用于測試管理： TestDirector

第二篇：軟件測試期末復習

一、單項選擇題：共20小題，每小題2 分，滿分40分。

1．軟件測試按照測試層次可以分為(C)A．黑盒測試、白盒測試//測試方式 B.功能性測試和結構性測試//測試目的 C．單元測試、集成測試和系統測試

D、動態測試和靜態測試//測試方式

2、軟件測試是采用（測試用例）執行軟件的活動。

A．測試用例 B．輸入數據 C．測試環境 D．輸入條件

3．軟件測試是軟件開發過程的重要階段，是軟件質量保證的重要手段，下列哪個（些）是軟件測試的任務？答案：（D）

1預防軟件發生錯誤 2發現程序錯誤 3提供診斷錯誤信息 A．只有1 B．只有2 C．只有3 D．都是

4、導致軟件缺陷的最大原因是：（A）

A．軟件需求說明書

B．設計方案 C．編碼

D．維護

5、測試用例是為達到最佳的測試效果或高效的揭露隱藏的錯誤而精心設計的少量測試數據，至少應該包括（A）

A、測試輸入、執行條件和預期的結果。

B、測試目標、測試工具 C、測試環境

D、測試配置

6、對已經發現的錯誤進行錯誤定位和確定出錯性質，并改正這些錯誤，同時修改相關的文檔，這種行為屬于（B）

A．測試

B．調試 C．回歸測試

D．單元測試

軟件測試是軟件測試人員和程序員都參與的一項工作，是貫穿整個生命周期的，只需要發現軟件的錯誤，而軟件調試主要是程序員自己參與，對程序（設計、編碼）進行修改、排除錯誤，主要是在開發階段。

7、軟件缺陷修復的代價最高的階段為（A）

A、發布階段

B、需求階段 C、設計階段

D、編碼階段

8、下列（B）是關于軟件缺陷的描述。

A．導致軟件包含故障的人的行為//軟件錯誤 B．產品的異常情況

C．引起一個功能部件不能完成所要求的功能的一種意外情況 D．功能部件執行其規定功能的能

軟件錯誤是指在軟件生存期內的不希望出現或不可接收的人為錯誤，軟件錯誤導致軟件缺陷的產生。

軟件缺陷是存在于軟件（文檔，數據，程序）之中不希望出現或不可接收的偏差；軟件缺陷導致軟件在運行某一特定條件時出現軟件故障；這時軟件缺陷被激活。

軟件故障是指軟件在運行過程中產生的不希望出現或不可接收的內部狀態，對軟件故障若無適當措施加以及時處理，就會是軟件失效。

軟件失效是指軟件在運行時產生的不希望出現或不可接受的外部行為結果。

9、可作為測試停止的標準是（D）

A．當時間用光時

B．執行了所有的測試用例，但沒有發現故障 C．當所有缺陷都已經清除時 D．當達到所要求的覆蓋時

10、下列描述錯誤的是（A）

A．軟件發布后如果發現質量問題，那是軟件測試人員的錯 B．窮盡測試實際上在一般情況下是不可行的 C．軟件測試自動化不是萬能的

D．測試能由非開發人員進行，調試必須由開發人員進行。

11、如下圖所示的N-S圖，至少需要（B）個測試用例完成邏輯覆蓋。

A．15 B．16 C．17 D．18

12、下列（C）方法設計出的測試用例發現程序錯誤的能力最強。

A．等價類劃分法 B．場景法

C．邊界值分析法 D．決策表法

13、功能性測試是根據（A）來設計測試用例。

A、軟件的規格說明 B、設計文檔

C、程序的內部邏輯 D、維護手冊

14、在軟件修改之后，再次運行以前為發現錯誤而執行程序曾用過的測試用例，這種測試稱之為（C）

A．單元測試 B．集成測試 C．回歸測試 D．驗收測試

15、（C）方法是根據輸出對輸入的依賴關系來設計測試用例的。

Ａ．邊界值分析 Ｂ．等價類 Ｃ．因果圖法 Ｄ．錯誤推測法

16、測試工程師的工作范圍會包括檢視代碼、評審開發文檔，這屬于（B）

A．動態測試

B．靜態測試 C．黑盒測試

D．白盒測試

17、下列（B）是對程序流程圖進行簡化后得到的，它可以更加突出的表示程序控制流的結構，且不包含復合條件。

A．DD-路徑圖

B． 控制流圖 C．MM-路徑圖

D． 模塊調用圖

18、自底向上增量式集成測試中，下面（C）描述是正確的。

A．測試由樁模塊控制

B．最上面的模塊最先測試

C．父單元用測試過的子單元測試

D．包含樹的深度優先或廣度優先遍歷過程

19、以下關于測試用例特征的描述錯誤的是(C)A．最有可能抓住錯誤的； B．一定會有重復的、多余的； C．一組相似測試用例中最有效的； D．既不是太簡單，也不是太復雜。20、（D）是一種關注變量定義賦值點（語句）和引用或使用這些值的點（語句）的結構性測試，主要用作路徑測試的真實性檢查。

A、基本路徑測試

B、邏輯覆蓋 C、決策表

D、數據流測試

二、判斷題：共20小題，每題1分，滿分20分）

1.軟件測試是有風險的行為，并非所有的軟件缺陷都能夠被修復。（T）2.軟件質量保證和軟件測試是同一層次的概念。（F）

3.我們有理由相信只要能夠設計出盡可能好的測試方案，經過嚴格測試之后的軟件可以沒有缺陷。（F）

4.程序員兼任測試員可以提高工作效率。（F）

5.在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。（T）6.傳統測試是在開發的后期才介入，現在測試活動已經擴展到了整個生命周期。（T）7.傳統測試以發現錯誤為目的，現在測試已經擴展到了錯誤預防的范疇。T 8.軟件測試的生命周期包括測試計劃、測試設計、測試執行、缺陷跟蹤、測試評估。（T）9.調試從一個已知的條件開始，使用預先定義的過程，有預知的結果；測試從一個未知的條件開始，結束的過程不可預計。（F）

10.白盒測試往往會造成測試用例之間可能存在嚴重的冗余和未測試的功能漏洞。（F）11.在所有的黑盒測試方法中，基于決策表的測試是最為嚴格、最具有邏輯性的測試方法。（∨）12.永遠有缺陷類型會在測試的一個層次上被發現，并且能夠在另一個層次上逃避檢測。（∨）13.測試用例的數目越多，測試的效果越好。（x）

14.只要能夠達到100％的邏輯覆蓋率，就可以保證程序的正確性。（x）15.單元測試屬于動態測試。（∨）16.驗收測試是以最終用戶為主的測試。（∨）17.沒有發現錯誤的測試是沒有價值的。（∨）18.可以把不合格的開發人員安排做測試。（x）19.每一個軟件項目都有一個最優的測試量。（∨）

20.黑盒測試往往會造成測試用例之間可能存在嚴重的冗余和未測試的功能漏洞。（∨）

三、簡答題：共4小題，每題5分，滿分20分。

1、簡單描述一下軟件測試工程師一般會承擔的一些具體工作。1：檢視代碼，評審開發文檔（靜態測試方法）

2：進行測試設計，寫作測試文檔（測試計劃，測試方案，測試用例等）3：執行測試，發現軟件缺陷，提交缺陷報告，并確認缺陷最終得到了修正。4：通過測試度量軟件的質量。

2、黑盒測試與白盒測試各有哪些優缺點？

黑盒測試與軟件如何實現無關，測試用例開發可以實現并行進行，因此可以壓縮總的項目開發時間，缺點：測試用例可以之間可能存在嚴重的冗余。還會有未測試的軟件漏洞。白盒測試局限于已經完成的代碼行為當中，離代碼太近，如果黑盒測試結合白盒測試的覆蓋率指標執行，冗余和漏洞問題會被發現并解決。如果發現同一條程序路徑被多個功能性測試用例遍歷，就可以懷疑這種冗余不會發生新的缺陷。

3、畫圖描述測試層次與傳統開發V型瀑布模型的對應

4、有函數f(x,y,z)，其中x∈[1900,2100]，y∈[1,12]，z∈[1,31]的。請寫出該函數采用基本邊界值分析法設計的測試用例。

(2000,6,1)，（2000,6,2），（2000,6,30），（2000,6,31），（2000,1,15），（2000,2,15）（2000,13,15），（2000,12,15），（1900,6,15），（1901,6,15），（1999,6,15），（2100,6,15）（2000,6,15）

測試用例來自等價類的邊界；正好等于；剛剛大于；剛剛小于邊界的值

四、綜合題：共1小題，每題20分，滿分20分。

1、使用基本路徑測試方法，為以下程序段設計測試用例。（1）畫出程序的控制流圖。

（2）計算程序的循環復雜度，導出程序基本路徑集中的獨立路徑條數。

（3）導出基本路徑集，確定程序的獨立路徑。

（4）根據（3）中的獨立路徑，設計測試用例（確保基本路徑集中的每一條路徑的執行）的輸入數據和預期輸出。

void Do(int X,int A,int B){ 1 if((A>1)&&(B=0))2 X = X/A;3 if((A=2)||(X>1))4 X = X+1;5 }

由于控制流圖假設的是單條件，因此對于復合條件，可將其分解為多個單個條件，并映射成控制流圖。1： A>1； 2： B=0 ； 3： X = X/A ； 4： A=2 ； 5：X>1 ； 6： X = X+1； 7： }

第三篇：軟件測試（推薦）

一、簡答5*6’

1.為什么不讓時間有余的人做測試工作

表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。2.軟件測試風險主要體現在哪里

我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小 3.所有軟件測試缺陷都需要修復嗎

從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復。-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。4.如何減少測試人員跳槽帶來的損失 建議我們從以下兩個方面做起：

-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實現。

5.驗收測試的注意點有哪些 測試要注意下面的事項：

（1）用戶現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。（2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。（3）永遠不能欺騙用戶，蒙混過關。6.完全測試程序是可能的嗎

實際上完全測試是不可能的。主要有以下原因：-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現實中往往是行不通的；-輸入量太大，不能一一進行測試；-輸出結果太多，只能分類進行驗證；-軟件實現途徑太多；

-軟件產品說明書沒有客觀標準，從不同的角度看，軟件缺陷的標準不同；因此測試的程度要根據實際情況確定 7.是不是發現的缺陷越多就說明軟件缺陷越多 其中的原因主要如下：

-代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。-程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。

“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。8.軟件測試就是QA嗎

軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是創建或者制定標準和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。9.測試產品和測試項目區別

習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產品，也就是可以買“賣拷貝”的軟件，軟件項目是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟件產品來滿足特定的用戶需求。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：

-質量要求不同。通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了。測試資源投入多少不同。做軟件產品通常是研發中心來開發，進度壓力要小些。同時由于質量要求高，因此會投入較多的人力、物力資源。項目最后要和用戶共同驗收測試，這是產品測試不具有的特點。此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作 10.如何編寫提交給用戶的測試報告

測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：

根據內部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；報告上面的內容盡量要真實可靠；整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。總之，外部測試報告要小心謹慎的編寫。

二、論述2*12’

1.請論述為什么要進行軟件測試，并列舉歷史上2~3個著名軟件測試（缺陷）案例，說明測試重要性

軟件測試的目的,第一是確認軟件的質量，其一方面是確認軟件做了你所期望做的事情（，另一方面是確認軟件以正確的方式來做了這個事情。第二是提供信息，比如提供給開發人員或程序經理的回饋信息，為風險評估所準備的信息。第三軟件測試不僅是在測試軟件軟件產品本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此，軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

愛國者導彈防御系統把“槍口”對準了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統性能問題

2.論述軟件測試科學的發展歷程 1957年之前－調試為主 20世紀50年代，計算機剛誕生不久，只有科學家級別的人才會去編程，需求和程序本身也遠遠沒有現在這么復雜多變，相當于開發人員一人承擔需求分析，設計，開發，測試等所有工作，當然也不會有人去區分調試和測試。

1957–1978－證明為主 當時計算機應用的數量，成本和復雜性都大幅度提升，隨之而來的經濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發現問題。

1983–1987－評估為主 人們提出了在軟件生命周期中使用分析，評審，測試來評估產品的理論。軟件測試工程在這個時期得到了快速的發展.1988–至今－預防為主 預防為主是當下軟件測試的主流思想之一。測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。3.論述軟件缺陷的由來

軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的。

軟件本身：①需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產品特征上的缺陷。②系統結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數傳遞、方法調用、對象狀態變化等方面問題。③對程序邏輯路徑或數據范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。④對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題。⑤沒有考慮系統崩潰后的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統安全性、可靠性的隱患。⑥系統運行環境的復雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。⑧新技術的采用，可能涉及技術或系統兼容的問題，事先沒有考慮到。

團隊工作：系統需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開發人員相互理解不一致。對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。項目組成員技術水平參差不齊技術問題。算法錯誤：在給定條件下沒能給出正確或準確的結果。語法錯誤：對于編譯性語言程序，編譯器可以發現這類問題；但對于解釋性語言程序，只能在測試運行時發現。計算和精度問題：計算的結果沒有滿足所需要的精度。系統結構不合理、算法選擇不科學，造成系統性能低下。接口參數傳遞不匹配，導致模塊集成出現問題。

項目管理的問題：缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開發周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；周期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。開發流程不夠完善，存在太多的隨機性和缺乏嚴謹的內審或評審機制，容易產生問題。文檔不完善，風險估計不足等。4.軟件測試V模型

①繪制示意圖

②闡述每個步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能

概要設計

主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務。詳細設計

對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等。軟件編碼

按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。單元測試

按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測試

經過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現情況，以及模塊接口連接的成功與否，數據傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據集成測試計劃，一邊將模塊或其他軟件單位組合成系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。系統測試

經過了單元測試和集成測試以后，我們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等。驗收測試

主要就是用戶在拿到軟件的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來做相應測試，以確定軟件達到符合效果的。

第四篇：軟件測試期末復習知識點總結

1.軟件測試：是由“驗證（verrificatione）”和“有效性確認（validation）”活動構成的整體： “驗證”是檢驗軟件是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟件相關產品與所有生命周期活動的要求（如正確性、完整性、一致性、準確性等）相一致。相當于以軟件產品設計規格說明書為標準進行軟件測試的活動。

“有效性確認”是確認所開發的軟件是否滿足用戶真正需求的活動。一切從客戶出發，理解客戶的需求，對軟件需求定義、設計的懷疑，發現需求定義和產品設計中的問題。這主要通過各種軟件評審活動來實現，包括讓客戶參加評審、測試活動。

軟件測試過程：（1）測試組織和管理（2）測試計劃（3）測試用例實際（4）測試實施（5）測試結果分析（6）測試評審與報告 軟件測試方法：白盒測試方法、黑盒測試方法、靜態測試與動態測試、主動測試與被動測試、形式化測試方法、基于風險的測試、模糊測試方法、ALAC測試和隨機測試方法

2.單元測試：是對軟件基本組成單元進行的測試，而且軟件單元是在與程序的其他部分相隔離的情況下進行獨立的測試。

靜態測試就是靜態分析，對模塊的源代碼進行研讀，查找錯誤或收集一些度量數據，并不需要對代碼進行編譯和仿真運行。

動態測試是通過真正運行程序發現錯誤，通過觀察代碼運行過程，來獲取系統行為、變量實時結果、內存、堆棧、線程以及測試覆蓋度等各方面的信息，來判斷系統是否存在問題，或者通過有效的測試用例，對于的輸入輸出關系來分析被測程序的運行情況，來發現缺陷。靜態測試、動態測試的區別：1.靜態測試用于預防，動態測試用于矯正；2.多次的靜態測試比動態測試的效率高；3，靜態測試綜合測試程序代碼；4.在相當短的時間里，測試的覆蓋率能達到100%，而動態測試經常只能達到50%測試左右；5.動態測試比靜態測試更花時間； 6.靜態測試比動態測試更能發現bug；7.靜態測試的執行可以在程序編碼編譯前，動態是中能在編譯后才能執行。

3.功能測試：一般須在完成集成測試后進行，而且是針對應用系統進行測試是根據產品規格說明書，來檢驗被測試的系統是否滿足各方面功能的使用要求。

集成測試：也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統或系統，進行集成測試，其主要目的是檢查軟件單位之間的接口是否正確。集成測試包括非增量測試和增量測試兩種方式，集成測試的策略主要有自頂向下和自底向上兩種。

功能測試、集成測試區別：

4.回歸測試：目的是在程序有修改的情況下，保證原有功能正常的一種測試策略和方法。程序在發現嚴重軟件缺陷要進行修改或版本升級要新增功能，這時需要對軟件進行修改，修改后的程序要進行測試，這時要檢驗軟件所進行的修改是否正確，保證改動不會帶來新的嚴重錯誤。

5.樁程序（Stub），也稱樁模塊：用以模擬被測模塊工作過程中所調用的下層模塊。樁模塊由被測模塊調用，它們一般只進行很少的數據處理,例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口。驅動程序（Driver），也稱驅動模塊：用以模擬被測模塊的上級模塊，能夠調用被測模塊。在測試過程中，驅動模塊接受測試數據，調用被測模塊并把相關的數據傳送給被測模塊。

軟件缺陷：軟件缺陷是指計算機系統或者程序中存在的任何一種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷、瑕疵，其結果會導致軟件產品在某種程度上不能滿足用戶的需求。標準定義，從產品內部看，軟件缺陷是軟件產品開發或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統所需要實現的某種功能的失效或違背。

軟件測試步驟： 即單元測試、集成測試、確認測試和系統測試。

1.開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。2.集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。3.確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。4.系統測試把已經經過確認的軟件納入實際運行環境中，與其它系統成份組合在一起進行測試。

軟件測試流程：需求分析和定義、系統設計、詳細功能設計、編碼、單元測試、功能測試、系統測試、驗收測試

軟件測試涉及的關鍵問題：1.測試過程和開發過程是同時開始，同時結束的，兩者保持同步的關系；2.測試過程是對開發過程中階段性成果和最終產品進行驗證的過程，所以兩者相互依賴；3.測試過程中的工作重點和開發工作的重點可能不一樣，兩者有各自的特點

黑盒測試的特點：1.不基于對系統內部的設計和實現。2.用例設計基于功能的定義和需求說明書。3.關注于測試數據的選擇和測試結果的分析。

測試方法有：等價類劃分、邊界值分析法、判定表方法、因果圖法、正交實驗法、功能圖法、錯誤推測法

黑盒測試缺點：1.對用例設計人員的經驗要求較高，包括數據的選擇，對潛在錯誤的敏感性；2.對于內部實現的bug不容易發現；3.不能提供直觀的測試覆蓋率。

白盒測試的特點：1.需要了解系統的整體設計和實現；2.對源代碼進行審查；3.在單元測試階段發現大量的缺陷；4.關注于系統的控制流和數據流；

測試方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋、基本路徑測試法

白盒測試缺點：1.不能確保系統是否完全符合需求說明書；2.白盒測試的代價會大于黑盒測試；3.需要源代碼首先完成才能進行測試；

集成測試中自頂向下和自底向上方法

自頂向下法：從主控模塊（主程序）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結合起來。具體步驟是：1.對主控模塊進行測試，測試時用樁程序代替所有直接附屬于主控模塊的模塊；2.根據選定的結合策略，每次用一個實際模塊代替一個樁程序；3.在結合下一個模塊的同時進行測試；4.為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試。優點：不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統的主要功能，而且能在早期發現上層模塊的接口錯誤。缺點：需要樁程序，可能遇到與此相聯系的測試困難，低層關鍵模塊中的錯誤發現較晚，而且用這種方法在早期不能充分展開人力

自底向上法：從“原子”模塊（即在軟件結構最底層的模塊）開始集成以進行測試，具體策略是：1.把底層模塊組合成實現某個特定的軟件子功能的族；2.寫一個驅動程序，協調測試數據的輸入輸出；3.對由模塊組成的子功能族進行測試；4.去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。優缺點：剛好和自頂向上相反

簡述增量式集成測試的自頂向下和自底向上兩種測試方法：自頂向下增量式測試的主要優點在于它可以自然地做到逐步求精，一開始便能讓測試者看到系統的框架。它的主要缺點是

需要提供被調用模擬子模塊，被調用模擬子模塊可能不能反映真實情況，因此測試有可能不充分。自底向上測試的優點在于，由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，生成測試數據也沒有困難。它的缺點在于，直到最后一個模塊被加入進去之后才能看到整個程序（系統）的框架

集成測試自底向上和自頂向下集成方法優缺點是什么？

自底向上集成方法盡早的對底層實用歷程進行測試，可以避免編寫眾多的樁模塊，使得系統底層的眾多問題及早得到解決。缺點是在一些頂層構件非常重要的情況下，卻將其放到了最后集成。

自頂向下集成方法則盡早進行了頂層控制模塊的測試和集成，使得系統整體上得到驗證，但卻將底層實用歷程的測試放到了最后。某些具有關鍵性能或作用的底層模塊的問題將在最后才可能被發現。

簡述系統測試過程的主要步驟及每個步驟的測試依據。

功能測試：測試依據是系統功能需求；

性能測試：測試依據是其他軟件需求；

驗收測試：測試依據是客戶需求規格說明書；

安裝測試：測試依據是用戶環境

第五篇：軟件測試復習資料

1． 黑盒測試法是通過分析程序的功能來設計測試用例的方法。

2． 黑盒測試除了測試程序外，它還適用于對需求分析階段的軟件文檔進行測試。3． 白盒測試除了測試程序外，它也適用于對軟件具體設計階段的軟件文檔進行測試。4． 單元測試一般以白盒測試法為主，測試的依據是模塊功能規格說明。5． 軟件測試中常用的靜態分析方法是引用分析和接口分析。

6． 測試人員的基本素質為計算機專業技能、測試專業技能、行業知識

7． 軟件危機的體現為：A、開發成本和進度估計不正確B、用戶對完成的軟件不滿足C、軟件經常不可維護；

8． 軟件測試按照開發階段劃分：A、單元測試

B、集成測試；系統測試C、確認測試；驗收測試

9． 軟件測試按照測試技術劃分：A、性能測試、負載測試、壓力測試B、恢復測試、安全測試、兼容測試

10． 軟件測試項目周期是指：A、需求階段、測試計劃B、階段測試、設計階段測試、執行階段 11． 軟件測試原則有：A、制定嚴格的測試計劃 B、保留所有的測試文檔C、功能測試中的缺陷確認 12． 制定測試計劃的步驟：確定測試范圍、確定測試策略、確定測試標準、確定測試構架、確定項目管理機制、預計測試工作量、測試計劃評審 13． 對于軟件的β測試，β測試就是在軟件公司外部展開的測試，由非專業的測試人員執行的測試。14． 正式的技術評審FTR（Formal Technical Review）是軟件質量保證活動，其相關的描述為： A.FTR是評審產品而不是評審生產者的能力B.FTR要有嚴格的評審計劃并遵守日程安排C.FTR限制參與者人數并要求評審會之前做好預備 15． 在進行單元測試時，常用的方法是采用白盒測試，輔之以黑盒測試

16． 側重于觀察資源耗盡情況下的軟件表現的系統測試被稱為壓力測試 17． 必須要求用戶參與的測試階段是驗收測試 18． 系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求并且遵循系統設計。

19． 測試通常可分為白盒測試和黑盒測試。白盒測試是根據程序的內部邏輯來設計測試用例,黑盒測試是根據軟件的規格說明來設計測試用例。20． 一個程序中所含有的路徑數與程序的復雜程度有著直接的關系。

1． 測試階段的根本目標是盡可能多地發現并排除軟件中潛藏的錯誤，最終把一個高質量的軟件系統交給用戶使用。2． 功能測試時系統測試的主要內容，檢查系統的功能、性能是否與需求規格說明相同。3． 軟件測試主要分為單元測試、集成測試、確認測試和系統測試四類測試。4． 漸增方式把模塊結合到程序中去時，有自頂向下和自底向上兩種集成策略。5． 編寫測試用例的依據是單元測試計劃和詳細設計說明書。6． 系統測試時在集成測試完成后，確認測試之前進行的測試。

7． 設計系統測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。

8． 測試設計員的職責有設計測試用例、設計測試過程、腳本。

9． 軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種類型。10． 軟件測試按照開發階段劃分單元測試、集成測試、系統測試、確認測試、驗收測試。11． 軟件測試按照測試技術劃分性能測試、負載測試、壓力測試、恢復測試、安全測試、兼容測試

12． 靜態測試基本特征是在對軟件進行分析、檢查和審閱，不實際運行被測試的軟件 13． 軟件測試項目周期是指需求階段、測試計劃、階段測試、設計階段測試、執行階段 14． 軟件測試的角色分析人員、設計人員、開發人員、執行人員 15． 軟件測試原則有制定嚴格的測試計劃、、保留所有的測試文檔、功能測試中的缺陷確認

16． 測試工作的文檔主要有：測試計劃、測試模型和用例設計或規格說明、測試分析報告等

17． 測試計劃的制定必須要注重測試策略、測試范圍、測試方法、測試安排、測試風險、測試治理

18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設計的缺陷、靜態文檔的缺陷、軟件開發引起的缺陷、短視將來的缺陷 19． 測試用例工作主要是如何添加測試用例、如何編寫測試用例、將測試用例和需求關聯

20． 自動化測試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設計階段的BUG、實現階段的BUG、配置階段的BUG、靜態文檔的BUG。23． 測試項目主要包括以下幾個階段：計劃階段、初始階段、執行階段、總結評估階段、設計階段。

1． 缺陷報告

是描述軟件缺陷現象和重現步驟地集合。軟件缺陷報告Software Bug Report（SBR）或軟件問題報告Software Problem Report（SPR）

2． 回歸測試

是指重新執行已經做過的測試的某個子集，以保證修改變化沒有帶來非預期的副作用。

3． 動態測試 通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。動態測試的兩個基本要素： 被測試程序、測試數據（測試用例）

4． 白盒測試又稱為結構測試和邏輯驅動測試，允許測試人員對程序內部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯路徑進行測試。白盒測試是把測試對象看作一個打開的盒子，測試人員須了解程序的內部結構和處理過程，由于白盒測試是一種結構測試，所以被測對象基本上是源程序，以程序的內部邏輯和指定的覆蓋標準確定測試數據。

5． 黑盒測試又稱為功能測試或數據驅動測試，把系統看成一個黑盒子，不考慮程序的內在邏輯，只根據需求規格說明書的要求來檢查程序的功能是否符合它的功能說明。

6． 路徑覆蓋的含義是，選取足夠多的測試數據，使程序的每條可能路徑都至少執行一次(如果程序圖中有環，則要求每個環至少經過一次)。

7． 軟件測試 ：在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。8． 單元測試（模塊測試）：針對每個模塊進行的測試，可從程序的內部結構出發設計測試用例，多個模塊可以平行地對立地測試。通常在編碼階段進行，必要的時候要制作驅動模塊和樁模塊。9． 集成測試：在單元測試的基礎上，將所有模塊按照設計要求組裝成為系統，應提交集成測試計劃、集成測試規格說明和集成測試分析報告。

10． 確認測試：驗證軟件的功能和性能及其它特性是否與用戶的要求一致。

11． 系統測試：將軟件放在整個計算機環境下，包括軟硬件平臺、某些支持軟件、數據和人員等，在實際運行環境下進行一系列的測試。

1． 測試過程中會產生哪些基本文檔？

（1）測試計劃（通常包括單元測試和集成測試）：確定測試范圍、方法和需要的資源

（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數據（包括測試數據及預期的結果）；

（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生 問題報告，并且必須通過調試解決所發現的問題。

（4）

2.大型軟件系統的測試過程基本上由幾個步驟組成? 1）.模塊測試

在設計得好的軟件系統中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設計檢驗模塊正確性的測試方案。模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發現的往往是編碼和詳細設計的錯誤。2）.子系統測試

子系統測試是把經過單元測試的模塊放在一起形成一個子系統來測試。模塊相互間的協調和通信是這個測試過程中的主要問題，因此，這個步驟著重測試模塊的接口。3）.系統測試

系統測試是把經過測試的子系統裝配成一個完整的系統來測試。在這個過程中不僅應該發現設計和編碼的錯誤，還應該驗證系統確實能提供需求說明書中指定的功能，而且系統的動態特性也符合預定要求。在這個測試步驟中發現的往往是軟件設計中的錯誤，也可能發現需求說明中的錯誤。不論是子系統測試還是系統測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。4）.驗收測試

驗收測試把軟件系統作為單一的實體進行測試，測試內容與系統測試基本類似，但是它是在用戶積極參與下進行的，而且可能主要使用實際數據(系統將來要處理的信息)進行測試。驗收測試的目的是驗證系統確實能夠滿足用戶的需要，在這個測試步驟中發現的往往是系統需求說明書中的錯誤。驗收測試也稱為確認測試。5）.平行運行

關系重大的軟件產品在驗收之后往往并不立即投入生產性運行，而是要再經過一段平行運行時間的考驗。所謂平行運行就是同時運行新開發出來的系統和將被它取代的舊系統，以便比較新舊兩個系統的處理結果。這樣做的具體目的有如下幾點：(1)可以在準生產環境中運行新系統而又不冒風險；(2)用戶能有一段熟悉新系統的時間；

(3)可以驗證用戶指南和使用手冊之類的文檔；

(4)能夠以準生產模式對新系統進行全負荷測試，可以用測試結果驗證性能指標。3.一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。

計劃階段、設計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統測試、回歸測試、驗收測試一套完整的測試應該由五個階段組成：

1）測試計劃首先，根據用戶需求報告中關于功能要求和性能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準。以后所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程序即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。2）測試設計將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，并為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響測試結果的有效性）。

3）測試開發建立可重復使用的自動測試過程。

4）測試執行執行測試開發階段建立的自動測試過程，并對所發現的缺陷進行跟蹤管理，測試執行一般由單元測試、組合測試、集成測試、系統聯調及回歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。

5）測試評估結合量化的測試覆蓋域及缺陷跟蹤報告，對于應用軟件的質量和開發團隊的工作進度及工作效率進行綜合評價。4.軟件測試的流程

制訂測試計劃、設計測試用例、實施測試、提交缺陷報告、編寫測試總結。5.測試計劃的內容都包括什么？其中哪些是最重要的？

1)測試計劃的內容：測試目的和測試項目簡介、測試參考文檔和測試提交文檔、術語和定義、測試策略、確定測試內容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準、暫停和重新啟動測試的標準、風險和問題等。2)最重要的：測試策略、確定測試內容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準 6.測試計劃的目的是什么？

測試計劃的目的：編寫軟件測試計劃的目的是指導測試組成員進行工作和讓測試組以外的項目成員了解測試工作的。7.簡述靜態測試和動態測試的區別？

a)靜態測試： 基本特征是在對軟件進行分析、檢查和審閱，不實際運行被測試的軟件。靜態測試約可找出30～70%的邏輯設計錯誤。對需求規格說明書、軟件設計說明書、源程序做檢查和審閱。包括：是否符合標準和規范；通過結構分析、流圖分析、符號執行指出軟件缺陷。b)動態測試：通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。動態測試的兩個基本要素：被測試程序和測試數據（測試用例）。動態測試方法：(1)選取定義域有效值,或定義域外無效值；(2)對已選取值決定預期的結果；(3)用選取值執行程序；(4)執行結果與預期的結果相比,不吻和程序有錯。8.白盒測試有哪幾種方法？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。9.壓力測試和性能測試的區別？

1)廣義上說壓力測試是包括在性能測試之中的，是性能測試項內的一種。

2)性能測試：顧名思義就是測試軟件的運行性能。驗證SRS中的性能需求，是否實現。

3)壓力測試：測試軟件在超負荷下的工作情況，也是一種軟件的性能。因此是屬于性能測試范圍的。

10.測試結束的標準是什么？

測試計劃中所有規定的測試內容和回歸測試都已經運行完成或根據上級主管對測試結果的意見，就可以結束本次測試。11.黑盒測試的測試用例設計方法包括哪些？：

a)等價類劃分：劃分等價類--確立測試用例--設計用例。b)邊界值分析：通過分析，考慮如何確立邊界情況 c)錯誤推測法：靠經驗和直覺來推測程序中可能存在的各種錯誤，從而有針對性地編寫用例。可以列舉出可能的錯誤和可能發生錯誤的地方，然后選擇用例。d)因果圖：通過畫因果圖，在圖上標明約束和限制，轉換成判定表，然后設計測試用例。這適合于檢查程序輸入條件的各種組合情況。

12.缺陷報告的作用

缺陷報告是軟件測試人員的工作成果之一，體現軟件測試的價值缺陷報告可以把軟件存在的缺陷準確的描述出來，便于開發人員修正缺陷報告可以反映項目、產品當前的質量狀態，便于項目整體進度和質量控制。軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力。13.等價分類法的基本思想是什么？

根據程序的輸入特性，將程序的定義域劃分為有限個等價區段“等價類”，從等價類中選擇出的用例具有“代表性”，即測試某個等價類的代表值就等于對這一類其他值的測試。如果某個等價類的一個輸入數據（代表值）測試中查出了錯誤，說明該類中其他測試用例也會有錯誤。14.簡單闡述一下軟件測試的目標

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。15.軟件測試準則有哪些？

(1)所有測試都應該能追溯到用戶需求。

(2)應當把“盡早地和不斷地進行軟件測試” 作為軟件開發者的座右銘。(3)pareto原則：測試發現的錯誤中的80%很可能是由程序中20%的模塊造成的。

（4）應該從“小規模”測試開始，并逐步進行“大規模”測試。

（5）測試用例應由輸入數據和預期的輸出結果兩部分組成，并兼顧合理的輸入和不合理的輸入數據

（6）窮舉測試是不可能的。

（7）為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。

（8）程序修改后要回歸測試。

（9）應長期保留測試用例，直至系統廢棄。16.您認為做好測試用例設計工作的關鍵是什么？

1)白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

2)黑盒測試用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

1． 根據下面給出的規格說明，利用等價類劃分的方法，給出足夠的測試用例。

“一個程序讀入三個整數。把此三個數值看成是一個三角形的三個邊。這個程序要打印出信息，說明這個三角形是三邊不等的、是等腰的、還是等邊的。”

2． 某報表處理系統要求用戶輸入處理報表的日期，日期限制在2003年1月至2008年12月，即系統只能對該段期間內的報表進行處理，如日期不在此范圍內，則顯示輸入錯誤信息。系統日期規定由年、月的6位數字字符組成，前四位代表年，后兩位代表月。請用等價類劃分法和邊界值劃分法設計測試用例來測試程序的日期檢查功能。

3． 設要對一個自動飲料售貨機軟件進行黑盒測試。該軟件的規格說明如下：

“有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣。”

利用等價類劃分的方法，設計測試該軟件的全部測試用例。