軟件測試基礎知識

第一章

1.1 軟件測試背景知識和發展史

互聯網公司職位架構：產品 運營 技術 市場 行政

軟件測試：使用人工或自動化手段，來運行或測試某個系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別（IEEE）。

測試結果：1）找出缺陷和故障? ? 2）顯示軟件執行正確

1.3測試的必要性

測試的必要性：1）避免金錢、名譽甚至生命損失?2）提高軟件質量

軟件測試開始時間：貫穿于軟件生命周期始終，越早開始越好。

出現軟件缺陷的時間：說明書，設計，編碼，其他

軟件缺陷修復費用，越晚費用越高。

1.4軟件測試的目的和對象

軟件測試目的：

1）測試者：通過軟件測試暴露軟件中隱藏的錯誤???? 和缺陷，以考慮用戶是否可接受該產品。

2）開發者：希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。

軟件測試的根本目的：1)發現\修改缺陷 2)滿足需求提高用戶滿意程度 3)優化軟件品質

軟件測試對象：不是程序測試。需求規格說明、概要設計規格說明、詳細? ?????? ?????? ?????? ?????? 設計規格說明以及源程序、用戶文檔。（程序、文檔、數據）

1.8軟件測試的原則

測試原則：

1）盡早地和及時地進行測試

2）測試前應準備好測試數據和與之對應的預期結果

3）測試輸入數據應包括合理是輸入條件和不合理的輸入條件

4）程序提交測試后，應當由專門的測試人員進行測試

5）嚴格執行測試計劃，排除測試的隨意性

6）測試用例的所有相關預期結果做全面的檢查

7）充分注意測試當中的群集現象

8）保存測試計劃、測試用例、出錯統計和最終分析報告，為維? ?????? 護工作提供充分的資料。

測試的補充原則：優化測試量

缺陷具有免疫性：每修補3-4?個bug，一般就會產生一個新的缺陷。

1.9軟件測試誤區

誤區一：軟件測試技術比編程容易

誤區二：若發布的軟件有質量問題，那是軟件測試人員的錯

誤區三：軟件測試是測試人員的事，與開發人員無關

誤區四：根據軟件開發瀑布模型，軟件測試是開發后期的一個階段

誤區五：有時間就多測試一些，來不及就少測試一些

誤區六：軟件測試是非建設性的工作，甚至是破壞性的，測試中發現錯誤是對負責人工作的一種否定。

1.10軟件開發過程及項目成員

軟件開發項目過程：

（生命周期）：需求分析，系統設計，編碼，實施，交付。

軟件項目開發過程分解

需求分析：深入了解客戶需求，根據用戶需要、個人經驗及需求編寫規范制定出《需求文檔》， 需求文檔需要經過評審，充分獲取軟件開發的范圍、邊界等具體問題的確認，且經相關部門評審合格即付諸后續工作

系統設計：需求評審通過后，開發部組織人員根據《需求分析書》并結合編寫規范進行系統設計（概要設計+詳細設計），制定出詳細設計方案。概要設計：系統的基本流程，系統結構，模塊劃分，功能分配，接口設計等； 詳細設計：設計每個模塊的實現算法、所需的局部數據結構，類的層次結構及調用關系。

編碼：系統設計完成后并經過評審通過后，開發人員依據《系統設計方案》并依據《代碼編寫規范》進行代碼編制，實現各模塊功能、性能、接口、界面等方面的需求。

實施：軟件編碼完成后，并經過內部人員測試，由開發部組織人員依據測試完成的系統軟件并結合軟件系統實施規范進行軟件實施，即正式部署到用戶的生產運行環境上。

交付及驗收： 實施完成并經用戶確認后，由質量保證部協助用戶根據驗收計劃和驗收規范來進行驗收，驗收完成后，提交驗收報告，軟件開發及實施全部完成，標志該項目完成。

軟件項目成員及角色：項目經理、產品經理（專員）、軟件開發人員、軟件測試人員/QA、文檔編寫人員、配置管理人員。

1.11軟件開發模型

