測試理論基礎（思惟導圖）

時間 2020-08-01

標籤測試理論基礎思惟简体版

原文原文鏈接

1、軟件測試基礎

2、測試級別

3、系統測試類型

4、軟件測試方法

5、軟件質量前端

6、系統測試流程

7、測試用例格式

8、用例設計方法

1.什麼是軟件測試？
軟件測試定義：使用人工和自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異。或者：爲了發現程序中的錯誤而執行程序的過程。ios

軟件測試存在的意義：程序員

①程序測試爲了發現程序存在的代碼或業務邏輯錯誤；面試

②軟件測試爲了檢驗產品是否符合用戶需求（充分站在用戶的角度）；數據庫

③軟件測試爲了提升用戶的體驗。編程

2.軟件測試的原則
一、測試應該儘早介入。數組

二、全部的測試都應追溯到用戶需求。瀏覽器

三、程序員應該避免檢查本身的程序。除了單元測試。由於程序員對於本身的做品，思惟具備侷限性。沒法保證測試質量。交給第三方或者專業測試，運用各類測試技術，利用豐富的測試經驗和對BUG的敏感，去提升軟件的質量。安全

四、設計測試用例時應考慮到合法的輸入和不合法的輸入以及各類邊界條件，特殊狀況下還要製造極端狀態和意外狀態。服務器

五、二八原則，測試發現的錯誤中80%極可能起源於20%的模塊中。

六、對錯誤結果要進行一個確認過程（分清必現和偶然）。

七、制定嚴格的測試計劃。

八、徹底測試時不可能的，測試須要終止。

九、妥善保存測試過程當中全部文檔。

3.軟件測試的分類
按測試階段劃分：單元測試（開發的自測行爲）、集成測試（多個模塊共同測試）、系統測試（完整的、全面的測試）、驗收測試（正式驗收測試、Alpha測試（開發和測試都不能參與，由用戶進行測試，前期，非真實環境）、Bate測試（開發和測試都不能參與測試，由用戶進行測試，後期，真實環境下測試））

按測試技術劃分：白盒測試、黑盒測試（主流）、灰盒測試

按測試對象是否運行劃分：動態測試、靜態測試（文檔檢查、代碼走查、界面檢查）

按不一樣的測試手段劃分：手工測試、自動化測試

按測試包含的內容劃分：功能測試（等同於黑盒測試，點點點）、界面測試（不會專門作，作功能測試時會同時作這個）、安全測試、兼容性測試（ios、安卓）、易用性測試（不會專門作，作功能測試時會同時作這個）、性能測試、壓力測試、負載測試、恢復測試（災備，若出現奔潰，須要多久自我修復）

其餘測試：冒煙測試（在真正測試以前，會先進行主幹測試，若主幹測試都沒法經過，則再也不進行測試）、迴歸測試（首先看bug是否真的修復，再次看bug修復後是否影響到與其有關的原本正常的功能）、探索性測試（測試思惟）（隨機測試）

4.軟件生命週期（十分重要）
軟件生命週期（SDLC,System Development Life Cycle）是軟件開始研製到最終被廢棄不用這整個過程叫作軟件生命週期，整個生命週期包括問題定義及規劃、需求分析、系統設計、軟件編程、軟件測試、軟件維護等階段。
1、問題定義及規劃（參與人員：老闆、產品經理（主導）、研發經理、項目經理、需求分析師）
主要肯定軟件的開發目的及其可行性。制定開發計劃（軟件需求說明書、原型圖）。
2、需求分析/評審（原型圖/軟件需求說明書、主持—>產品經理其餘參與：研發設計測試）
在肯定軟件開發可行的狀況下，對軟件須要實現的各個功能進行詳細分析，明確客戶的需求，輸出需求規格說明書（原型圖）。（關注一個問題：測試參與這個需求分析的目的是什麼？產品用途，功能如何實現）
3、軟件設計（屬於開發的工做）
把需求分析獲得的結果轉換爲軟件結構和數據結構，造成系統架構。
概要設計：主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口鏈接和數據傳遞的實現等項事務。（數據庫、表等框架性的東西）
詳細設計：對概要設計中表述（僞代碼的級別）
4、軟件編碼（開發編碼，與測試無關）
5、軟件測試

