1. 軟件測試定義

首先要明確測試的定義,所謂測試,就是以檢驗產品是否滿足需求為目標。
而軟件測試,自然是為了發現軟件(產品)的缺陷而運行軟件(產品)
比較標準的軟件測試的定義是:在規定的條件下對程序進行操作，以發現錯誤，對軟件質量進行評估。

IEEE 標準的定義:使用人工或自動的手段來運行或測定某個系統的過程，其目的在于檢驗;它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。

軟件測試的目的：
測試目的會隨著不同測試階段而有所側重點，主要體現在：

1）發現缺陷

盡早和盡量多的發現被測對象中的缺陷，應該是測試人員測試過程中最常提起的一個測試目標，也是所謂測試價值的一個的重要體現。發現缺陷的目的是推動開發人員定位和修復問題，測試人員通過再測試和回歸測試，確保開發人員已修復缺陷，并沒有影響原來正常的區域，從而提高產品質量。開發生命周期的每個階段，都應該有測試的參與，并盡量多的發現本階段的缺陷，從而大大提高本階段的缺陷階段遏制能力，從而提高測試效率、降低成本和提高質量。

軟件產品的質量是多維度的，因此軟件測試的關注點不僅僅在被測對象的功能上面，各種非功能質量屬性都應該是測試的關注點。更多的產品質量屬性可參考標準ISO 9126 - 軟件產品質量。

2）增加信心

當測試過程中發現很少或沒有發現缺陷時，測試就可以幫助樹立對于軟件產品質量的信心。除了沒有發現缺陷時可以降低風險增加信心之外。通過測試增加信心還體現在：

（1）確認Verification：確認軟件產品描述的需求已經得到正確實現；

（2）驗證Validation：被測對象可以按照用戶/客戶的要求工作（客戶/用戶是多個層面的含義，不僅包括最終的用戶）；

例如：假如我們參加用戶現場的驗收測試，此時測試的主要目的是為了確保軟件產品可以正常工作，從而增加用戶對使用產品質量的信心。

3）提供信息

測試過程的每個階段都在為開發過程提供信息，包括給軟件產品的不同利益干系人提供不同維度不同詳細程度的信息。提供信息的主要目的是幫助利益干系人作出正確的決策：

（1）評估質量：通過測試過程提供的各種數據，可以幫助利益干系人評估被測軟件產品的質量。例如：根據測試過程中發現缺陷的累積趨勢、測試執行的進度數據、執行通過率和覆蓋率等，可以判斷軟件產品是否滿足計劃中定義的質量要求；

（2）評估進度：通過提供的各種數據，可以幫助管理人員作出是否能及時發布軟件產品的決策，包括評估：測試執行進度是否在計劃范疇內、開發修復缺陷進度是否滿足質量和發布要求等；

評估產品質量和進度情況，測試過程中提供的數據是非常重要的輸入。

4）預防缺陷

測試過程中發現的缺陷，以及遺漏到用戶現場的缺陷，都應該對它們進行缺陷根本原因分析，找到引入缺陷的主要原因。從測試角度也要分析為什么能發現缺陷，以及為什么缺陷會遺漏到用戶現場。

缺陷根本原因分析的目的是從以前軟件開發和測試過程中吸取經驗和教訓，避免同樣的問題重復發生，從而改進開發和測試過程。過程改進反過來可以預防相同的缺陷再次引入或遺漏，從而提高軟件產品質量，這也是軟件質量保證的重要一環。

發現缺陷、增加信心、提供信息和預防缺陷這4個測試目的同樣貫穿于整個生命周期，并且4個測試目標是相互支持和補充的。同時，不同階段、不同利益干系人對不同測試目標的要求和詳細程度都會不一樣。

2.軟件測試方法分類

3. 軟件測試原則

測試證明軟件存在缺陷
測試的本質是證明軟件存在缺陷，而不是軟件沒有缺陷。

人無完人，只要是人寫的代碼，肯定不能保證百分之百正確，除非特別簡單的功能。即便如此，也會存在各種環境問題，網絡問題等，更何況現在軟件原來越復雜，缺陷更是難以避免。

