一、軟件測試基礎
二、測試級別
三、系統測試類型
四、軟件測試方法
五、軟件質量
六、系統測試流程
七、測試用例格式
八、用例設計方法
1.什么是軟件測試？
軟件測試定義：使用人工和自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。或者：為了發現程序中的錯誤而執行程序的過程。
軟件測試存在的意義：
①程序測試為了發現程序存在的代碼或業務邏輯錯誤；
②軟件測試為了檢驗產品是否符合用戶需求（充分站在用戶的角度）；
③軟件測試為了提高用戶的體驗。
2.軟件測試的原則
1、測試應該盡早介入。
2、所有的測試都應追溯到用戶需求。
3、程序員應該避免檢查自己的程序。除了單元測試。因為程序員對於自己的作品，思維具有局限性。無法保證測試質量。交給第三方或者專業測試，運用各種測試技術，利用豐富的測試經驗和對BUG的敏感，去提高軟件的質量。
4、設計測試用例時應考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下還要制造極端狀態和意外狀態。
5、二八原則，測試發現的錯誤中80%很可能起源於20%的模塊中。
6、對錯誤結果要進行一個確認過程（分清必現和偶然）。
7、制定嚴格的測試計划。
8、完全測試時不可能的，測試需要終止。
9、妥善保存測試過程中所有文檔。
3.軟件測試的分類
按測試階段划分：單元測試（開發的自測行為）、集成測試（多個模塊共同測試）、系統測試（完整的、全面的測試）、驗收測試（正式驗收測試、Alpha測試（開發和測試都不能參與，由用戶進行測試，前期，非真實環境）、Bate測試（開發和測試都不能參與測試，由用戶進行測試，后期，真實環境下測試））
按測試技術划分：白盒測試、黑盒測試（主流）、灰盒測試
按測試對象是否運行划分：動態測試、靜態測試（文檔檢查、代碼走查、界面檢查）
按不同的測試手段划分：手工測試、自動化測試
按測試包含的內容划分：功能測試（等同於黑盒測試，點點點）、界面測試（不會專門做，做功能測試時會同時做這個）、安全測試、兼容性測試（ios、安卓）、易用性測試（不會專門做，做功能測試時會同時做這個）、性能測試、壓力測試、負載測試、恢復測試（災備，若出現奔潰，需要多久自我修復）
其他測試：冒煙測試（在真正測試之前，會先進行主干測試，若主干測試都無法通過，則不再進行測試）、回歸測試（首先看bug是否真的修復，再次看bug修復后是否影響到與其有關的本來正常的功能）、探索性測試（測試思維）（隨機測試）
4.軟件生命周期（十分重要）
軟件生命周期（SDLC,System Development Life Cycle）是軟件開始研制到最終被廢棄不用這整個過程叫做軟件生命周期，整個生命周期包括問題定義及規划、需求分析、系統設計、軟件編程、軟件測試、軟件維護等階段。
一、問題定義及規划（參與人員：老板、產品經理（主導）、研發經理、項目經理、需求分析師）
主要確定軟件的開發目的及其可行性。制定開發計划（軟件需求說明書、原型圖）。
二、需求分析/評審（原型圖/軟件需求說明書、主持—>產品經理 其他參與：研發 設計 測試）
在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析，明確客戶的需求，輸出需求規格說明書（原型圖）。（關注一個問題：測試參與這個需求分析的目的是什么？產品用途，功能如何實現）
三、軟件設計（屬於開發的工作）
把需求分析得到的結果轉換為軟件結構和數據結構，形成系統架構。
概要設計：主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務。（數據庫、表等框架性的東西）
詳細設計：對概要設計中表述（偽代碼的級別）
四、軟件編碼（開發編碼，與測試無關）
五、軟件測試
在軟件設計完成后要經過嚴密的測試，以及發現軟件在整個設計過程中存在的問題並加以糾正。測試的方法主要有白盒測試和黑盒測試兩種。
其中，開發：單元測試；開發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測試執行前修復。對一致認可但不准備修復的缺陷，或者不能重現的缺陷，可以將“項目內暫不處理”作為終態。
已否決：軟件工程師認為不需要修改，或者按照設計就應該是這樣的。對於非本項目或者非本人缺陷，由於設計變更或者版本變更之前的問題現在無法重現，不能否決。無理由否決的，測試工程師一律重新打開。
已分配：轉發給其他人處理。也可以轉給自己處理，轉給自己處理時，表明軟件工程師已接受此項缺陷。
重新打開：測試工程師對已修復的缺陷進行驗證，發現缺陷仍舊存在。或者測試工程師認為已被否決的缺陷確實需要修改。
已關閉：缺陷已被修復，且回歸測試驗證成功。
非問題關閉：對於軟件工程師否決的缺陷，如果測試工程師認為確實不屬於缺陷，則將缺陷狀態標記為“非問題關閉”。
轉業務需求：該缺陷與業務相關，需要解決，但在本項目中不處理，由需求人員在后續版本中作為業務需求提出。
轉內部需求：該缺陷主要是設計實現的問題，不涉及業務需求的變更，需要解決，但在本項目中不處理，由軟件工程師在后續版本中作為內部改進需求提出。
取消：測試中新建的軟件缺陷，由測試負責人進行評估，確認不屬於缺陷，則將缺陷狀態標記為“取消”。
====================================================================================================================================================================================================
缺陷嚴重度說明—非性能測試項目域
一、致命
該類缺陷如果發生會造成基本業務無法使用、或對其他業務造成嚴重影響、或對我行造成經濟損失、法律糾紛、聲譽影響等。
● 由於程序所引起的死機,非法退出或系統掛起。
● 死循環。
● 發生線程互鎖、數據庫死鎖等嚴重資源爭用情況。
● 數據轉換錯誤，通訊程序不穩定或通訊程序錯誤。
● 主要功能缺失。
● 記賬錯誤。
● 嚴重的數值錯誤，比如數據庫或回單上的客戶信息，余額，利息，積數，日期等。
二、嚴重
該類缺陷如果發生會造成部分業務功能無法使用、或對其他業務造成一定影響、部分功能實現造成較大的錯誤理解等。
● 影響業務進行的主要功能與需求不符。包括設計與需求不符，以及實現與設計不符。
● 非主要功能未實現。
● 程序引起的接口或數據通訊錯誤，導致數據缺失，信息傳輸錯誤等。
● 導致資金或是賬務錯誤等關鍵字段的數值計算錯誤。
● 操作權限錯誤。
● 異常處理遺漏或錯誤。
● 存在嚴重性能問題。
● 顯示或打印的關鍵信息格式與需求定義存在大的偏差。
● 關鍵的輸入限制未進行控制。
三、一般
該類缺陷如果發生會對非主要功能造成影響、或者有較為快速方便的規避方式、有較小的錯誤理解等。
● 與設計文檔不符的界面錯誤。
● 非主要功能實現不正確，但不影響業務進行。
● 非關鍵信息的計算錯誤，如頁碼的計算錯誤。
● 打印的非關鍵信息錯誤；由於內容超長導致的格式錯誤。
● 簡單的輸入限制未進行控制。
● 業務操作缺少交互式的確認提示信息。
● 錯誤提示信息錯誤。
● 系統處理速度較慢，可能存在性能風險。
四、較小
該類缺陷如果發生會使用戶不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
● 輔助說明描述不清楚。
● 顯示格式不規范，界面有錯別字。
● 長時間操作未給用戶進度提示。
● 提示窗口文字未采用行業術語。
● 錯誤提示信息不清晰。
● 可輸入區域和只讀區域沒有明顯的區分標志。
● 界面布局不合理、用戶體驗效果不佳、操作界面與用戶使用習慣不一致，但不影響系統正常使用。
● 建議。
五、建議及警告
針對系統功能實現方式、組織方式、界面布局、用戶體驗、易用性等方面提出的修改建議（此類缺陷不會給系統帶來直接的負面影響或安全隱患）。
====================================================================================================================================================================================================
缺陷嚴重度說明—性能測試項目域
一、致命(P1)
該類缺陷如果發生會造成基本業務無法使用、或對其他業務造成嚴重影響、或對我行造成經濟損失、法律糾紛、聲譽影響等。
● 由於程序所引起的死機,非法退出或系統掛起。
● 死循環。
● 記賬錯誤。
● 應用服務器或數據庫服務器出現崩潰或不可用。
● 交易錯誤率>10%。
二、嚴重(P2)
該類缺陷如果發生會造成部分業務性能無法使用、或對其他業務造成一定影響、部分功能實現造成較大的錯誤理解等。
● 數據庫出現嚴重鎖等待、死鎖。
● 嚴重線程阻塞。
● 5%< 交易錯誤率% <10%。
● TPS和響應時間嚴重不達標。
● 發現架構設計缺陷。
三、一般(P3)
該類缺陷如果發生會對性能造成一定影響、部分功能會出現一些錯誤。性能指標：1）錯誤率<10%；2）TPS和響應時間不達標；3）操作系統資源消耗過大。
● 0.5%< 交易錯誤率% <5%。
● TPS和響應時間不達標。
● 服務器資源消耗過大。
● 非功能測試案例不通過。
● 參數設置不合理。
四、較小(P4)
該類缺陷如果發生會不會影響到交易的性能，但客戶體驗上會相對比較差。
● 前端頁面性能明顯BUG。
五、建議及警告(P5)
已達到預期性能指標，但還可以提升性能的建議。
=====================================================================================================================================================================================================
缺陷類型說明
缺陷類型有三個一級類型分類，各個一級類型下有多個二級類型分類。提缺陷時，類型有二級類型時必須選擇二級類型。
一級類型：01-功能性缺陷 二級類型：11-功能錯誤
● 實現與提供的需求不一致
● 使用的計算方法或計算公式錯誤
● 影響賬務或可能導致法律糾紛的關鍵數據的計算錯誤，比如針對數據庫和客戶回單上賬戶余額、利息、積數、凍結金額、可用余額、額度等關鍵信息的計算錯誤
● 變量初始數據錯誤
● 系統數據初始化錯誤
● 數組越界或緩沖區溢出
● 數據結構或數據庫表結構設計有問題
● 寫入數據庫表的內容錯誤，比如出現重復記賬或表內賬單邊賬
● 死循環
● 業務功能重復或缺失
● 業務功能實現與需求不符
● 流程控制不符合需求
● 流程實現不完整
一級類型：01-功能性缺陷 二級類型：12-用戶界面錯誤
● 控件布局、格式不統一
● 界面控制錯誤
● 界面布局與界面規范不一致
● 打印或輸出格式錯誤
一級類型：01-功能性缺陷 二級類型：13-通訊及接口錯誤
● 通訊接口不匹配
● 通訊接口數據轉換錯誤
● 通訊程序不穩定
● 通訊程序錯誤
一級類型：01-功能性缺陷 二級類型：14-信息提示錯誤
● 提示信息重復
● 提示信息內容錯誤
● 提示信息內容模糊，不能准確判斷錯誤原因
● 提示信息出現時機不對，或焦點位置錯誤
一級類型：01-功能性缺陷 二級類型：15-異常處理錯誤
● 程序未進行異常處理
● 異常處理不正確或者不合理
一級類型：02-非功能缺陷 二級類型：21-易用性錯誤
● 不符合常識或不符合操作習慣
● 操作使用不友好，不易操作等
一級類型：02-非功能缺陷 二級類型：22-性能錯誤
● 批量處理時間過長
● 聯機業務響應時間過長導致資源爭用，造成互鎖或死鎖問題，如線程同步問題或數據庫鎖等待
一級類型：02-非功能缺陷 二級類型：23-安全性錯誤
● 用戶和權限控制錯誤
● 有SQL注入漏洞
● 有跨站點攻擊漏洞
● 有其他安全性漏洞
一級類型：02-非功能缺陷 二級類型：24-兼容性錯誤
● 在不同操作系統、不同瀏覽器上的錯誤
● 與不同版本匹配出現的錯誤
一級類型：02-非功能缺陷 二級類型：25-安全性錯誤
● 數據錯誤
● 腳本錯誤
● 功能問題
● 硬件問題
● 環境問題
● 數據庫問題
● 網絡問題
一級類型：03-文檔類缺陷 二級類型：31-評審類缺陷
● 各類評審活動發現的缺陷
一級類型：03-文檔類缺陷 二級類型：32-其他文檔錯誤
● 各類評審活動發現的缺陷
====================================================================================================================================================================================================
缺陷歸屬說明
項目內：表示該缺陷是由於該項目新增或者修改功能而導致的缺陷；
項目外：表示該缺陷不是由於該項目新增或者修改功能而導致的缺陷，是由於其他產品引起或該產品一直遺留的缺陷。若不在本項目解決，必須掛系統產品，狀態設為項目暫不處理。如果項目外缺陷項目內修復，這缺陷歸屬需重新選擇為項目內。
行外系統：表示該缺陷是由於行外系統導致的，但是如果該項目涉及到行外系統的再維護和開發，不屬於此范疇。
如果認定為行外缺陷，則系統產品欄位需選擇事先定義好的虛擬行外產品。