在軟件設計完成後要通過嚴密的測試，以及發現軟件在整個設計過程當中存在的問題並加以糾正。測試的方法主要有白盒測試和黑盒測試兩種。

其中，開發：單元測試；開發or測試：集成測試、接口測試；測試人員：系統測試；客戶or產品經理：驗收測試（α測試、β測試）

單元測試：主要測試程序代碼，爲的是確保各單元模塊被正確的編譯，好比有具體到模塊的測試，也有具體到類、函數的測試等。----通常是開發來完成。

集成測試：單元測試後，將各單元組合成完整的體系，測試軟件單位之間的接口是否正確、數據可否正常傳遞。----好比說註冊和充值這兩個功能是否可以連通。

系統測試：把軟件系統搭建起來，按照軟件規格說明書所要求，測試軟件其性能功能等是否和用戶需求符合，在系統中運行是否存在漏洞等。-----根據測試用例，進行完整的系統測試。

六：運行維護階段（版本上線，產品上線；版本升級；bug修復）

5.軟件測試的工做流程：
接觸人員：開發，產品經理，客服（用戶反饋問題），實施/技術支持/現場實施，設計師；
測試工做流程：
①需求分析：1.閱讀需求/理解需求 2.整理需求 3.有疑問的地方須要討論，弄明白爲止；

②軟件測試計劃：一個文檔，測試負責人/小組長制定計劃；

文檔包含內容：

目的：完成測試，什麼時候終止，達成什麼樣的目標；

參與人員：誰參與，成爲測試小組；

任務劃分：誰負責哪一個功能模塊的測試/用例的編寫；

時間規劃：何時寫用例，何時測試，何時解釋，何時上線；

出具的文檔：用例bug表單軟件測試報告；

資源的申請/準備：申請一臺服務器？我要作什麼類型的測試？須要準備什麼樣的工具？

③測試設計階段：寫測試用例

評審（相互檢查），修改：理解錯誤：改正；需求變動：修改，

④軟件測試的執行階段

1.測試前，進行冒煙測試，經過繼續測試，不經過，打回

2.根據測試用例執行測試：發現bug提交bug管理系統；修復後，檢驗，再進行迴歸測試。

⑤評估階段

測試完畢，出具測試報告：1.測試經過，上線； 2.測試不經過，打回，修改

6.軟件生命週期模型
做爲測試工程師，咱們最關心的三件事：

1.測什麼？（最關注的問題）2.怎麼測？3.何時測？

測試的計劃是跟開發的計劃走的

學習目標：

1.什麼是軟件測試需求？

2.軟件測試需求的必要性

3.如何對軟件測試需求進行分析（重點）

功能、易用、界面、權限

4.需求分析對開發和測試的影響

3.軟件測試流程
設計、執行、總結

4.常見面試筆試題
測試結束的標準是什麼：系統測試缺陷報告跟蹤完畢，系統測試報告經過審批。測試用例執行完畢、用例經過率＞98%。不存在嚴重bug。

執行測試用例的時間：通常爲3-6個月，起碼3個月，但留給測試的可能只有7天。

軟件測試用例的設計方法——四大金剛

1.等價類劃分法

1.等價類劃分法的概念

等價類劃分法是一種典型的、重要的黑盒測試方法，是指某個輸入域的子集合。在該子集合中，全部的輸入數據對於揭露軟件中的錯誤是等效的。

等價劃分分爲有效等價類和無效等價類，有效和無效是根據條件劃分的。

2.錯誤推測法

輸入錯誤的信息進行檢測，看測試程序對錯誤狀況的處理能力。

3.邊界值分析法

1.定義：邊界值分析法是對等價類劃分法的一個補充，邊界值通常都是從等價類的邊緣值去尋找。邊界值分析的基本思想：正好等於、剛剛大於、剛剛小於邊界的值作爲測試數據。

注意：0和負數都是一個特殊值，咱們在考慮邊界值的時候同時也要考慮特殊值。

4.場景法（功能作好了才用）（xmind）

整個流程的描述，例如ATM取款流程