不可能執行窮盡測試
舉個很簡單的例子來說明，比如測試一個計算器功能里的加法，你可以嘗試1+1,1+2 ,1+3 …你能把所有數組相加的情況都測試嗎，所以窮盡測試時不可能的，更別提是實際情況中，項目進度還有明確時間節點。截止日期。

測試應盡早啟動，盡早介入
這條很重要，但是對測試的要求也會更高。
先來講為什么要盡早啟動，舉例說明，軟件工程和蓋房子一樣，先也得設計，打好地基，試想假如設計階段，或者地基沒打好，你后面樓房蓋得越高，推到重來，或者回頭再去修改所耗費的成本也就越大，所以，測試要盡早介入。

系統測試階段什么時候介入呢，對著需求文檔設計測試用例的時候，就開始測試了。軟件此時還在設計階段，測試站在質量和安全性角度，應該多多思考功能本身的可測試性，可靠性，完善用例的同時也可注意下 整個業務流程是否能形成完整的閉環。是否存在明顯的需求錯誤。

集成測試階段
還有一個場景，比如開發app時候，往往后端工程師 服務器先開發完成，此時無論ios還是android工程師都在開發中，等待更多接口完成，等待接口文檔。測試工程師此時便可以對著接口文檔，先進行服務器端的接口測試了。這樣聯調之前就可以先找到部分服務器缺陷，減少了前后端開發調試和糾錯時間。

單元測試階段
這個對測試來說有一定難度，多半還是開發人員自己完成，也就是每一個方法，類完成之后。自己對軟件的最小組成單元編寫測試代碼進行驗證。這就好像你蓋樓房，組成樓房的每一層階梯，每一塊磚頭質量先保證是好的。

缺陷存在群集現象（二八原則）
這個也是經驗之談了，一般認為，百分之80的缺陷集中出現在百分之20的核心功能區域。一旦你在某個功能模塊找到缺陷，相關附近功能多半也會存在問題。實戰中如何使用呢，寫缺陷報告的時候，做橫向對比，比對類似功能，相近模塊，版本，機型。指定回歸測試策略的時候，也可以重點測試。

殺蟲劑悖論
殺蟲劑悖論，很簡單，意思就是相同的功能，相同的用例，多次執行，后幾輪就慢慢找不到缺陷了。仿佛軟件對你的測試用例產生了抗藥性。所以，用例在每次執行完之后應該及時進行更新和維護，升級你的裝備。

不同測試活動依賴不同的測試背景
舉個例子來說明，你在金融公司測試，安全性就是第一位。電子商務測試，功能性則更加重要。

不存在缺陷的謬論
假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的。

4.軟件測試策略

因為軟件開發中測試資源和時間是有限的，測試需要策略，更何況測試總是有風險的，就更需要測試策略。什么是軟件測試策略？簡單地說，軟件測試策略就是在測試質量和測試效率之間的一種平衡藝術（Leverage Test）。更明確地說，測試策略是為了以最低的成本最大程度地揭示（／降低）產品的質量風險或盡早地完成測試所選擇（或制定的）的最合理／合適的方式、方法、過程等，這里：
最低的成本是指完成測試所需的資源、時間等最少，“最”是相對的，即基于目前的認識或能力所能做到的；

完成測試，即達到特定的測試目標，如達到測試覆蓋率的某個值、發現盡可能多的缺陷、完成所有主要功能特性的驗證，這也依賴于對“軟件測試”是如何理解的，或測試目標是如何定義的；

方式，包括手工方式、自動化方式；探索式測試或基于腳本的傳統測試；自己團隊測試還是眾測、外包；

方法，包括基于需求的、基于數據流、基于控制流、組合測試、形式化等方法、技術、工具等

過程：先測什么、后測試什么；對測試階段的不同劃分等。

