問題總結：

1.測試用例覆蓋考慮不全面，測試用例設計方法使用不夠完美，無法熟練掌握測試用例設計的方法。

2.測試用例設計之前，思維分析能力薄弱，無法完全理解需求。

1.知識總結

1.1 軟體工程要點

1.1.1軟體的概念及分類

軟體最初的概念就是就是指程式，隨著時代發展，軟體就是指文件、程式和資料。

1. 當執行時，能夠提供所要求的功能和效能的指令或計算機程式集合。

2. 該程式能夠具有滿意地處理資訊的資料結構。

   ⑶ 描述程式功能需求以及程式如何操作和使用所要求的文件。

   軟體種類：

1. 系統軟體：作業系統、資料庫管理系統、裝置驅動程式等。

2. 應用軟體：事物軟體、娛樂軟體、實時軟體等。

3. 工具軟體：文字格式化軟體、文字編輯軟體等。

1.1.2軟體危機

軟體危機產生的原因：

（1）對使用者的需求不明確是產生軟體危機的主要原因之一；

（2）缺乏正確的理論指導；

（3）軟體開發規模越來越大；

（4）軟體開發複雜度越來越高；

如何消除軟體危機：

（1）應該對計算機軟體有一個正確的認識；

（2）必須充分認識到軟體開發不是某個個體勞動的神祕技巧，而應該是一種組織良好、理嚴密、各類人員協同配合、共同完成的工程專案。

1.1.3軟體工程

軟體工程是一門研究如何用系統化、規範化、數量化等工程原則和方法去進行軟體開發和維護的學科。

軟體工程三要素：方法、工具、過程。

軟體工程內容：軟體開發技術、軟體專案管理。

1. 軟體專案管理

   軟體專案管理包括軟體度量、專案估算、進度控制、人員組織、專案計劃等。

1.1.4軟體生命週期

軟體生命週期是軟體的產生直到報廢的生命週期，週期內有問題定義、可行性分析、總體描述、系統設計、編碼、除錯和測試、驗收與執行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟體工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文件以供交流或備查，以提高軟體的質量。

軟體生命週期模型：

1. 瀑布模型（開發者角度）

2. 迭代式模型

3. V模型（測試人員的角度）

4. W模型（測試人員的角度）

5. 敏捷模型

1.1.5軟體開發主流技術

1.2軟體測試基礎

1.2.1軟體測試基本概念

1.定義：

Hetzal：評級一個系統或程式的特性或能力，並確認他是否達到預期的結果，檢查是否滿足規定的需求。

Myers：測試是為了發現錯誤而執行程式的過程。

現代：是對軟體需求分析、設計、編碼的最終複查的一系列過程，是軟體質量保證的關鍵。

2. 軟體測試目的

a）儘可能發現並改正被測試軟體的錯誤，提高軟體的可靠性

b）保證軟體質量

c）建立軟體質量信心

3.軟體測試基本原則

（1）測試顯示缺陷的存在；

（2）窮盡測試是不可能的；

（3）測試儘早介入；

（4）缺陷叢集性（80-20原則）；

（5）殺蟲劑悖論；

（6）測試活動依賴於測試背景；

（7）不存在缺陷的謬論。

4.軟體測試質量度量

1.2.3軟體測試工作流程

軟體工作流程圖，如圖2。

圖 2 軟體測試工作流程圖

1.2.4 測試工作內容

1.計劃：識別測試任務、定義測試目標、定義為達到測試目標和任務所必須的測試活動

2.分析與設計：

評審測試依據（比如需求、系統架構、設計和介面說明等）、評估測試依據和測試物件的可測性、通過對測試項、規格說明、測試物件行為和結構的分析，識別測試條件並確定其優先順序；設計測試用例並確定優先順序、確定測試條件和測試用例所需的必要的測試資料、規劃測試環境的搭建和確定測試需要的基礎設施和工具。