軟件開發模型概述：軟件開發的全部過程、活動、任務和管理的結構框架。它給出了軟件開發活動各階段之間的關系。

開發模型分析

大棒開發法 優點：思路簡單，突發奇想 缺點：非工程化，隨意性大，結果不可預知 測試：開發任務完成后，修復較困難。

邊寫邊改法 優點：簡單考慮到軟件需求，產品周期短 缺點：沒有計劃和文檔的編制，后續維護難度大 測試：新版本不斷產生，測試工作長期循環。

快速原型法 根據客戶需求在較短的時間內解決用戶最迫切的問題，完成可演示的產品。這個產品只實現最重要功能，在得到用戶的更加明確的需求之后，原型將丟棄。

瀑布模型 特點：逐級下落 將軟件生存周期各活動規定為依線性順序連接的若干階段的模型，包括需求分析、概要設計，詳細設計、編碼、測試和維護等階段。 優點：易理解，階段性，強調需求分析，明確測試階段，提供了一套模版

5）螺旋模型法：

當前階段開發和測試，明確并化解風險，確定目標、可選方案和限制條件，確定下一階段方法，計劃下一階段，評估可選方案

優點：嚴格的全過程風險管理；強調各開發階段的質量；提供機會評估項目是否有價值繼續下去（發現問題早）

1.12軟件測試模型

V模型

特點：瀑布模型的變種，反映了測試活動與分析、設計的關系。是最具有代表意義的測試模型。

優點：開發級別清晰，測試階段對應。底層：單元測試。高層：系統測試。

缺點：線性執行——測試滯后編碼

關注程序——忽略需求、設計

需求變更——實用性差

W模型=V模型+各階段同步測試 （體現了盡早地和不斷地進行軟件測試原則）優點：W模型可以說是V模型自然而然的發展。它強調：測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、功能、設計同樣要測試。

缺點：在小的項目里面，W模型不適用，不支持迭代，應對需求變化方面不適用。

H模型 揭示出軟件測試應盡早準備盡早執行。是一個獨立的流程，貫穿于整個產品周期，與開發并行。

1.20軟件測試流程

測試過程中基本測試活動

擬定軟件測試計劃

設計和生成測試用例（格式還是測試點）

搭建測試環境

實施測試

測試評估

測試總結

測試計劃：階段主要處于測試的前期準備工作階段，在該階段中主要是對將要進行的測試工作做整體計劃安排。

測試計劃制定：對需求規格說明書的仔細研究，將要測試的產品分解成可獨立測試的單元，為每個測試單元確定采用的測試技術，為測試的下一個階段及其活動制定計劃。

測試開發與設計：開發：測試數據準備，測試腳本準備

設計：熟悉需求分析的基礎上，測試用例

測試用例文檔：軟件測試的依據，包括測試輸入、測試步驟、預期結果等內容。本質：從測試的角度對被測對象的功能和各種特性的細化和展開。好處：（1）保證測試功能不被遺漏，也不重復（2）合理安排測試人員（3）使得軟件測試不依賴于個人

實施測試：執行用例腳本-記錄測試結果-缺陷提交、跟蹤及管理-回歸

初測期：測試主要功能和關鍵的執行路徑，排除主要障礙。

細測期：依據測試計劃和測試用例、逐一測試大小功能、各方面特性、性能、用戶界面呢、兼容性、可用性等等；預期可發現大量不同性質、不同嚴重程度的錯誤和問題。

回歸測試期：系統已達到穩定，在議論測試中發現的錯誤已十分有限；復查已知正情況，確認未引發任何新的錯誤。

評估：測試過程、產品。評估-總結-測試總結報告。

測試流程與測試文檔 擬定測試計劃：測試計劃方案 評審測試計劃

設計與開發：測試用例 測試腳本

實施測試：缺陷報告 測試記錄 用戶文檔

測試評估：測試總結報告

1.21軟件測試計劃

軟件測試計劃（定義）：軟件測試正式實施之前明確測試對象，并通過對資源、時間、風險、測試范圍和預算等方面的綜合分析和規劃。意義：保證有效的實施軟件測試。

