Wondershare EdrawMind
心智圖資源庫 軟體系統測試知識點總結
- 19
軟體系統測試知識點總結
軟體系統測試基礎知識點總結，軟體測試是使用人工或自動的手段來運行或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清楚預期結果與實際結果之間的差別。
編輯於2024-01-12 16:00:06
- 推薦給您
- 大綱
系統測試
概念
軟體測試是使用人工或自動的手段來運作或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清楚預期結果與實際結果之間的差異。
內容
MCP
Minimal Concept Principle（最小概念原則）
軟體生命週期
計劃
確定開發目標：開發一款小型軟體
完成專案可行性研究：能不能做，做出來是否有意義
對專案進度進行預估與安排：人，時間預算
制定實施計劃
需求分析
分析整理專案需求項：需要開發的功能，詳細的特性
根據整理出的需求項，編製需求規格說明書（SRS：Software Requirement Specification）
製作產品原型
設計
完成專案概要設計
完成詳細設計
編碼
根據概要設計說明書以及詳細設計說明書，完成程式碼編寫
測試
單元測試：程式最小單元（函數或一個類別的程式碼）
整合：模組與模組之間介面進行測試
系統：對完成編譯的系統整體進行測試的過程
驗收：與客戶一起完成測試
運作與維護
產品部署
運作維護
功能升級
性能提升
常見測試模型
傳統瀑布模型
缺點：測試後置，開發完成後，修改成本大
V模型
特點：將測試流程細化，分為了單元測試、整合測試、系統測試和驗收測試四個不同的階段
缺點:測試後置，沒有解決風險問題
W模型
優點
①測試的活動和開發同時進行
②測試對像不僅是程序，還包括需求和設計
③儘早發現軟體缺陷可降低開發成本
缺點
無法支援靈活的版本迭代
敏捷開發模型
特點
敏捷開發與測試模型主要是為了適應現代網路公司「短平快」的開發節奏而設計的一種開發和測試模型
內容
①迭代：每次迭代叫做一個sprint，每個sprint裡面選出來要實現的需求會安排到sprint backlog裡面，每個sprint一般是以一個月作為週期
② Product Owner：相當於是產品經理。整理出整個專案的所有需求，並且依照需求的優先順序將需求排列到Produce Backlog
③ Daily Meeting：每日會議，一般是站會形式。每個人發言一般不會超過1分鐘，主要內容包括三點：昨天完成的工作、今天準備進行的工作、面臨的風險和問題
④ sprint burndown：迭代燃盡圖，記錄剩餘的工作量
⑤ sprint review meeting：迭代回顧會議，主要是去回顧在本輪迭代中存在的問題有哪些、如何改進等
⑥ scrum master：相當於組長，由他來統一管理組員
軟體品質模型
定義
軟體品質模型提供了從不同維度考慮產品品質屬性的依據
內容
功能性、可靠性、易用性、效能效率、相容性、安全性、維護性、可攜性
可移植性和相容性的區別：
可移植性是屬於產品的內部質量，更關注程式碼在不同的平台上是否可以正確的安裝和配置。
相容性是屬於產品的外部質量，更關注的是最終用戶能感知到的不同的瀏覽器、不同解析度、不同裝置之間的正確的使用及顯示。
測試方法
黑盒測試
指在不知道被測軟體程式碼結構的基礎上，根據產品需求規格、站在最終用戶的角度來對軟體的輸入和輸出進行測試的過程叫做黑盒測試
白盒測試
指基於被測軟體的程式碼和結構，對被測軟體的程式碼和結構本身進行測試的過程叫做白盒測試
灰盒測試
介於白盒和黑盒之間，一般來說灰盒是針對介面來進行測試，例如只知道函數的函數名稱、參數以及回傳值，並不知道函數內部的實作結構
整合測試
單元經過測試，底層軟體缺陷被找出並修復之後，就整合在一起，對模組的組合進行整合測試，較多涉及介面測試
確認測試
也叫冒煙測試，確認基本功能是否實現，一般不作為正式的測試環節
系統測試
系統所有功能的測試，模擬所有軟體使用者的操作
回歸測試
對軟體新版本測試時重複執行先前的測試案例
目的
①驗證之前缺陷已修復
②確認修復缺陷沒有引發新缺陷
驗收測試： 供需雙方以及第三方的測試，依據運行主題的不同可分為ɑ測試（內側）、β測試（公測）、γ測試
項目相關的文檔
開發階段主要文檔
需求規格說明書
摘要設計
詳細設計
測試階段主要文檔
測試計劃和方案
測試用例
缺陷報告
測試報告
方法
測試流程
分析
需求評審（需求評審檢查表）
需求從哪裡來，如果沒有需求怎麼辦？
需求評審怎麼評？
測試需求分析
為啥要做測試需求分析？
測試需求分析流程
得到測試點
計劃：測試計劃和方案文檔編寫
測試設計的概念
用例編寫
測試編號：TC TestCase
測試標題：用一句話來表達該條用例是測試哪個測試點的。
優先：高中低。作用是在專案時間不夠或人員不充足的時候，我們可以優先測試重點的測試案例
預置條件：執行該條用例時，系統必須預先達到的一個狀態或條件。可選，有就寫，沒有就不寫
測試步驟：詳細描述在測試這條用例時，需要進行哪些操作。
預期結果：來自於需求，要求我們達到的一個結果。
實際結果：實際作業系統之後得到的結果。
測試結果：pass/fail/NA pass 預期結果和實際結果相同。 fail 預期結果和實際結果不相同。 N/A 指目前使用案例不適用或無法操作
設計：測試案例設計
測試用例設計方法
等價類法
輸入域：所有使用者可以輸入內容的區域
等價類設計步驟
編寫等價類表，為每個輸入劃分等價類，得到等價類表，為每個等價類規定一個唯一編號
設計一個測試案例，使其盡可能多的覆蓋所有尚未覆蓋的有效等價類。重複此步驟，使得有效等價類均被被測試案例所覆蓋
設計一個測試案例，使其只覆寫一個無效等價類。重複此步驟使得所有無效等價類均被覆蓋
等價類劃分原則
如果輸入條件規定了取值範圍或值的個數，則可以確定一個有效等價類和兩個無效等價類
要求輸入年齡在18-25 歲之間，則 18-25 就是一個有效等價類，小於 18 和大於 25 就是兩個無效等價類
要求一個函數有3 個參數，則 3 個參數就是一個有效等價類，大於 3 個和小於 3 個都是無效等價類
輸入條件規定了輸入值的集合，或是規定了必須如何的條件，則可以確定一個有效等價類和一個無效等價類
例如要求輸入學歷值，學歷包含大專、本科、碩士、博士、博士後，那麼學歷中的這些值就是一個有效等價類，凡是不屬於這個學歷集合中的值就是一個無效等價類
在輸入條件是一個布林值的情況下，可確定一個有效等價類和一個無效等價類
例如要求輸入性別為女，那麼女就是有效等價類，男就是無效等價類。
如果我們確知，已經劃分的等價類中各個元素在程序中的處理方式不同，則應將此等價類進一步劃分
在規定了輸入資料必須遵守的規則的情況下，可確立一個有效等價類（遵守規則）和若干無效等價類（從不同角度違反規則）
要求輸入的資料必須是正整數，那麼正整數就是一個有效等價類，無效等價類可以是0 ，負數、小數
邊界值法
定義
1.對程式的輸入和輸出邊界進行測試的一種黑盒用例設計方法，常與等價類設計法結合使用，此時它的用例來自於等價類的邊界。
2.邊界值分析法的理論基礎是假定大多數的錯誤是發生在各種輸入條件的邊界上，如果在邊界附近的取值不會導致程式出錯。那麼其他的取值導致程式錯誤的可能性也很小。
3.邊界值使用條件（重點：可度量）
輸入條件明確了一個值的值範圍，或是規定了值的值個數
輸入條件明確了一個有序集合
相關概念
上點：邊界上的點
離點：離邊界最近的點
內點：取值域內的任一點
每個點一定是不同的數字，不可能一個點既是上點又是離點
上點：範圍中你看到的那兩個點一定是上點
用例步驟
分析輸入參數的類型：從測試規格分析得到輸入參數類型
等價類劃分（可選）：對於輸入等價類劃分方法進行等價類的劃分確定邊界：運用域測試分析方法確定域範圍的邊界（上點、離點與內點）
形成測試項：選擇這些上點、離點與內點或這些點的組合形成測試項
分析原則
如果輸入（輸出）條件規定了取值範圍，則應以該範圍的邊界內的及邊界附近的值作為測試案例
如果輸入（輸出）條件規定了值的個數，則用最大個數、最小個數，比最小個數少1，比最大個數多1的數作為測試案例
如果程式規格說明中提到的輸入或輸出是一個有序的集合，應該注意選取有序集合的第一個和最後一個元素作為測試案例
如果程式中使用了一個內部資料結構，則應該選擇這個內部資料結構的邊界上的值作為測試案例
使用場景：把輸入條件分成多個不同的子條件，條件與條件相對獨立，沒有限制關係
判定表法
定義（是否）
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。
條件樁
列出系統所有輸入，列出的輸入次序沒有影響
條件項
列出針對它左列輸入條件的取值，在所有可能情況下的真假值
動作樁
列出系統可能採取的操作，這些操作的排列順序沒有約束
動作項目
列出在輸入項目的各種取值情況下應該採取的動作
設計步驟
確定規則的個數。如這裡有3個條件，每個條件有兩個值，故應有2*2*2=8種規則
列出所有的條件樁和動作樁
填入條件項
填入動作樁和動作項
化簡，合併相似規則
將每條規則轉化為用例
流程分析法
定義
流程分析法（又稱場景設計法）是將軟體系統的某個流程看成路徑，用路徑分析的方法來設計測試案例。 依照流程的順序依序進行組合，使得流程的各個分支都能走到。 這是從白盒測試中路徑覆蓋分析法中推廣到黑盒測試中來的測試分析方法。
概念
基本流程：指所有操作都正確的主流程
備選流程：指部分操作不正確的流程分支
設計步驟
畫出業務流程圖
設定功能路徑優先權
確定測試路徑
選取測試數據
構造測試用例
範例：某嵌入式系統中，將待傳送的資料打包為符合CA協定的訊框格式後，便可寫入發送緩衝區.，並自動傳送。
1.進入發送子程序
2. 系統判斷是否有空閒發送緩衝區，如果沒有則返回，顯示發送失敗訊息
3.如果有空閒緩衝區將封包寫入空閒發送緩衝區
4.系統判斷是否寫入成功，如果不成功則返回，顯示發送失敗訊息
5. 如果寫入成功，則啟動發送命令
6.返回發送成功訊息
錯誤猜想法
定義
錯誤猜測法就是根據經驗猜想可能有什麼問題並依此設計測試案例
錯誤測法只能作為測試設計的補充而不能單獨用來設計測試用例.否則可能會造成測試的不充分
錯誤猜測不是瞎猜，不是沒有根據和目的的猜測.它需要依據對系統薄弱地方的了解和對開發人員盲點的了解
例子
a = [3,5,8,9,2,4]
重複
[1,1,1,1,1,1,1]
非數字
[1,2,3,a,7,6,5]
列表為空
: [] [67]
順序問題
[1,2,3,4,5,6] [6,5,4,3,2,1]
業務熟悉程度、程式設計經驗的豐富度
測試用例設計總結
測試案例設計方法很多，我們不僅要知道每種方法怎麼用，更需要清楚每種方法使用的場景。
等價類和邊界值是任何其他測試設計方法的基石，必須先考慮使用等價類和邊界值進行使用案例設計。
當輸入域與輸入域之間有約束關係 ，必須使用 判定表來進行組合。
在考慮了所有測試案例設計方法後，最後也要使用錯誤猜測法來補充，以免遺漏。
在測試某一個欄位時，應確保其他欄位的取值是一個正常值。
實作：編寫測試案例、測試腳本等
測試點的分析與擷取
做測驗前思考的問題
你知道要測試的系統是做什麼的嗎？
你了解系統有哪些特色嗎？
你知道系統有哪些功能嗎？
你知道系統的業務流程是什麼嗎？
系統在這個版本上，哪些需要測試，哪些不需要測試？
系統對效能、安全性有沒有什麼要求？
測試需求分析流程
1、根據產品需求提取系統的測試點
1.首先檢查介面元素的顯示是否正確
2.測試頁面的基本功能。如果頁面既有表單也有列表，則優先測試表單功能是否正常
3.針對表單在測試時，需要依據表單裡面的每個欄位依序進行測試。凡是使用者可輸入的輸入域，都要使用等價類別和邊界值根據欄位的限制來進行考慮
4.如果多個欄位之間有關聯關係和限制關係，那麼在測試完單一欄位的等價類別和邊界值之後，應該繼續使用判定表等測試方法進行組合的測試
5.表單測試完後，再測試清單中的功能
6.當單一頁面的內容都測試完畢後，再來結合流程分析法（場景法）測試流程相關的內容
7.流程分析測試完後，最後再使用錯誤猜測法來確保沒有遺漏的測試點
8.例子
2.編寫需求追蹤矩陣
需求追蹤矩陣指的是根據產品需求和測試點以及測試案例，建立一個三者映射的列表，這個表叫做需求追蹤矩陣
需求追蹤矩陣的作用
建立產品需求、測試需求與測試案例之間的映射關係，方便進行使用案例需求覆蓋率統計
如果需求發生變更，可以根據需求追蹤矩陣快速定位哪些測試案例需要更新
3.根據測試點利用適當的測試案例設計方法設計測試案例
執行：搭建測試環境、執行測試腳本、缺陷報告
建構測試環境
伺服器環境搭建
JDK的安裝
JDK的安裝主要是為了提供 JAVA 的運作環境。 （TOMCAT伺服器是由 java 寫的，所以要執行tomcat 必須先設定好 JAVA 運行環境）
JAVA_HOME:你安裝 JDK 的路徑
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
在Path 環境變數中，加入 %JAVA_HOME%\jre\bin 和 %JAVA_HOME%\bin 這兩個路徑
TOMCAT的安裝
tomcat作為主要的web伺服器，負責處理客戶端發送的所有請求
把tomcat壓縮包解壓縮到一個不含中文或特殊字元的路徑下
CATALINA_HOME：你解壓縮tomcat包的路徑
在Path環境變數中，新增%CATALINA_HOME%\bin路徑
透過雙擊bin目錄下，startup.bat這個檔案來啟動tomcat
MYSQL資料庫的安裝
Mysql資料庫主要用於管理系統數據
透過wampserver工具包安裝mysql應用，並透過wampserver啟動mysql和apache伺服器
被測系統相關的設置
將被測系統的 war 套件放置到 tomcat 指定的路徑中
將資料庫對應的 sql 檔案匯入到資料庫中，並且修改 mysql 資料預設的密碼
啟動伺服器，存取被測系統。網址是： http://localhost:8080/mms/login.html
環境變數
環境變數其實是一種系統的設置，透過這些設定我們可以告訴電腦我們要運行的目標檔案在什麼位置
缺陷報告
缺陷的定義
軟體沒有實現產品的說明書所描述的功能
軟體實現了產品說明書描述不應有的功能
軟體執行了產品說明書沒講的操作
軟體沒有實現產品說明書沒講但應該實現的功能
從軟體測試員的角度來看，軟體難以理解、不易使用、運作緩慢，或最終使用者認為不對
缺陷管理
掌握軟體缺陷的生命週期
掌握高品質缺陷報告的填寫方法
一個完整的測試報告
缺陷編號
預置條件
缺陷標題
測試步驟
嚴重程度
優先權
重現率
缺陷狀態
掌握軟體缺陷的相關屬性
缺陷嚴重程度
嚴重性
項名思義就是軟體缺陷對軟體品質的破場程度，也就是此軟體缺陷的存在將對軟體的功能和效能產生怎樣的影響
致命
例如，軟體的意外退出甚至作業系統崩潰，造成資料遺失
嚴重
例如，由於單功能失效導致多個相關功能失效
一般
例如，軟體的單一功能失效
提示
軟體介面的細微缺陷，例如，某個控制項沒有對齊，某個標點符號遺失等
缺陷狀態分類
了解軟體缺陷管理的常用工具
了解缺陷衝突中一些常見的問題
如何處理不能重現的缺陷？ 一定要提交到缺陷管理庫！
1. 一定要詳細描述遇到缺陷的流程和相關環境配置。如果有日誌的話，一定要附上相關的操作日誌或系統運作日誌。
2. 對於不可重現的缺陷，一定要盡量描述清楚復現率是多少。
3. 對於不可重現的缺陷，當開發人員將缺陷設為fixed之後，在驗證時，不能只在一個版本上去驗證缺陷是否修復，必須至少在3個以上的版本上驗證後都沒有重現過，才能將缺陷關閉。
執行測試的全流程
回歸測試的目的：1. 檢查缺陷是否真的被修復了。 2. 程式設計師在修復缺陷的過程中有沒有引入新的缺陷。
回歸測試和驗收測試
回歸測試
定義
修改程式碼後，重新進行測試
目的
檢查缺陷是否真的被修復
程式設計師在修復缺陷中是否引入新的缺陷
流程
1.在測試策略制定階段，制定迴歸測試策略
2.確定需要迴歸測試的版本 Version，哪個版本上bug被修改了就在哪個版本上回歸
3.回歸測試版本發布，依照回歸測試策略執行迴歸測試
4.回歸測試通過，關閉缺陷報告單
5.回歸測試不通過，缺陷報告單返回開發人員，開發人員重新修改問題，再次提交測試人員回歸測試
策略
完全回歸
重新執行所有在前期測試階段建立的測試案例，來確認問題修改的正確性和修改的擴散局部影響性
選擇性迴歸
即選擇性地重新執行部分在前期測試階段建立的測試案例，來測試被修改的程序
方法
覆蓋修改
針對被修改的部分，選取或重新建構測試案例驗證沒有錯誤再次發生的用例選擇方法
週邊影響
包含覆蓋修改法確定的用例，也要分析修改的擴散影響，驗證是否有其他部分被影響
指標達成
驗收測試
定義
在通過了內部系統測試之後，就可以開始驗收測試
驗收測試是以使用者為主的測試，驗收群組應該由專案組成員、使用者代表等組成
驗收測試原則上在使用者所在地進行，但如經使用者同意也可以在公司內模擬使用者環境進行
驗收測試根據合約、《需求規格說明書》或《驗收測試計畫》對成品進行驗收測試
對於產品型的項目，驗收測試一般又分為α測試（內測：在開發環境下進行）和β測試（公測：實際使用環境下測試）兩種
生命週期測試方法對比
編寫測試報告（每家公司都有範本）
目的
概述
被測對象
測試特性
測試結論
時間、地點、人員
環境
測試組網圖
硬體環境
軟體環境
總結評價
相關數據統計
軟體測試
概念
軟體測試是使用人工或自動的手段來運作或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清楚預期結果與實際結果之間的差異。
內容
MCP
Minimal Concept Principle（最小概念原則）
軟體生命週期
計劃
需求分析
設計
編碼
測試
運作與維護
常見測試模型
傳統瀑布模型
V模型
W模型
敏捷開發模型
軟體品質模型
測試方法
黑盒測試
白盒測試
灰盒測試
整合測試
確認測試
系統測試
回歸測試
驗收測試
項目相關的文檔
開發階段主要文檔
需求規格說明書
摘要設計
詳細設計
測試階段主要文檔
測試計劃和方案
測試用例
缺陷報告
測試報告
方法
測試流程
分析
計劃：測試計劃和方案文檔編寫
設計：測試案例設計
實作：編寫測試案例、測試腳本等
執行：搭建測試環境、執行測試腳本、缺陷報告
執行測試的全流程
回歸測試的目的：1. 檢查缺陷是否真的被修復了。 2. 程式設計師在修復缺陷的過程中有沒有引入新的缺陷。
回歸測試和驗收測試
回歸測試
驗收測試
生命週期測試方法對比
編寫測試報告
軟體生命週期
計劃
確定開發目標：開發一款小型軟體
完成專案可行性研究：能不能做，做出來是否有意義
對專案進度進行預估與安排：人，時間預算
制定實施計劃
需求分析
分析整理專案需求項：需要開發的功能，詳細的特性
根據整理出的需求項，編製需求規格說明書（SRS：Software Requirement Specification）
製作產品原型
設計
完成專案概要設計
完成詳細設計
編碼
根據概要設計說明書以及詳細設計說明書，完成程式碼編寫
測試
單元測試：程式最小單元（函數或一個類別的程式碼）
整合：模組與模組之間介面進行測試
系統：對完成編譯的系統整體進行測試的過程
驗收：與客戶一起完成測試
運作與維護
產品部署
運作維護
功能升級
性能提升
常見測試模型
傳統瀑布模型
缺點：測試後置，開發完成後，修改成本大
V模型
特點：將測試流程細化，分為了單元測試、整合測試、系統測試和驗收測試四個不同的階段
缺點:測試後置，沒有解決風險問題
W模型
優點
①測試的活動和開發同時進行
②測試對像不僅是程序，還包括需求和設計
③儘早發現軟體缺陷可降低開發成本
缺點
無法支援靈活的版本迭代
敏捷開發模型
特點
敏捷開發與測試模型主要是為了適應現代網路公司「短平快」的開發節奏而設計的一種開發和測試模型
內容
①迭代：每次迭代叫做一個sprint，每個sprint裡面選出來要實現的需求會安排到sprint backlog裡面，每個sprint一般是以一個月作為週期
② Product Owner：相當於是產品經理。整理出整個專案的所有需求，並且依照需求的優先順序將需求排列到Produce Backlog
③ Daily Meeting：每日會議，一般是站會形式。每個人發言一般不會超過1分鐘，主要內容包括三點：昨天完成的工作、今天準備進行的工作、面臨的風險和問題
④ sprint burndown：迭代燃盡圖，記錄剩餘的工作量
⑤ sprint review meeting：迭代回顧會議，主要是去回顧在本輪迭代中存在的問題有哪些、如何改進等
⑥ scrum master：相當於組長，由他來統一管理組員
軟體品質模型
定義
軟體品質模型提供了從不同維度考慮產品品質屬性的依據
內容
功能性、可靠性、易用性、效能效率、相容性、安全性、維護性、可攜性
可移植性和相容性的區別：
可移植性是屬於產品的內部質量，更關注程式碼在不同的平台上是否可以正確的安裝和配置。
相容性是屬於產品的外部質量，更關注的是最終用戶能感知到的不同的瀏覽器、不同解析度、不同裝置之間的正確的使用及顯示。
測試方法
黑盒測試
指在不知道被測軟體程式碼結構的基礎上，根據產品需求規格、站在最終用戶的角度來對軟體的輸入和輸出進行測試的過程叫做黑盒測試
白盒測試
指基於被測軟體的程式碼和結構，對被測軟體的程式碼和結構本身進行測試的過程叫做白盒測試
灰盒測試
介於白盒和黑盒之間，一般來說灰盒是針對介面來進行測試，例如只知道函數的函數名稱、參數以及回傳值，並不知道函數內部的實作結構
整合測試
單元經過測試，底層軟體缺陷被找出並修復之後，就整合在一起，對模組的組合進行整合測試，較多涉及介面測試
確認測試
也叫冒煙測試，確認基本功能是否實現，一般不作為正式的測試環節
系統測試
系統所有功能的測試，模擬所有軟體使用者的操作
回歸測試
對軟體新版本測試時重複執行先前的測試案例
目的
①驗證之前缺陷已修復
②確認修復缺陷沒有引發新缺陷
驗收測試
供需雙方以及第三方的測試，依據運行主題的不同可分為ɑ測試（內側）、β測試（公測）、γ測試
測試流程
分析
需求評審（需求評審檢查表）
需求從哪裡來，如果沒有需求怎麼辦？
需求評審怎麼評？
測試需求分析
為啥要做測試需求分析？
測試需求分析流程
得到測試點
計劃：測試計劃和方案文檔編寫
測試設計的概念
用例編寫
測試編號：TC TestCase
測試標題：用一句話來表達該條用例是測試哪個測試點的。
優先：高中低。作用是在專案時間不夠或人員不充足的時候，我們可以優先測試重點的測試案例
預置條件：執行該條用例時，系統必須預先達到的一個狀態或條件。可選，有就寫，沒有就不寫
測試步驟：詳細描述在測試這條用例時，需要進行哪些操作。
預期結果：來自於需求，要求我們達到的一個結果。
實際結果：實際作業系統之後得到的結果。
測試結果：pass/fail/NA pass 預期結果和實際結果相同。 fail 預期結果和實際結果不相同。 N/A 指目前使用案例不適用或無法操作
設計：測試案例設計
測試用例設計方法
實作：編寫測試案例、測試腳本等
測試點的擷取及需求追蹤矩陣
執行：搭建測試環境、執行測試腳本、缺陷報告
建構測試環境
缺陷報告
測試用例設計方法
等價類法
輸入域：所有使用者可以輸入內容的區域
等價類設計步驟
編寫等價類表，為每個輸入劃分等價類，得到等價類表，為每個等價類規定一個唯一編號
設計一個測試案例，使其盡可能多的覆蓋所有尚未覆蓋的有效等價類。重複此步驟，使得有效等價類均被被測試案例所覆蓋
設計一個測試案例，使其只覆寫一個無效等價類。重複此步驟使得所有無效等價類均被覆蓋
等價類劃分原則
如果輸入條件規定了取值範圍或值的個數，則可以確定一個有效等價類和兩個無效等價類
要求輸入年齡在18-25 歲之間，則 18-25 就是一個有效等價類，小於 18 和大於 25 就是兩個無效等價類
要求一個函數有3 個參數，則 3 個參數就是一個有效等價類，大於 3 個和小於 3 個都是無效等價類
輸入條件規定了輸入值的集合，或是規定了必須如何的條件，則可以確定一個有效等價類和一個無效等價類
例如要求輸入學歷值，學歷包含大專、本科、碩士、博士、博士後，那麼學歷中的這些值就是一個有效等價類，凡是不屬於這個學歷集合中的值就是一個無效等價類
在輸入條件是一個布林值的情況下，可確定一個有效等價類和一個無效等價類
例如要求輸入性別為女，那麼女就是有效等價類，男就是無效等價類。
如果我們確知，已經劃分的等價類中各個元素在程序中的處理方式不同，則應將此等價類進一步劃分
在規定了輸入資料必須遵守的規則的情況下，可確立一個有效等價類（遵守規則）和若干無效等價類（從不同角度違反規則）
要求輸入的資料必須是正整數，那麼正整數就是一個有效等價類，無效等價類可以是0 ，負數、小數
邊界值法
定義
1.對程式的輸入和輸出邊界進行測試的一種黑盒用例設計方法，常與等價類設計法結合使用，此時它的用例來自於等價類的邊界。
2.邊界值分析法的理論基礎是假定大多數的錯誤是發生在各種輸入條件的邊界上，如果在邊界附近的取值不會導致程式出錯。那麼其他的取值導致程式錯誤的可能性也很小。
3.邊界值使用條件（重點：可度量）
輸入條件明確了一個值的值範圍，或是規定了值的值個數
輸入條件明確了一個有序集合
相關概念
上點：邊界上的點
離點：離邊界最近的點
內點：取值域內的任一點
每個點一定是不同的數字，不可能一個點既是上點又是離點
上點：範圍中你看到的那兩個點一定是上點
用例步驟
分析輸入參數的類型：從測試規格分析得到輸入參數類型
等價類劃分（可選）：對於輸入等價類劃分方法進行等價類的劃分確定邊界：運用域測試分析方法確定域範圍的邊界（上點、離點與內點）
形成測試項：選擇這些上點、離點與內點或這些點的組合形成測試項
分析原則
如果輸入（輸出）條件規定了取值範圍，則應以該範圍的邊界內的及邊界附近的值作為測試案例
如果輸入（輸出）條件規定了值的個數，則用最大個數、最小個數，比最小個數少1，比最大個數多1的數作為測試案例
如果程式規格說明中提到的輸入或輸出是一個有序的集合，應該注意選取有序集合的第一個和最後一個元素作為測試案例
如果程式中使用了一個內部資料結構，則應該選擇這個內部資料結構的邊界上的值作為測試案例
使用場景：把輸入條件分成多個不同的子條件，條件與條件相對獨立，沒有限制關係
判定表法
定義（是否）
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。
條件樁
列出系統所有輸入，列出的輸入次序沒有影響
條件項
列出針對它左列輸入條件的取值，在所有可能情況下的真假值
動作樁
列出系統可能採取的操作，這些操作的排列順序沒有約束
動作項目
列出在輸入項目的各種取值情況下應該採取的動作
設計步驟
確定規則的個數。如這裡有3個條件，每個條件有兩個值，故應有2*2*2=8種規則
列出所有的條件樁和動作樁
填入條件項
填入動作樁和動作項
化簡，合併相似規則
將每條規則轉化為用例
流程分析法
定義
流程分析法（又稱場景設計法）是將軟體系統的某個流程看成路徑，用路徑分析的方法來設計測試案例。 依照流程的順序依序進行組合，使得流程的各個分支都能走到。 這是從白盒測試中路徑覆蓋分析法中推廣到黑盒測試中來的測試分析方法。
概念
基本流程：指所有操作都正確的主流程
備選流程：指部分操作不正確的流程分支
設計步驟
畫出業務流程圖
設定功能路徑優先權
確定測試路徑
選取測試數據
構造測試用例
範例：某嵌入式系統中，將待傳送的資料打包為符合CA協定的訊框格式後，便可寫入發送緩衝區.，並自動傳送。
1.進入發送子程序
2. 系統判斷是否有空閒發送緩衝區，如果沒有則返回，顯示發送失敗訊息
3.如果有空閒緩衝區將封包寫入空閒發送緩衝區
4.系統判斷是否寫入成功，如果不成功則返回，顯示發送失敗訊息
5. 如果寫入成功，則啟動發送命令
6.返回發送成功訊息
錯誤猜想法
定義
錯誤猜測法就是根據經驗猜想可能有什麼問題並依此設計測試案例
錯誤測法只能作為測試設計的補充而不能單獨用來設計測試用例.否則可能會造成測試的不充分
錯誤猜測不是瞎猜，不是沒有根據和目的的猜測.它需要依據對系統薄弱地方的了解和對開發人員盲點的了解
例子
a = [3,5,8,9,2,4]
重複
[1,1,1,1,1,1,1]
非數字
[1,2,3,a,7,6,5]
列表為空
: [] [67]
順序問題
[1,2,3,4,5,6] [6,5,4,3,2,1]
業務熟悉程度、程式設計經驗的豐富度
測試用例設計總結
測試案例設計方法很多，我們不僅要知道每種方法怎麼用，更需要清楚每種方法使用的場景。
等價類和邊界值是任何其他測試設計方法的基石，必須先考慮使用等價類和邊界值進行使用案例設計。
當輸入域與輸入域之間有約束關係 ，必須使用 判定表來進行組合。
在考慮了所有測試案例設計方法後，最後也要使用錯誤猜測法來補充，以免遺漏。
在測試某一個欄位時，應確保其他欄位的取值是一個正常值。
測試點的分析與擷取
做測驗前思考的問題
你知道要測試的系統是做什麼的嗎？
你了解系統有哪些特色嗎？
你知道系統有哪些功能嗎？
你知道系統的業務流程是什麼嗎？
系統在這個版本上，哪些需要測試，哪些不需要測試？
系統對效能、安全性有沒有什麼要求？
測試需求分析流程
1、根據產品需求提取系統的測試點
1.首先檢查介面元素的顯示是否正確
2.測試頁面的基本功能。如果頁面既有表單也有列表，則優先測試表單功能是否正常
3.針對表單在測試時，需要依據表單裡面的每個欄位依序進行測試。凡是使用者可輸入的輸入域，都要使用等價類別和邊界值根據欄位的限制來進行考慮
4.如果多個欄位之間有關聯關係和限制關係，那麼在測試完單一欄位的等價類別和邊界值之後，應該繼續使用判定表等測試方法進行組合的測試
5.表單測試完後，再測試清單中的功能
6.當單一頁面的內容都測試完畢後，再來結合流程分析法（場景法）測試流程相關的內容
7.流程分析測試完後，最後再使用錯誤猜測法來確保沒有遺漏的測試點
8.例子
2.編寫需求追蹤矩陣
需求追蹤矩陣指的是根據產品需求和測試點以及測試案例，建立一個三者映射的列表，這個表叫做需求追蹤矩陣
需求追蹤矩陣的作用
建立產品需求、測試需求與測試案例之間的映射關係，方便進行使用案例需求覆蓋率統計
如果需求發生變更，可以根據需求追蹤矩陣快速定位哪些測試案例需要更新
3.根據測試點利用適當的測試案例設計方法設計測試案例
建構測試環境
伺服器環境搭建
JDK的安裝
JDK的安裝主要是為了提供 JAVA 的運作環境。 （TOMCAT伺服器是由 java 寫的，所以要執行tomcat 必須先設定好 JAVA 運行環境）
JAVA_HOME:你安裝 JDK 的路徑
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
在Path 環境變數中，加入 %JAVA_HOME%\jre\bin 和 %JAVA_HOME%\bin 這兩個路徑
TOMCAT的安裝
tomcat作為主要的web伺服器，負責處理客戶端發送的所有請求
把tomcat壓縮包解壓縮到一個不含中文或特殊字元的路徑下
CATALINA_HOME：你解壓縮tomcat包的路徑
在Path環境變數中，新增%CATALINA_HOME%\bin路徑
透過雙擊bin目錄下，startup.bat這個檔案來啟動tomcat
MYSQL資料庫的安裝
Mysql資料庫主要用於管理系統數據
透過wampserver工具包安裝mysql應用，並透過wampserver啟動mysql和apache伺服器
被測系統相關的設置
將被測系統的 war 套件放置到 tomcat 指定的路徑中
將資料庫對應的 sql 檔案匯入到資料庫中，並且修改 mysql 資料預設的密碼
啟動伺服器，存取被測系統。網址是： http://localhost:8080/mms/login.html
環境變數
環境變數其實是一種系統的設置，透過這些設定我們可以告訴電腦我們要運行的目標檔案在什麼位置
缺陷報告
缺陷的定義
軟體沒有實現產品的說明書所描述的功能
軟體實現了產品說明書描述不應有的功能
軟體執行了產品說明書沒講的操作
軟體沒有實現產品說明書沒講但應該實現的功能
從軟體測試員的角度來看，軟體難以理解、不易使用、運作緩慢，或最終使用者認為不對
缺陷管理
掌握軟體缺陷的生命週期
掌握高品質缺陷報告的填寫方法
一個完整的測試報告
缺陷編號
預置條件
缺陷標題
測試步驟
嚴重程度
優先權
重現率
缺陷狀態
掌握軟體缺陷的相關屬性
缺陷嚴重程度
嚴重性
項名思義就是軟體缺陷對軟體品質的破場程度，也就是此軟體缺陷的存在將對軟體的功能和效能產生怎樣的影響
致命
例如，軟體的意外退出甚至作業系統崩潰，造成資料遺失
嚴重
例如，由於單功能失效導致多個相關功能失效
一般
例如，軟體的單一功能失效
提示
軟體介面的細微缺陷，例如，某個控制項沒有對齊，某個標點符號遺失等
缺陷狀態分類
了解軟體缺陷管理的常用工具
了解缺陷衝突中一些常見的問題
如何處理不能重現的缺陷？ 一定要提交到缺陷管理庫！
1. 一定要詳細描述遇到缺陷的流程和相關環境配置。如果有日誌的話，一定要附上相關的操作日誌或系統運作日誌。
2. 對於不可重現的缺陷，一定要盡量描述清楚復現率是多少。
3. 對於不可重現的缺陷，當開發人員將缺陷設為fixed之後，在驗證時，不能只在一個版本上去驗證缺陷是否修復，必須至少在3個以上的版本上驗證後都沒有重現過，才能將缺陷關閉。
回歸測試和驗收測試
回歸測試
定義
修改程式碼後，重新進行測試
目的
檢查缺陷是否真的被修復
程式設計師在修復缺陷中是否引入新的缺陷
流程
1.在測試策略制定階段，制定迴歸測試策略
2.確定需要迴歸測試的版本 Version，哪個版本上bug被修改了就在哪個版本上回歸
3.回歸測試版本發布，依照回歸測試策略執行迴歸測試
4.回歸測試通過，關閉缺陷報告單
5.回歸測試不通過，缺陷報告單返回開發人員，開發人員重新修改問題，再次提交測試人員回歸測試
策略
完全回歸
重新執行所有在前期測試階段建立的測試案例，來確認問題修改的正確性和修改的擴散局部影響性
選擇性迴歸
即選擇性地重新執行部分在前期測試階段建立的測試案例，來測試被修改的程序
方法
覆蓋修改
針對被修改的部分，選取或重新建構測試案例驗證沒有錯誤再次發生的用例選擇方法
週邊影響
包含覆蓋修改法確定的用例，也要分析修改的擴散影響，驗證是否有其他部分被影響
指標達成
驗收測試
定義
在通過了內部系統測試之後，就可以開始驗收測試
驗收測試是以使用者為主的測試，驗收群組應該由專案組成員、使用者代表等組成
驗收測試原則上在使用者所在地進行，但如經使用者同意也可以在公司內模擬使用者環境進行
驗收測試根據合約、《需求規格說明書》或《驗收測試計畫》對成品進行驗收測試
對於產品型的項目，驗收測試一般又分為α測試（內測：在開發環境下進行）和β測試（公測：實際使用環境下測試）兩種
生命週期測試方法對比