最近，有幾個朋友向我了解關於軟體測試的工作內容及前景，由於自己才兩年多的工作經驗，也沒給出特別實質性的建議，於是就想總結一篇軟體測試方面的知識，希望能幫到一些朋友，最主要的還是對自己兩年來的工作進行乙個總結！也算是給自己乙個交代吧^.^
軟體測試概念
軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。《軟體測試的藝術》給出的定義：
所謂軟體測試，就是乙個過程或一系列過程。用來確認計算機**完成了其應該完成的功能，不執行其不該有的操作。通俗點說，軟體測試是為了發現錯誤執行程式的過程，驗證軟體做了其應該做的事情，沒有做其不應該做的事情。舉例說明：
比如說老闆要你造一雙筷子，你卻造了乙個勺子，這叫需求不符；於是你連夜趕工造了一雙竹筷子給老闆，老闆開開心心拿著新筷子去吃飯，誰想新筷子的分叉刺破了老闆的嘴巴，然後你被劈頭蓋臉臭罵了一頓，這叫缺陷；最後你吸取教訓又重造了一雙世界上最完美的筷子，老闆對此讚不絕口，不計前嫌給你公升職加薪，從此走向人生巔峰。
軟體缺陷的定義
從上面的栗子又引申出另乙個概念：軟體缺陷（bug）。《軟體測試》一書中這樣定義的：
軟體沒有實現產品的說明書所描述的功能。其實，說到底軟體測試的本質就是為了發現更多的缺陷，從而提公升軟體質量，但是我們要知道窮盡測試是不可能的。軟體實現了產品說明書描述不應有的功能。
軟體執行了產品說明書沒講的操作
軟體沒有實現產品說明書沒講但應該實現的功能。
從軟體測試員的角度來看，軟體難以理解、不易使用、執行緩慢，或者終端使用者認為不對。
測試與開發各階段的關係
需求分析→驗收測試
概要設計→系統測試
詳細設計→整合測試
編碼開發→單元測試
需求分析與驗收測試
1、需求分析（熟悉業務）
淺說軟體需求分析
測試需求分析總結
需求分析就是需要弄清楚使用者需要的是什麼功能，使用者會怎樣使用功能，這樣我們測試的時候才能更加清楚的知道系統該怎麼執行，才能更好的設計測試用例，才能更好的測試。軟體測試需求分析主要是熟悉軟體需求文件，劃分測試點，定義測試範圍和優先順序，細分測試點並確定測試策略和測試方法，包括功能性測試、白盒測試、靜態測試和動態測試、效能測試、相容性測試、安全性測試等，對測試需求進行管理，根據測試需求編寫測試用例。
作為軟體測試人員，那我們如何做好測試需求分析呢？
軟體測試是以使用者需求為中心的，站在使用者的角度去看待系統，使用系統
查閱需求文件說明書，熟悉系統的業務流程，實際操作具體的功能模組。舉個例子，讓你去測試吃雞遊戲，首先你得熟悉遊戲規則，知道怎麼去玩，才能更好開展測試。
熟悉業務資料表，不同的操作會產生不同的資料和關聯。測試需求分析過程可以根據系統資料流，劃分測試點。
了解系統框架，用到的第三方介面，具體使用者數量，生產環境配置等
2、驗收測試
驗收測試常用三種策略：正式驗收測試、α測試和β測試
（1）正式驗收是測試：是一項管理嚴格的過程，它通常是系統測試的延續。計畫和設計這些測試的周密和詳細程度不亞於系統測試。選擇的測試用例應該是系統測試中所執行測試用例的子集。不要偏離所選擇的測試用例方向，這一點很重要。在很多組織中，正式驗收測試是完全自動執行的。
（2）α測試：是由乙個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的測試。不能由程式設計師或測試員完成。
（3）β測試：是由軟體的乙個或多個使用者在實際使用環境下進行的測試。不能由程式設計師或測試員完成，由使用者測試記錄問題定期向開發人員反饋
驗收測試是部署軟體之前的最後乙個測試操作。在軟體產品完成了單元測試、整合測試和系統測試之後，產品發布之前所進行的軟體測試活動。它是技術測試的最後乙個階段，也稱為交付測試。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。
概要設計與系統測試
1、概要設計
概要設計是乙個設計師根據使用者互動過程和使用者需求來形成互動框架和視覺框架的過程，其結果往往以反映互動控制項布置、介面元素分組以及介面整體板式的頁面框架圖的形式來呈現。這是乙個在使用者研究和設計之間架起橋梁，使使用者研究和設計無縫結合，將對使用者目標與需求轉換成具體介面設計解決方案的重要階段。概要設計的主要任務是把需求分析得到的系統擴充套件用例圖轉換為軟體結構和資料結構。2、系統測試概要設計范文
系統測試是將經過整合測試的軟體，作為計算機系統的一部分，與系統中其他部分結合起來，在實際執行環境下對計算機系統進行的一系列嚴格有效地測試，以及發現軟體潛在的問題，保證系統的正常執行。主要內容包括
詳細設計與整合測試
1、詳細設計
詳細設計的目的是說明乙個軟體系統各個層次中的每個程式（每個模組或子程式）和資料庫系統的設計考慮，為程式設計師編碼提供依據。2、整合測試
整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求（如根據結構圖）組裝成為子系統或系統，進行整合測試。整合測試屬於灰盒測試：驗證介面是否與設計相符合和發現設計和需求中存在的錯誤。單元測試與編碼
單元測試和編碼主要是由程式猿做的，這裡就不再做總結。
注意：提測前理論上開發人員都是要做ut的，但是每個開發水平不一樣，導致提測質量參差不齊，如果某些開發的提測質量一直不佳，測試人員可以設計幾個主要流程的場景用例，讓開發自測，自測通過後再提測。或者測試人員也可以對提測後的專案進行冒煙測試。
軟體測試的基本流程
（1）測試需求分析階段：閱讀需求文件，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議。
（2）測試計畫階段：主要任務就是編寫測試計畫，參考軟體需求規格說明書，專案總體計畫，內容包括測試範圍（來自需求文件），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規矩措施有乙個制定。
（4）測試執行階段：搭建環境，執行冒煙測試（**試），然後進入正式測試，bug管理直到測試結束。
（5）測試評估階段：測試報告總結，確認是否可以上線。
開發流程：了解使用者需求–》進行需求分析–》得知功能組成及設計軟體結構–》開發設計計畫–》概要設計–》詳細設計–》進行軟體編碼–》單元測試–》**審查–》打包提交給測試部–》測試部返回bug–》更新修復bug–》再次進入測試部測試–》直到bug解決–》版本上線–》面向使用者使用
測試流程：了解使用者需求–》參考需求規格說明書–》測試計畫（人力物力時間進度的安排）–》編寫測試用例–》評審用例–》搭建環境–》測試包安排**（冒煙測試）-正式測試-bug-測試結束出報告–》版本上線–》面向使用者
需求分析階段
我們的需求分析比較簡單，主要是劃分功能模組（what），計畫測試時間（when）和人力（who），測試環境配置（where）以及測試策略（how）
可參考部落格，如何分析軟體測試需求：軟體測試需求分析方法
測試計畫階段
我們的測試計畫主要包含以下內容：
測試專案包含哪些模組需要測試
測試計畫和實際起始時間，模組負責人
備註計畫變更以及測試情況記錄
怎樣編寫出乙份好的測試計畫
測試設計階段
根據需求分析文件或者其他相關文件進行測試用例設計，深入分析文件中的字眼，簡單劃分測試點，包括前提條件，預期輸入輸出等，用例設計完成後需要進行用例評審，用例評審在我看來是很有必要的完善用例的手段之一。
常用的測試用例設計方法傳送門：軟體測試用例設計常用7大方法
測試執行階段
以下主要是我的測試工作流程：
提測後jenkins自動發布程式，執行sql指令碼，更新其他第三方介面環境等，對每個提測版本打標籤（版本控制）
大型專案需要進行冒煙測試，冒煙測試通過後才能進入系統測試。
按照測試計畫，分模組執行測試用例並記錄執**況，提交bug至缺陷管理系統。
每天向專案組匯報測試進度，反饋測試問題（比如嚴重缺陷），嚴重影響測試進度則需要修改測試計畫。
所有中高等級的bug需要全部解決，低等級的bug根據專案計畫來決定是否解決，全部bug修復完成後，再對所有bug進行一次回歸。
測試評估階段
傳送測試報告，主要包含以下內容：
根據測試團隊制定的規則判定軟體測試是否通過
測試負責人，時間，測試主要內容
缺陷數量和用例執**況統計，未解決的bug的風險分析
測試環境配置，**指令碼路徑，軟體版本號等
寫在最後
軟 件 測 試 基 礎 知 識
軟體效能指標主要有響應時間，系統響應時間和應用延遲時間，吞吐量，併發使用者數，資源利用率五種。軟體實現的演算法與系統響應時間和應用延遲時間是直接相關的，所以軟體的效能也必定與實現演算法是有關係的吞度量是指系統在單位時間內處理請求的數量，對於無鬢髮的應用系統而言，吞度量是與響應時間嚴格的反比關係，因為...
軟體測試基礎知識
1 發現軟體錯誤 2 有效定義和實現軟體部件由底層到高層的組裝過程 3 驗證軟體是否滿足任務書和系統定義文件所規定的技術要求 4 為軟體質量模型的建立提供依據。概念 軟體測試是軟體質量保證的關鍵組成部分，對軟體測試的認識可分為以下幾個階段 測試就是除錯階段 測試是證明軟體正確階段 測試是發現軟體中錯...
軟體測試基礎知識
本人部落格文章 1.確認軟體的質量 a.是確認軟體做了你所期望做的事情 do the right thing b.是確認軟體以正確的方式來做了這個事情 do it right 2.是提供資訊 比如提供給開發人員或程式經理的回饋資訊，為風險評估所準備的資訊 3.是在測試軟體軟體產品本身，而且還包括軟體...