目的：把知識和經驗直接轉化為執行任務的具體方法?為組織、安排和管理測試項目提供一個整體框架促進團隊間關于測試任務和過程的交流?分析項目執行過程中的風險，并制定應對策略

時間：需求說明書確定之后（盡早）

測試計劃在測試活動中處于中心位置，它設定了測試準備工作和執行測試的必備的條件，同時形成了測試過程質量保證的基礎。

使用和維護：使用過程中必要的檢測，經評審，是否需要調整和修改，項目是否按照計劃執行

基本結構：簡介，項目說明，范圍，手段和策略，標準，原則，可交付性，任務分配，環境需求，職責，人員和培訓需求，進度表，風險及偶然事故的預測。

要求：指導測試工作，用戶是特殊用戶：按用戶要求填寫。

第二章

2.1軟件測試環境搭建

為何搭建測試環境：對線上環境產生影響。（生產環境【也包括測試生產環境】 預發布環境 正式環境）

搭建測試環境原則：真實：項目軟件（針對性） 產品軟件（普遍性）

干凈：除去多余的

獨立：開發環境與測試環境 測試環境與測試數據庫

無毒：各種殺毒軟件

環境介紹：B/S結構 C/S結構 移動端 APP 嵌入式設備

2.2測試用例相關

測試用例：為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果等信息的一個特定集合。

解決的問題：測什么，怎么測，如何衡量

時間：測試計劃評審通過后開始進行，正式執行測試前完成。

好處：理清思路，避免遺漏，跟蹤測試進展，歷史參考，重復性

作用：實施測試指導，指導腳本編寫，出具測試報告，分析缺陷的基準依據。（以測試用例為依據，測試結束后，總結出：bug數量，有效bug，無效bug）

內容：參考需求文檔，編號（拼音縮寫+數字）

– 測試步驟：操作描述

– 輸入數據：測試數據

– 期望結果：程序應該輸出的結果

– 測試結果：程序實際輸出的結果（yes/no）

測試用例管理工具：BugFree，QC，TD禪道，Redmine

測試用例更新和維護的原因： 需求變更、功能變化，測試用例也需要更新，測試用例需要細化和不斷完善，是個循序漸進的過程。

測試用例要經過正式、有效的評審：集眾人的經驗及認識于一體，對測試用例進行查漏補缺，使得測試用例的有效性進一步提升。

黑盒測試用例設計方法：等價類劃分法、邊界值分析法、因果圖法

白盒測試用例設計方法：語句覆蓋，邏輯覆蓋，條件覆蓋

黑盒測試：在完全不考慮程序內部結構和內部特性的情況下檢測每個功能是否正常使用。

白盒測試：結構測試，透明盒測試，邏輯驅動測試或基于代碼的測試

靜態測試：不運行程序，只對程序進行檢查和審核

動態測試：使用和運行程序進行檢查

2.3等價類劃分法

定義：依據需求對輸入的范圍進行細分，然后再分出的每一個區域內選取一個有代表性的測試數據開展測試。

有效等價類：符合需求說明，合理地輸入數據集合

無效等價類：不符合需求說明，無意義地輸入數據的集合

步驟總結：劃分等價類，編號，覆蓋有效等價類，覆蓋無效等價類

2.4邊界值分析法

定義：對輸入或輸出的邊界值進行測試的一種測試方法。（通常作為對等價類劃分法的補充。）

選取三種情況，=?

情況：被測對象跟數量有關系

2.5黑盒測試——常用控件測試方法

文本框測試

數據內容、長度、類型（注：大小寫）、格式（行、日期）、唯一性、空、空格、復制/粘貼+手動、特殊字符、功能鍵等。

步驟

按鈕測試 – 按鈕功能是否實現（關聯）

– 提示信息是否正確（正確、友好、無法恢復時）

黑盒測試——錯誤推測法

定義：借助測試經驗開展測試的一種方法，基于經驗和直覺推測軟件中容易產生缺陷的功能、模塊，及各種業務場景等，并依據推測逐一進行列舉，從而更有針對性的設計測試用例。