7.什麼是測試用例
測試用例（TestCast）是爲項目需求而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序是否知足客戶需求。
能夠總結爲：每一個測試點的數據設計和步驟設計。

7.1測試用例的重要性

1.測試用例是軟件測試的核心

軟件測試的重要性是毋庸置疑的，測試用例是測試工做的指導，是軟件測試質量穩定的保障。影響軟件測試的因素不少，如軟件自己的複雜程度，開發質量，測試方法和技術的使用。但有些因素是客觀存在，不可避免的，如IT團隊的流動、環境、情緒等。

2.評估測試結果的基準

測試用例的經過率以及錯誤率，是測試結束的一個重要依據，用來判斷該軟件測試結果是否經過，可否達到上線的標準。

3.保證測試的時候不遺漏測試功能點。能夠在測試人員疲累的時候起到引導做用。

4.在編寫測試用例過程，能夠熟悉需求，對系統架構或者業務流程有一個總體的、深刻地瞭解。

5.好的測試用例不只方便本身和他人查看，並且能幫助設計的時候考慮的更周全，所以測試用例的寫做和設計同樣，很重要。指導性。

7.2測試用例的八大要素

1.用例編號：產品名-測試階段-測試項-xxx

2.測試項目：對應一個功能模塊（細分功能）

3.測試標題：直接對測試點進行細化得出，輸入內容+結果，同一功能模塊標題不能重複(一句話說清楚測試點是什麼)

4.重要級別：高/中/低

5.預置條件：須要知足一些前提條件，不然用例沒法執行（用例可寫也可不寫）

6.測試輸入：須要加工的輸入信息，根據具體狀況來設計（跟步驟結合起來必定要具備指導性意義）

7.操做步驟：明確給出每一個步驟的描述，執行人員能夠根據該步驟完成執行工做。

8.預期結果：根據與其輸出比對實際記過，來判斷被測對象是否符合需求。（預期結果惟一）

9.實際結果：

7.3測試用例使用工具

excel和xmind（都要會用）

8.bug的生命週期（重點）

8.1 bug的定義

軟件的Bug，狹義概念是指軟件程序的漏洞或缺陷，廣義概念除此以外還包括測試工程師或用戶所發現和提出的軟件可改進的細節、或與需求文檔存在差別的功能實現等。

測試工程師的職責是：發現BUG，並提交給開發，讓開發去修改。

8.2 bug的類型

要肯定一個bug的類型，須要對項目（或產品）有比較深的理解。這個劃分對於開發定位問題影響很小，但對問題類型的統計就比較重要了。

常見bug類型劃分（禪道系統爲例，可自定義）：

代碼錯誤

設計缺陷

界面優化

性能問題

配置相關

安裝部署

安全相關

標準規範

測試腳本

其餘

8.3bug的等級

1,2,3,4級，1級最嚴重的bug;3屬於正常bug。

（1）致命錯誤：

1.常規操做引發的系統崩潰、死機、死循環，好比對話框輸入信息形成程序崩潰；

2.形成數據泄露的安全性問題，好比惡意攻擊形成的帳戶私密信息的泄露；

3.涉及金錢的方面，例如：用戶餘額爲零，卻能消費

（2）嚴重錯誤：

1.重要功能不能實現；（好比用戶沒法註冊）

2.錯誤的波及面廣，影響到其餘重要功能正常實現：功能交互

3.很是規操做致使程序的崩潰、死機、死循環等；

4.外觀難以接受的缺陷；

5.密碼明文顯示（界面+數據庫）。

（3）通常錯誤：

不影響產品的運行、不會成爲故障原由，但對產品外觀和下道工序影響較大的缺陷。

1.次要功能不能正常實現；

2.操做界面錯誤（包括數據窗口內列名定義，含義不一致）；

3.查詢錯誤，數據錯誤顯示；（張冠李戴）

4.簡單的輸入限制未放在前段進行控制；（格式限制）

5.刪除操做未給出提示；

（4）可忽略錯誤

例如錯別字，或測試人員以爲軟件設計不美觀等。

8.4bug的生命週期
測試(發現並提交bug至管理系統中)——>指派給對應開發人員