1. 實現與執行：測試用例的開發、實現並確定它們的優先順序、開發測試規程並確定優先順序，建立測試資料，同時也可以準備測試用具和設計自動化測試指令碼、根據測試規程建立測試套件，提高測試執行的效率、確認已經正確搭建了測試環境、根據計劃的執行順序，通過手工或使用測試執行工具來執行測試規程、記錄測試執行的結果，以及被測軟體、測試工具和測試件的標識和版本。、將實際結果和預期結果進行比較、對實際結果和預期結果之間的差異，作為事件上報、缺陷修正後，重新進行測試活動。

2. 評估出口準則：按照測試計劃中定義的測試出口準則檢查測試日誌

3. 評估是否需要進行更多的測試，或是否需要更改測試的出口準則。

1.2.5軟體測試心理學

1.開發人員的思維，如圖3。

開發人員的思維是構造思維。

開發人員在設法通過程式實現使用者需求時，更多的是思考如何來實現功能而並非破壞該功能。

同時具備構造思維和破壞思維是一件不容易的事情思維的侷限性。

2.測試人員的思維

技術思維能力、對技術的建模能力和理解原因與後果的能力、創造思維能力、提出新想法和預見可能性的能力、批判思維能力、評價想法並進行推理的能力、實踐思維能力、將想法變成現實的能，測試人員的思維是一種破壞性的思維(逆向思維)。

3.開發人員與測試人員的關係

以合作而非鬥爭的方式開展專案，共同目標是追求高質量的產品

以中性的語調和事實為依據的方式來溝通，而不要指責和批評他人

儘量理解其他成員的感受，以及他們為什麼會有這種反應

確信其他成員已經理解你的描述。

3.軟體測試的心理學

⑴端正對軟體測試工作的認識。

⑵具有較強的溝通能力、外交能力和移情能力。

⑶掌握比較全面的技術。

⑷測試中要做到“5心：專心、細心、耐心、責任心、自信心”。

⑸要有很強的記憶力、懷疑精神和洞察力。

⑹具有探索、創新和挑戰精神，努力追求完美。

⑺測試人員在測試時要注意的事項：①永遠不要許諾或保證什麼；②文件反應了自己的精神面貌；③要學會逆向思維；④編寫缺陷時一定要保證重現；⑤測試要依據需求，關注對使用者不利的缺陷；⑥儘量使用測試工具；⑦牢記服務意識。

1.26測試工具

商業化的測試工具：

• 測試管理工具：HP ALM/QC

• 自動化測試工具：HP UFT(QTP & Service Test)

• 效能測試工具：HP Loadrunner

• 安全測試工具：HP Fortify、WebInspet

  開源測試工具：

  Testlink、Mantis、BugZilla、Selenium、JUnit、CppUnit

1.3基於生命週期的軟體測試

1.3.1生命名週期的概念

生命週期測試的概念：生命週期測試應伴隨整個軟體開發週期，此時測試的物件不僅僅是程式，需求、功能和設計同樣要設計。生命週期意味著測試與軟體開發平行，在軟體開發的所有階段進行測試，確保在儘可能早的階段點去修正缺陷，用來減少測試成本。

1.3.2生命週期模型

1. V模型，如圖3.

圖3 V模型

特點：①定義：基本的開發過程和測試行為②標明：測試過程中存在不同型別、不同級別的測試③描述：不同測試階段和開發過程期間各階段的對應關係。

2.W模型，如圖4.

圖4 W模型

特點：①增加了軟體各開發階段中應同步進行的驗證（verification）和確認（validation）活動。②基於“儘早地和不斷地進行軟體測試”的原則。

1.3.2生命週期測試的主要任務

生命週期測試的主要任務：

1. 測試要素：軟體的屬性，描述測試的主要目標；

2. 測試用例；

3. 測試種類/技術；

4. 測試的准入準出條件。

1.4軟體測試分類與分級

1.4.1軟體測試分類

1.1 軟體配置項