前提：深度熟悉被測系統，系統的分析過已有的缺陷

經驗分享：時間性測試 密碼輸入框缺陷 配置文件安全性 同時操作問題

2.7測試數據準備

測試數據影響測試質量，影響測試環境。

來源：錄入數據，已有系統數據

要求

功能測試不需要大量數據

功能測試覆蓋率高

功能測試盡量真實

性能測試需要大量數據

性能測試盡可能的達到符合實際的數據分配

2.8白盒測試——靜態測試

白盒測試又稱結構測試，邏輯驅動測試，基于代碼的測試。

靜態測試

代碼檢查法（變量，子程序、宏、函數，等價性，常量，風格，補充文檔）

內容：

i.代碼和設計的一致性

ii.代碼對標準的遵循、可讀性

iii.代碼邏輯表達的正確性

iv.代碼結構的合理性等方面

方法

i.桌面檢查：自己檢查代碼，編譯、分析、檢驗、補充文檔（目的：發現程序中的錯誤）

ii.代碼走查：發資料、開會運行

Iii.代碼審查：發材料、開會講解

靜態結構分析法

I.定義：靜態結構分析工具分析程序源代碼的內部結構

i.系統結構，數據結構，數據接口，內部控制邏輯

ii.可生成的分析文檔 函數調用關系圖，模塊控制流程圖，內部文件調用關系圖，子程序圖，宏和函數參數表

代碼質量度量

i.ISO 9126國際標準定義：功能性，可靠性，易用性，效率，可維護性，可移植性

ii.代碼行度量法 代碼行數 bug率（千行代碼內bug的數量）

iii.McCabe度量法 （V(G)＝m－n＋2 弧-結點+2 控制流程畫對）

iv.Halstead軟件科學法（程序=運算符號 + 運算對象結構度量）

v.結構度量

n1=不同運算符的個數? – + - * / = if else for ……

n2=不同運算對象的個數

? 扇入：調用該模塊的模塊計數；

? 扇出：該模塊所調用的模塊計數；

? 使用扇入、扇出來評價軟件設計

– 具有大扇入和大扇出的模塊可能是不良設計。

這種模塊可能未能正確分解并需要重新設計。

– 程序復雜性與扇出的平方成正比

動態白盒測試

靜態檢查

代碼檢查法

靜態結構分析法

靜態質量度量法

動態檢查——邏輯覆蓋

語句覆蓋

判定覆蓋

條件覆蓋

1.邏輯覆蓋：通過程序邏輯結構的遍歷實現程序的覆蓋

2.語句覆蓋：一個比較弱的測試標準，設計若干測試用例，使得程序中每個可執行語句至少都能被執行一次。

3.判定覆蓋(分支覆蓋)：每個分支至少獲得一次“真值”或“假植”，比語句封蓋稍強的測試標準

4.條件覆蓋：每個條件的可能取值至少滿足一次。每個條件都真一次假一次。

5.判定-條件覆蓋：使得判定中所有條件至少執行一次取值，同時，使得所有判定的可能至少執行一次。（全部真全部假）

6.條件組合測試：使得判定中條件的各種組合都至少執行一次。（如圖都試一遍）

7.路徑測試：相當強的覆蓋標準，足夠多的測試用例，覆蓋程序中所有可能的路徑。（每一條路都試過 三個字母涵蓋每條路徑）

第三章

3.1軟件缺陷相關

定義：產品內部：產品開發或維護過程中所存在的錯誤、毛病等各種問題。產品外部：系統所需要實現的某種功能的失效或違背。

滿足以下規則之一稱發生一個缺陷：

為實現產品說明說要求的功能

出現產品說明書指明不該出現的錯誤

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

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

軟件難以理解，不易使用，運行緩慢或者用戶認為不好

產生原因及修復成本

解決問題想法 溝通 需求評審 設計評審 文檔更新即使 開發測試

缺陷報告