**一般來說測試策略是測試計劃的一部分，但也不一完全是。**從一個項目來看，在測試需求、測試風險分析之后，需求制定測試策略盡量降低測試風險，在有限的資源和時間內達到測試目標。但通用的測試策略（如測試四象限）、測試分析策略（如啟發式測試策略HTSM）、自動化測試策略（如著名的金字塔策略）、通用的回歸測試策略就不屬于具體項目，也就不屬于測試計劃，但可能在測試計劃中可能采用或強調其應用。測試策略也不等同于測試方案，測試方案是找到如何測試對象的具體方法（完整的解決辦法），雖然包含項目級別的測試策略，但也包括具體的技術運用、新的工具定義／設計等。它們有相交，也有區別，見下面圖示。另外，測試策略也不僅僅指導測試設計，而且也指導測試的執行。

基于風險的測試策略是指評估測試項的優先級，先進行高優先級的測試項，或者／并 將測試的優質資源（包括人力、物力等）優先放在高優先級的測試項上。如果時間或精力不夠，低優先級的測試可以暫時不做。基于風險的測試，也就是根據事情的輕重緩急來決定測試工作的重點和工作的順序，而這建立在對測試風險的分析評估的基礎上。

5. 軟件測試模型

以下內容轉載自：http://www.51testing.com/html/70/n-4461370.html
按測試模式來分類： 瀑布模型、敏捷測試、基于腳本的測試、基于風險的測試、探索式測試等。

5.1 傳統瀑布模型

優點：

強調需求，設計的作用；

前一階段完成后只需關注后續階段；

為項目提供按階段劃分的檢查點，里程碑清晰

文檔規范

缺點：

線性研發過程難以適應需求的頻繁變化

項目周期后段才可看到成果，用戶要到末期才能看到開發結果，增加了開發的風險

強制的里程碑，對于開發過程中出現的變化，適應能力較差，

文檔工作量較大，測試在項目的后期，文檔的開發帶來很大的工作量。

5.2 V模型

優點：
　　在V模型里，強調軟件開發的協作和速度，反應測試活動和分析測試的關系，并且將軟件的實現和驗證有機的結合了起來，V模型，明確的界定測試過程是存在不同階段的。
缺點：
　　但是V模型也有一定的局限性,它僅僅把測試過程放在需求分析、系統設計、編碼之后的一個階段，忽視了測試對于需求的分析和驗證。我們對需求的驗證，對系統設計的驗證，到后期的驗收測試才有可能被發現，對于我們測試當中的測試需要盡早進行的原則在V模型中沒有體現，這是V模型的局限。

5.3 W模型（雙V模型）

優點：開發與測試并行，有利于盡早發現問題，有利于及時的了解項目的測試風險，來及早的執行相應的應對方案，加快項目的進度。
局限性：需求、設計、編碼仍然是串行進行的，測試和開發保持線性的關系，上一個階段完成之后才能進行下一個階段，不能夠很好的支持迭代的開發模型。

5.4 X模型

左邊描述的是針對單獨的程序片段相互分離的編碼和測試，此后進行頻繁的交接，再通過集成，最終合成可執行的程序，對這些程序進行測試，這些程序還是需要冀衡測試，已經通過的程序可以進行封板提交給用戶，也可以作為更大集成的一部分，X模型還定位了探索式測試，探索式測試是不進行事先計劃的特殊類型的測試，能夠幫助測試人員在測試計劃之外發現更多的錯誤。

5.5 H模型：

把軟件測試看成一個完全獨立的流程，與其他流程并發進行，比如設計流程，編碼流程，甚至是測試流程

H模型強調把測試分為測試準備和測試執行兩個不同的階段，只要由于其他流程的進展引發了測試就緒點的到位，這時候，只要測試準備不能完成，測試執行活動就可以或者需要開展，在H模型當中，測試是一個完全獨立的模型，所以可以和其他的流程交叉地進行，也便于我們盡早的執行測試。

最后總結一下：
如果你對此文有任何疑問，如果你也需要接口項目實戰，如果你對軟件測試、接口測試、自動化測試、面試經驗交流感興趣歡迎加入：軟件測試技術群：593462778，群里的免費資料都是筆者十多年測試生涯的精華。還有同行大神一起交流技術哦。

作者：暗潮洶涌
原創不易，歡迎轉載，但未經作者同意請保留此段聲明，并在文章頁面明顯位置給出原文鏈接。-

總結

以上是生活随笔為你收集整理的软件测试学习（一）软件测试基础知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。