軟體配置縮寫為CSCI(Computer Software Configuration Item)，是為獨立的配置管理而設計的且能滿足終端使用者要求的一組軟體，簡稱軟體配置項。

軟體配置管理控制這些軟體配置項的投放和變更，並且記錄並報告配置的狀態和變更要求，驗證配置的完整性、正確性和一致性。

1.2基於CSCI的軟體測試分類

①功能測試：功能測試主要對軟體需求規格說明中的功能需求進行測試,找出被測軟體的實現與需求不一致的地方,確認一致的地方。

②效能測試：主要對軟體需求規格說明中定義的效能需求進行測試，費事在一定工作負荷和配置條件下，系統的響應時間及處理速度等特性。

③外部介面和人機互動介面測試：外部介面和人機互動介面測試主要對平臺各個服務域提供的應用程式設計介面、應用程式介面、外部環境介面以及人機互動介面的符合性和可用性進行測試。

④強度測試：強度測試必須在預先規定的一個時期內，在軟體設計能力的極限狀態，進而超出此極限狀態下，執行軟體的所有功能。

⑤餘量測試：測試程式全部儲存量、輸入/輸出通道及處理時間的餘量滿足需求規格說明的要求。

⑥可靠性測試：可靠性測試是在有使用代表性的環境中，為進行軟體可靠性估計而對其進行的功能測試。

⑦安全性測試：安全性測試主要對平臺軟體配置項的安全性進行測試，包括系統安全評估和系統侵入測試兩個部分。

⑧恢復性測試：對有恢復或重置（RESET）功能的軟體，必須驗證恢復或重置功能，對每一類導致恢復或重置的情況進行測試。

⑨邊界測試：測試程式在輸入域（或輸出域）、資料結構、狀態轉換、過程引數、功能界限等的邊界或端點情況下執行狀態。

⑩功能多餘物測試：驗證程式中沒有附加的軟體需求中沒有指明的功能及功能邊界的不適當。所有輸出都應有意義並在軟體需求中指明。

⑪安裝性測試：安裝性測試主要對平臺軟體配置項的可安裝性/可解除安裝性進行測試。

⑫本地化測試：本地化測試的內容，主要對平臺軟體配置項的本地語言、時間等本地特色的支援能力進行測試，驗證軟體配置項是否能全面、正確地支援、處理本地特色化要素。

⑬應用基準測試測試：應用基準測試主要對平臺軟體配置項的綜合性能進行測試。

1.3軟體測試分類，如圖5。

圖5 軟體測試分類

1.4.2軟體測試分級

對軟體測試的要求、目的、關注點、被測物件、工作產品及測試人員不同，相應的軟體測試級別劃分或分級是不同的。

四種軟體測試級別，如圖6.

圖6 軟體測試級別

1. 單元測試（元件測試）：

針對單個軟體單元的測試都可以稱為單元測試

在單元測試過程中，經常會用到樁、驅動器、模擬器

單元測試包括功能測試和特定的非功能測試

在寫程式碼之前就開始準備測試和自動化測試用例是單元測試常用的一種方法

單元測試的任務包括：模組區域性資料結構測試，模組引數邊界值測試，模組中所有獨立執行路徑測試，以及模組的各條錯誤處理路徑測試等

測試環境：當程式程式碼編寫完成並通過評審和編譯檢查後，便可開始單元測試

2. 整合測試的

整合測試也叫組裝測試、聯合測試，目的是檢驗軟體單元/系統之間的介面關係，是單元測試的邏輯擴充套件，其關注點是對單元之間的介面進行測試，以及檢查與系統其它部分相互作用的測試，是旨在暴露介面以及整合元件/系統間互動時存在缺陷的測試，整合測試驗證程式和概要設計說明的一致性，任何不符合該說明的程式模組行為都應該加以記載並上報。

3.系統測試