——>開發人員先確認是不是本身的bug，如果，確認；不是，打回測試；不是bug，不予解決，由於不是bug；或延期解決。設計如此；沒法重現。——>對於打回的bug，測試再次肯定需求，若的確是bug，則再次激活發給開發。——>對於修復後的bug，測試進行迴歸測試或驗證測試，若已經解決，就直接關閉。若還未解決，再次打回給開發。

客服（客戶反饋的問題）——>發給測試，如果bug,提交，若不是就告訴客服是客戶的操做問題。

測試（需求的肯定，需求的變動，和開發扯不清楚）——>產品經理
---------------------

缺陷狀態說明

新建：測試中新建的軟件缺陷，尚未提交給軟件工程師。通常由測試負責人進行評估，若是屬於缺陷，修改成「打開」狀態；若是不屬於缺陷，修改成「取消」狀態。

打開：測試中新建的軟件缺陷，已提交給相關軟件工程師。

待討論：存在爭議，須要軟件工程師、需求人員和測試工程師共同確認；該狀態是臨時狀態，在進入最後一輪ST測試執行以前，必須進行處理。

已修復：軟件工程師已修正缺陷，等待測試工程師進行驗證。

已發佈：軟件工程師已提交修復版本，而且版本管理員已將修復版本發佈到測試環境。

項目內暫不處理：因爲各類緣由，提交的缺陷須要在後續版本才能修改，或者不修改。項目內暫不處理的缺陷須要由需求人員、軟件工程師和測試工程師最終確認。對準備修改的缺陷，在進入最後一輪ST測試執行以前，測試工程師就必須和需求人員、開發人員討論肯定是「轉業務需求」仍是「轉內部需求」，在後續項目進行修復，或者在本項目最後一輪ST測試執行前修復。對一致承認但不許備修復的缺陷，或者不能重現的缺陷，能夠將「項目內暫不處理」做爲終態。

已否決：軟件工程師認爲不須要修改，或者按照設計就應該是這樣的。對於非本項目或者非本人缺陷，因爲設計變動或者版本變動以前的問題如今沒法重現，不可否決。無理由否決的，測試工程師一概從新打開。

已分配：轉發給其餘人處理。也能夠轉給本身處理，轉給本身處理時，代表軟件工程師已接受此項缺陷。

從新打開：測試工程師對已修復的缺陷進行驗證，發現缺陷仍舊存在。或者測試工程師認爲已被否決的缺陷確實須要修改。

已關閉：缺陷已被修復，且迴歸測試驗證成功。

非問題關閉：對於軟件工程師否決的缺陷，若是測試工程師認爲確實不屬於缺陷，則將缺陷狀態標記爲「非問題關閉」。

轉業務需求：該缺陷與業務相關，須要解決，但在本項目中不處理，由需求人員在後續版本中做爲業務需求提出。

轉內部需求：該缺陷主要是設計實現的問題，不涉及業務需求的變動，須要解決，但在本項目中不處理，由軟件工程師在後續版本中做爲內部改進需求提出。

取消：測試中新建的軟件缺陷，由測試負責人進行評估，確認不屬於缺陷，則將缺陷狀態標記爲「取消」。

====================================================================================================================================================================================================

缺陷嚴重度說明—非性能測試項目域
1、致命
該類缺陷若是發生會形成基本業務沒法使用、或對其餘業務形成嚴重影響、或對我行形成經濟損失、法律糾紛、聲譽影響等。

● 因爲程序所引發的死機,非法退出或系統掛起。

● 死循環。

● 發生線程互鎖、數據庫死鎖等嚴重資源爭用狀況。

● 數據轉換錯誤，通信程序不穩定或通信程序錯誤。

● 主要功能缺失。

● 記帳錯誤。

● 嚴重的數值錯誤，好比數據庫或回單上的客戶信息，餘額，利息，積數，日期等。
2、嚴重
該類缺陷若是發生會形成部分業務功能沒法使用、或對其餘業務形成必定影響、部分功能實現形成較大的錯誤理解等。

● 影響業務進行的主要功能與需求不符。包括設計與需求不符，以及實現與設計不符。

● 非主要功能未實現。

● 程序引發的接口或數據通信錯誤，致使數據缺失，信息傳輸錯誤等。

