測試流程和理論--測試流程體系

測試流程體系

1.需求評審：無論是自研發還是其他公司的產品，都得等產品經理設計好，召集開發，設計，測試開會了詳細瞭解需求，瞭解需開展之後的測試工作，測試人員是從使用者角度考慮居多，更加能夠從使用者的角度提出符合實際的建議。
2.制定測試計劃：
需求最終確定下來，開始制定測試計劃，確定測試目標、測試範圍、測試方法、測試策略、資源安排、風險評估，測試周期等。
3.測試用例設計：
做好測試計劃後，可開始進行用例設計。一般先使用思維導圖工具（Xmind）整理大概框架，再使用測試用例管理工具（如testlink，禪道）按功能模組、使用場景進行設計。
4.測試用例評審：
測試用例寫在禪道上好管理也可以讓其他研發者觀看參考，待用例設計好後（產品經理、研發人員、測試人員）都參與用例評審，以便查漏補缺，儘可能使用例覆蓋更全面。
5.冒煙測試：
待研發人員提交版本後，測試人員便可以進行冒煙測試（當然，冒煙測試的用例要提前選好）。
5.1做介面測試時，等後端告訴前端介面弄好了，前端和後端開始調介面時，此時做介面測試用postman寫介面測試的用例
6.一輪測試：
待冒煙測試通過，則可以開始執行第一輪的測試。發現的bug使用缺陷管理工具（如jira/redmine/禪道等）記錄下來。
7.N輪測試：
如果有必要，則進行第二輪、第三輪、第N輪的測試
5個黑盒測試方法（等價類/邊界值、決策表、狀態轉換圖、決策樹和正交測試法）和7個白盒測試（語句、分支、條件、判定/條件、MC/DC、路徑和控制流覆蓋）方法。
8.迴歸測試：
待研發人員修復的bug後，即可進行迴歸測試。主要是驗證缺陷是否真的修復，是否會影響現有系統的使用。
9.寫總結測試報告：
之後就可以開始撰寫測試報告、使用者手冊等相關文件。測試報告要能反映本次測試的目標、範圍、物件、執行過程即結論和風險分析。

軟體錯誤產生的原因

1.需求說明說中的包含錯誤需，或者漏掉一些需求，或沒有準備表達客戶所有需求內容
2.需求說明中有些功能不可能或無法實現
3.系統設計的不合理
4.系統程式中錯誤
5.程式到程式碼中的問題，包括錯誤的演算法，複雜的邏輯等等
技術問題導致的缺陷：演算法錯誤，語法錯誤，計算和精度問題，系統結構不合理，演算法不科學，搞成系統效能地下，介面引數傳遞不匹配，導致模組整合出現問題
團隊工作：研發對系統需求不清楚，或者和使用者溝通出問題，不同級別的研發人員相互理解不一致，對軟體設計對需求分析結果存在理解偏差，對說明書某些內容重視不夠，或存在誤解。
軟體本身：
文件錯誤，內容不正確或者拼寫錯誤
沒有考慮大量資料使用場合，從而可能引起負載問題
對程式邏輯路徑或者資料範圍的編輯考慮不夠周全，漏掉幾個邊界條件造成容量或邊界錯誤
對一些實時應用的系統要精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題
沒有考慮系統崩潰後自我恢復或者資料的異地備份，災難性對付，從而存在系統安全性，可靠性的隱患
硬體或者系統軟體存在的錯誤
軟體開發標準或者過程上的錯誤

軟體測試的目的：就是儘可能找出軟體中的缺陷，叫開發人解決bug,從而提高軟體的正確性，可靠性

常用的測試平臺

BUG管理工具：禪道、Jira、Bugzilla等。

web端自動化測試工具：selenium、QTP等。

app自動化測試工具，有Appium，MonkeyRunner、Robotium等，

效能測試工具主要是Loadrunner和Jmeter，postman

抓包分析工具wireshak、fiddler。

資料庫工具：mysql/oracle，navicat

白盒測試方法論：

邏輯覆蓋：以程式的內部邏輯結構為基礎，分為語句覆蓋，判斷覆蓋，判定-條件覆蓋，條件組合覆蓋等
基本路徑測試：在程式控制流程的基礎上，分析控制構造的環路複雜性，匯出基本可執行路徑集合，從而設計測試用例

1.1.1語句覆蓋法的基本思想是設計若干測試用例，執行被測程式，使程式中的每個可執行語句至少被執行一次

1.1.2判定覆蓋法的基本思想是設計若干用例，執行被測程式，使得程式中每個判斷的取真分支和假取分支至少經歷一次，即判斷真假均曾被滿足，也陳分支覆蓋

1.1.3條件覆蓋的基本思想是被設計若干測試用例，執行被側程式以後，要使每個判斷中每個條件的可能取值至少滿足一次

1.1.4判定-條件覆蓋是判定和條件覆蓋設計方法的交集，即設計足夠的測試用例，使得判斷條件中的所有條件可能取值至少執行一次，同時，所有的判斷的可能結果至少被執行一次

1.1.5條件組合覆蓋的基本思想是設計足夠的測試用例，使得判斷中每個條件的所有的可能組合都至少出現一次