系統測試是將已經整合好的軟體系統作為計算機系統的一部分，與計算機系統硬體、某些支援軟體、資料和人員等系統元素結合起來，在實際執行環境下對計算機系統進行一系列嚴格有效的測試；系統測試對測試環境的要求是在整合測試完成後，系統已經完全組合起來後進行，應該在儘可能和目標執行環境一致的情況下進行；系統測試的目的是確認整個系統是否滿足了系統需求規格說明中的功能和非功能需求，以及滿足程度。

常見系統測試包括：壓力測試、容量測試、效能測試、安全測試、容錯測試等。

4.系統測試過程，如圖7。

圖7 系統測試過程

4.驗收測試

驗收測試通常由使用系統的使用者來進行測試

1.4.3軟體測試中的錯誤分級

對軟體錯誤進行級別定義或分級，目的就是科學地指導軟體測試工作，提高軟體測試的目的性，確保軟體測試的質量。軟體錯誤分級涉及到兩個方面：錯誤分類及錯誤級別劃分

。

1.錯誤級別劃分（按GB/T15532-2008劃分）:

第1級錯誤：

妨礙由基線要求所規定的執行或任務的主要功能的完成

妨礙操作員完成執行或任務的主要功能

危及人員安全

第2級錯誤：

給由基線要求所規定的執行或任務的主要功能的完成造成不利的影響,以致降低效能,且

沒變通的解決辦法，給操作員完成由基線要求所規定的執行或任務的主要功能造成不利的影響,以致降低效能，且沒有變通的解決辦法。

第3級錯誤：

給由基線要求所規定的執行或任務的主要功能的完成造成不利的影響,以致降低效能,但已知有變通的解決辦法

給操作員完成由基線要求所規定的執行或任務的主要功能造成不利的影響,以致降低效能，但已知有變通的解決辦法

第4級錯誤

這種軟體問題給操作員帶來不方便或麻煩，但不影響所要求的執行或任務的主要功能

第5級錯誤：所有的其他錯誤

1.5軟體缺陷

1.5.1 概念

軟體錯誤或軟體缺陷是軟體產品的固有成分，是軟體“生來具有”的特徵，軟體缺陷包括檢測缺陷和殘留缺陷。

一般符合下列5個規則之一，就是軟體缺陷。

軟體未實現產品說明書要求的功能

軟體出現了產品說明書指明不應該出現的錯誤

軟體實現了產品說明書未提到的功能

軟體未實現產品說明書雖未明確提及但應該實現的目標

軟體難以理解、不易使用、執行緩慢或者——從測試員的角度看——終端使用者會認為不好

1.5.2原因

導致軟體產生缺陷的九類原因：需求的不完善定義、客戶——開發者通訊失敗、對軟體需求的故意偏離、邏輯設計錯誤、編碼錯誤、不符合文件編制與編碼規定、測試過程不足、規程錯誤、文件編制錯誤。

1.5.3軟體缺陷基本屬性

①缺陷標識(Identifier)：缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識

②缺陷型別 (Type)：缺陷型別是根據缺陷的自然屬性劃分的缺陷種類。

③缺陷嚴重程(Severity)：缺陷嚴重程度是指因缺陷引起的失效對軟體產品的影響程度。

④缺陷優先順序(Priority)：缺陷的優先順序指缺陷必須被修復的緊急程度。

⑤缺陷狀態(Status)：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。

⑥缺陷起源(Origin)：缺陷起源指缺陷引起的失效或事件第一次被檢測到的階段。

⑦缺陷來源(Source)：缺陷來源指引起缺陷的起因。

⑧缺陷根源(Root Cause)：缺陷根源指發生錯誤的根本因素。

1.5.4軟體缺陷報告撰寫

1）可追蹤資訊——缺陷ID

(唯一的缺陷ID，可以根據該ID追蹤缺陷)

2）缺陷基本資訊，如圖8.

圖8 缺陷基本資訊

3）缺陷的詳細描述

描述應儘可能詳細

4）測試環境說明

對測試環境的描述