用途：記錄缺陷，缺陷分類（為解決缺陷分配資源）缺陷跟蹤

編寫：使非缺陷報告撰寫者依據缺陷報告（簡單、迅速）重現缺陷。包括重現缺陷的必要步驟。一個缺陷一個報告。

嚴重性和優先級

– Fatal：致命的錯誤，造成系統或應用程序崩潰、死機、系統懸掛，或造成數據丟失、主要功能完全喪失等。

– Critical：嚴重錯誤，主要指功能或特性沒有實現，主要功能部分喪失，次要功能完全喪失，或致命的錯誤聲明。

– Major：主要錯誤，這樣的缺陷雖然不影響系統的使用，但沒有很好地實現功能，沒達到預期效果。如提示信息不太準確，或用戶界面差，操作時間長等。

– Minor：一些小問題，對功能幾乎沒有影響，產品及屬性仍可使用。

– Suggestion：一些友好的建議。

缺陷狀態及周期性

定義：缺陷通過一個跟蹤修復過程的進展情況，也就是在缺陷生命周期中的狀態基本定義。

狀態：激活或打開、已修正、關閉或非激活、重新打開、推遲、保留、不能重現、需要更多信息、重復、不是缺陷、需要修改軟件規格說明書。

周期

第四章

4.1單元與單元測試概念

單元：一個最小的單元應有明確的功能、性能定義、接口定義而且可以清晰地與其他單元區分開來。例如：面向過程語言（C、VB單元）一個或若干個函數或過程 面向對象（JAVA、C++、C#）一個類或類的實例，或者由方法來實現的功能 網頁或用戶窗口界面單元 一文字輸入窗口或一個按鈕

單元測試（Unit Testing模塊測試）：針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試工作。程序單元是應用最小可測試部件。

單元測試關注點

目標：確保每個模塊能正常工作

時間：編碼——編譯——單元測試

注意：前期完成單元測試計劃、設計好用例

依據：詳細設計說明

執行者：程序開發者或白盒測試人員

操作：以白盒測試法為主，先靜態檢查分析（檢查編碼規范）代碼是否符合規范，再動態（邊界值，非法數據容錯性）運行代碼（編譯，語法問題；運行，測試數據；輸出結果比較），檢查結果。

4.3單元測試的執行過程

單元測試時，若模塊不是獨立的程序，需要設置一些輔助測試模塊。

驅動模塊（Drive）：模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數據，將相關數據傳送給被測模塊，啟動被測模塊，并打印出相應的結果。

樁模塊（Stub）：測試被測模塊工作過程中所調用的模塊。一般只進行很少的數據處理。

單元測試工具

常用 main函數、C++ Test、JUnit、NUnit

實施測試：單元測試，集成測試，系統測試，驗收測試

4.5集成測試

集成測試（integration test）：是每個模塊完成單元測試后，按照設計時確定的結構圖，將它們連接起來進行測試。（綜合測試、組裝測試、聯合測試）

時間：單元—集成（理論）同步進行（真實工作中）

注意：前期完成繼承測試計劃，設計好用例。

依據：概要設計說明書。

內容：

方法：非增量：一步到位的方法構造測試。優點：節省時間。缺點：新舊故障混雜，一次集成的模塊較多時，容易出現混亂。故障定位和糾正比較困難。增量式：逐步集成方式實現測試。方式：自底向上，自頂向下，混合增量。

自頂向下：深度、廣度優先，逐步集成、測試。

主控模塊：關鍵模塊。

主控模塊特征：滿足某些軟件的主要需求；在程序的模塊結構中位于較高層次（高層控制模塊）；較復雜、交易發生錯誤；有明確定義的性能要求。

測試過程：主控模塊作為測試驅動器；根據集成方式，下層樁模塊一次次被替換為真正的模塊；每個模塊被2集成時，都必須進行單元測試。

測試方式：深度優先方式集成（集成在結構中的一個任意主控路徑下的所有模塊）；

廣度優先方式的集成：沿水平方向，把每一層所有直接隸屬于上一層的模塊集成起來，知道底層。