1.1.6路徑覆蓋就是設計所有的測試用例，來覆蓋程式中的所有可能執行的路徑

1.1.7 條件組合+路徑測試

1.1.8基本路徑測試就是在程式控制流圖的基礎上，通過分析構造的環路複雜性，匯出基本可執行路徑集合，從而設計測試用例的方法

黑盒測試方法

1.等價類劃分法
2.邊界值分析法
3.判定表方法
4.因果圖法
5.正交試驗法
6.功能圖法
7.錯誤推測法

單元測試

測試的4個階段：單元測試→整合測試→系統測試→驗收測試
1.按階段進行測試是一種基本的測試策略

單元測試定義：是對軟體基本組成單元進行的測試
時機：在程式碼完成後
概念：模組，元件，單元
意義：儘早發現錯誤和檢查程式碼是否符合設計和規範
目標：
資訊能否正確地流入和流出單元
在單元工作過程中，其內部資料能否保持其完整性，包括內部資料的形成，內容及相互關係不發生錯誤，包括全域性變數在單元中的處理和影響
在為限制資料加工而設定的邊界處，能否正確工作
單元執行能否做到滿足特定的邏輯覆蓋
單元中發生錯誤，其中的出錯處處理措施是否有效

1、模組獨立執行通路測試：檢查每一條獨立執行路徑的測試，保證每條語句被至少執行一次
誤解或用錯了運算子優先順序
混合型別運算
變數初值錯
精度不夠
表示式符號錯等等

任務2:模組區域性資料結構測試
檢查區域性資料結構完整性
Checklist:
不適合或不相容的型別說明。變數無初值。
變數初始化或預設值有錯。
不正確的變數名或從來未被使用過。出現上溢或下溢和地址異常。
其它

任務3:模組介面測試
檢查模組介面是否正確，checklist:輸入的實際引數與形式引數是否一致。
個數、屬性、量綱
呼叫其他模組的實際引數與被調模組的形參是否一致。個數、屬性、量綱
全程變數的定義在各模組是否一致。外部輸入、輸出
檔案、緩衝區、錯誤處理其它
任務4:模組邊界條件測試
檢查臨界資料處理的正確性
Checklist:
普通合法資料的處理。普通非法資料的處理。
邊界值內合法邊界資料的處理。邊界值外非法邊界資料的處理。其它

6.1整合測試的模式
漸增式測試模式與非漸增式測試模式
非漸增式測試模式:先分別測試每個模組，再把所有模組
按設計要求放在一起結合成所要的程式，如大棒模式。
漸增式測試模式:把下一個要測試的模組同已經測試好的
模組結合起來進行測試，測試完以後再把下一個應該測試的模組結合進來測試。
各自的優缺點
自頂向下和自底向上整合方法
————
驅動程式/驅動模組（driver) ，用以模擬被測
模組的上級模組。驅動模組在整合測試中接受測試資料，把相關的資料傳送給被測模組，啟動被測模組，並列印出相應的結果。
樁程式/樁模組(stub)，也有人稱為存根程式，
用以模擬被測模組工作過程中所呼叫的模組。樁模組由被測模組呼叫，它們一般只進行很少的資料處理，例如列印入口和返回，以便於檢驗被測模組與其下級模組的介面

效能測試

效能測試(Performance test)通過測試以確定系統執行時的效能表現，如得到執行速度、響應時間、佔有系統資源等方面的系統資料。
壓力測試
壓力測試(Stress test)，也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及使用者使用過程的系統負荷，長時間或超大負荷地執行測試軟體，來測試被測系統的效能、可靠性、穩定性等。

併發效能測試
考察客戶端應用的效能，測試的入口是客戶端併發效能測試的過程，是一個負載測試和壓力測試的過程。即逐漸增加併發虛擬使用者數負載，直到系統的瓶頸或者不能接收的效能點，通過綜合分析交易執行指標、資源監控指標等來確定系統併發效能的過程。併發效能測試是負載壓力測試中的重要內容。

疲勞強度測試
通常是採用系統穩定執行情況下能夠支援的最大併發使用者數或者日常執行使用者數,持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度效能的過程。
疲勞強度測試案例制定的原則是保證系統長期不間斷執行的業務量，並且應該儘量去滿足該條件。

大資料量測試
■獨立的資料量測試
針對某些系統儲存、傳輸、統計、查詢等業務進行大資料量測試
■綜合資料量測試
和壓力效能測試、負載效能測試、併發效能測試、疲勞效能測試相結合的綜合測試方案

容量測試**
容量測試目的是通過測試預先分析出反映軟體系統應用特徵的某項指標的極限值（如最大併發使用者數、資料庫記錄數等)，系統在其極限值狀態下還能保持主要功能正常執行。容量測試還將確定測試物件在給定時間內能夠持續處理的最大負載或工作量。
*
安全性測試
安全性測試是檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如:
想方設法擷取或破譯口令;
專門開發軟體來破壞系統的保護機制;
故意導致系統失敗，企圖趁恢復之機非法進入;試圖通過瀏覽非保密資料，推導所需資訊等等。
理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此係統安全設計的準則是，使非法侵入的代價超過被保護資訊的價值，此時非法侵入者已無利可圖。