● 致使資金或是帳務錯誤等關鍵字段的數值計算錯誤。

● 操做權限錯誤。

● 異常處理遺漏或錯誤。

● 存在嚴重性能問題。

● 顯示或打印的關鍵信息格式與需求定義存在大的誤差。

● 關鍵的輸入限制未進行控制。
3、通常
該類缺陷若是發生會對非主要功能形成影響、或者有較爲快速方便的規避方式、有較小的錯誤理解等。

● 與設計文檔不符的界面錯誤。

● 非主要功能實現不正確，但不影響業務進行。

● 非關鍵信息的計算錯誤，如頁碼的計算錯誤。

● 打印的非關鍵信息錯誤；因爲內容超長致使的格式錯誤。

● 簡單的輸入限制未進行控制。

● 業務操做缺乏交互式的確認提示信息。

● 錯誤提示信息錯誤。

● 系統處理速度較慢，可能存在性能風險。
4、較小
該類缺陷若是發生會使用戶不方便或遇到麻煩，但它不影響執行工做功能或重要功能。

● 輔助說明描述不清楚。

● 顯示格式不規範，界面有錯別字。

● 長時間操做未給用戶進度提示。

● 提示窗口文字未採用行業術語。

● 錯誤提示信息不清晰。

● 可輸入區域和只讀區域沒有明顯的區分標誌。

● 界面佈局不合理、用戶體驗效果不佳、操做界面與用戶使用習慣不一致，但不影響系統正常使用。

● 建議。
5、建議及警告
針對系統功能實現方式、組織方式、界面佈局、用戶體驗、易用性等方面提出的修改建議（此類缺陷不會給系統帶來直接的負面影響或安全隱患）。

====================================================================================================================================================================================================
缺陷嚴重度說明—性能測試項目域
1、致命(P1)
該類缺陷若是發生會形成基本業務沒法使用、或對其餘業務形成嚴重影響、或對我行形成經濟損失、法律糾紛、聲譽影響等。

● 因爲程序所引發的死機,非法退出或系統掛起。

● 死循環。

● 記帳錯誤。

● 應用服務器或數據庫服務器出現崩潰或不可用。

● 交易錯誤率>10%。
2、嚴重(P2)
該類缺陷若是發生會形成部分業務性能沒法使用、或對其餘業務形成必定影響、部分功能實現形成較大的錯誤理解等。

● 數據庫出現嚴重鎖等待、死鎖。

● 嚴重線程阻塞。

● 5%< 交易錯誤率% <10%。

● TPS和響應時間嚴重不達標。

● 發現架構設計缺陷。
3、通常(P3)
該類缺陷若是發生會對性能形成必定影響、部分功能會出現一些錯誤。性能指標：1）錯誤率<10%；2）TPS和響應時間不達標；3）操做系統資源消耗過大。

● 0.5%< 交易錯誤率% <5%。

● TPS和響應時間不達標。

● 服務器資源消耗過大。

● 非功能測試案例不經過。

● 參數設置不合理。
4、較小(P4)
該類缺陷若是發生會不會影響到交易的性能，但客戶體驗上會相對比較差。

● 前端頁面性能明顯BUG。
5、建議及警告(P5)
已達到預期性能指標，但還能夠提高性能的建議。

=====================================================================================================================================================================================================

缺陷類型說明
缺陷類型有三個一級類型分類，各個一級類型下有多個二級類型分類。提缺陷時，類型有二級類型時必須選擇二級類型。
一級類型：01-功能性缺陷二級類型：11-功能錯誤
● 實現與提供的需求不一致

● 使用的計算方法或計算公式錯誤

● 影響帳務或可能致使法律糾紛的關鍵數據的計算錯誤，好比針對數據庫和客戶回單上帳戶餘額、利息、積數、凍結金額、可用餘額、額度等關鍵信息的計算錯誤

● 變量初始數據錯誤

● 系統數據初始化錯誤

● 數組越界或緩衝區溢出

● 數據結構或數據庫表結構設計有問題

● 寫入數據庫表的內容錯誤，好比出現重複記帳或表內帳單邊帳

● 死循環

● 業務功能重複或缺失

● 業務功能實現與需求不符

● 流程控制不符合需求