b)自底向上：逐步集成、測試

c)混合增量式：自頂向下+自底向上=兼具優點，摒棄缺點。

測試方式：對輸入輸出模塊和引入新算法模塊的測試。調用模塊多：自底向上。被調用模塊多：自頂向下。

測試方法比較

非增量式：先分散再集中，若在模塊接口處存在錯誤，只在最后的集成測試時暴露，修改難度大。

增量式：逐步集成和測試，差錯分散暴露，一些模塊得到較多次的考驗。

自頂向下 優點：逐步求精，開始就能看到系統的框架，發現上層接口不需要驅動模塊。缺點：需要提供樁模塊，底層關鍵模塊中錯誤發現較晚。在輸入/輸出模塊加入系統以前，在樁模塊中表示測試數據有一定困難。

自底向上 優點：最常用，可發現底層模塊錯誤，由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，容易生成測試數據。缺點：直到最后一模塊被加進去之后才能看到整個程序（系統）的框架。

系統測試

1定義：將軟件系統看作一個整體急性測試，包括對功能性能等，以及將計算機硬件、某些支持軟件、數據和人員等系統元素結合起來，在實際運行環境下對軟件進行測試。

系統測試——功能測試

定義：對產品各功能點進行驗證。根據需求規格說明書和功能測試用例，逐項測試以檢查產品是否到達用戶的要求。

方法：（1）分析產品/產品所有功能。

逐個功能分析測試點

等價類劃分

對每個定價類進行邊界值分析

對子功能使用錯誤推測法分析

4.8系統測試——易用性測試

定義：交互的適應性、功能性和有效性的集中體現。

內容 （1）UI測試（頁面、遙控器按鍵）

易用性功能

標準和規范：風格，錯別字

直觀：潔凈，合理，清晰

一致：遵循標準 例：快捷鍵和菜單選項（賦值，粘貼）

靈活：狀態終止和跳轉，數據輸入輸出。

舒適

正確：語言拼寫，文件和屏幕一致。

實用：是否有實際價值。

輔助選項測試：殘疾障礙測試。

輔助特性 提供輔助方式：操作系統內置，平臺 遵守啟用輔助選項：鍵盤、鼠標、聲卡。若被測軟件本身就是平臺，就需要定義、編制和測試自己的輔助選項。

Windows提供的輔助選項粘貼鍵? 篩選鍵? 切換鍵? 聲音衛士（每當系統發出聲音時，給出警告）? 聲音顯示（讓程序顯示其聲音或講話的標題，需要在軟件中編制）等等。

4.9系統測試——兼容性測試

定義：檢查軟件之間是否能夠正確地交互信息和共享信息。

原因：軟件越來越多，保證這些通用軟件支持跨平臺、跨支撐軟件運行

標準

向后兼容：可以使用軟件的以前版本

向前兼容：可以使用軟件以后的版本

高級標準和規范：遵守平臺（操作系統）的標準

低級標準和規范：產品本身的標準

內容：操作系統，應用軟件之間，數據庫，軟硬件配合。

平臺兼容性應用軟件選擇 （利用等價類劃分，使驗證軟件之間正確交互的最小有效集合）

流行程度：銷售記錄前100前1000個最流行的程序。

年份：近三年以內的程序和版本）。

類型：文字編輯，圖形，音頻，視頻，財務，數據庫等。

生產廠商：根據制作軟件的公司才選擇軟件。

數據兼容性

應用程序間共享數據，要求支持并遵守公開的標準，允許用戶與其他軟件無障礙的傳輸數據。

文件保存和讀取，只有符合標準才能在兩臺計算機上保持兼容。

文件導出和導入是許多程序與自身以前版本、其他程序保持兼容的方式。

數據被復制、剪切，當進行粘貼時，一些應用程序只接受特定數據類型和格式。

軟硬件配合兼容

新操作系統對于主流硬件型號上進行兼容性測試

新應用軟件對于主流硬件型號及主流操作系統的兼容性測試

B/S 架構的軟件，必須考慮瀏覽器的兼容性

移動端的軟件，必須考慮主流移動設備廠商的設備，主流平臺（Android,IOS等），主流屏幕大小等等

系統測試—安全性測試

定義：檢查系統對非法入侵的防范能力。

目的：驗證安裝在系統內的保護機制能否在實際中保護系統且不受非法入侵，不受非法干擾。（應對入侵）

方式：分析黑客攻擊系統的動機和角度。

常見安全問題：安全性威脅、跨站腳本攻擊、緩沖區溢出、SQL注入（穿過防火墻，入侵檢測系統，執行增、刪、改、查腳本，嘗試輸入特殊字符）、命令注入、格式化字符串、整數溢出。

4.11 回歸測試

定義：對軟件的新的版本測試時，對新版本進行重新測試，這時的測試不僅是驗證被修復的軟件缺陷是否被解決了，且要保證以前所有運行正常的功能依舊保持正常，而不要受到這次修改的影響。（為了修復一些問題而進行的版本升級）

測試用例選擇 再測試全部用例，基于風險選擇測試（最重要的、關鍵的和可疑的測試），基于操作剖面選擇測試（最重要或最頻繁使用功能），測試修改的部分（被改變的模塊和它的接口上）。

過程

識別被修改的部分

排除不適用用例，確定有效用例，建立新測試用例庫T0

從T0中選擇用例測試被修改的軟件

如有必要，生成T1，補充T0

用T1執行修改后的軟件

注意：（2）（3）驗證是否破壞現有的功能，（4）（5）驗證修改工作本身

4.12驗收測試

定義：對新版本重新測試，驗證被修復的軟件缺陷是否誒解決，保證以前所有運行正常的功能依舊正常，且不受的這次修改的影響。（為了修復一些問題而進行的版本升級）

時間人員：系統測試之后，用戶測試穩住，有時人員等質量保障人員共同參與的測試，是檢驗軟件產品質量正式交給用戶使用的最后一道工序。

內容

明確驗收項目，規定驗收測試通過的標準

確定測試方法

決定驗收測試的組織機構和可利用的資源。

選定測試結果分析方法。

指定驗收測試計劃并進行評審。

設計驗收測試所用的測試用例。

審查驗收測試準備工作。

執行驗收測試。

分析測試結果。

做出驗收結論，明確通過驗收或不通過驗收。

測試計劃內容：功能測試，逆向測試，特殊情況，文檔檢查，強度檢查，回復測試，可維護性，用戶操作，友好性，安全測試。

步驟：測試計劃-測試用例-執行用例記錄結果-分析測試結果-提交測試報告

實施策略：項目軟件驗收，產品軟件驗收。（選人，備材料，搭現場，討論過程，測試輔助，總結）

實施

Alpha測試(α測試內部測試)：軟件開發公司組織內部人員（用戶、測試人員、開發人員）模擬用戶測試。關鍵：逼真模擬運行環境和用戶操作，盡力涵蓋所有用戶操作。

Beta測試：公測。軟件開發公司組織各方面的典型用戶，實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發公司再對β版本進行改錯和完善。

技術

黑盒測試：執行用戶確認測試報告或需求規格說明，逐步進行至整個運作過程結束，并分析執行結果是否符合要求。

易用性測試：檢驗測試過程中對軟件的操作及反應的滿意程度，是否快捷、符合使用習慣，提出見解。

靜態測試：檢驗用戶手冊或相關文件，保證描述正確。

第五章

5.1軟件質量相關

質量范圍-3A

可說明性（acountability）：用戶可以基于產品或服務的描述和定義進行使用。

有效性（Availability）：產品或服務對于99.999%的客戶總是有效的

易用性（Accessibility）：對于用戶，產品或服務非常容易使用并且一定是非常有用的功能

質量視角：用戶，開發者

質量標準：產品質量（McCall ISO9126 Boehm），過程質量（CMM ISO9000）。

CMM五級模型

初始級

可重復級

定義級

定量管理級

（不斷）優化級

應用與數據集成平臺 ROMA Connect 自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。