[軟件測試][概論和基礎][一][學習筆記]

1.軟件測試概論

軟件測試是伴隨軟件的產生而產生的，有了軟件生產和運行就必然有軟件測試。早期的軟件開發過程中，測試等同于調試，目的是糾正軟件中已知的錯誤，通常由開發人員自己完成。對測試投入極少，介入的時間也很晚，常常等到產品基本完成時才進行測試。

直到1957年，軟件測試才開始與調試區別開來，成為一種發現軟件缺陷的活動。但測試工作仍然后于開發的活動。1972年在北卡羅萊納大學舉行了首屆軟件測試會議，1975年John Good Enough和Susan Gerhart在IEEE上發表了"測試數據選擇的原理（Toward a Theory of Test Data Selection）"的文章，軟件測試才被確定為一種研究方向。而1979年，Glen ford Myers的《軟件測試藝術》（The Art

of Software Testing）算是軟件測試領域的第一本最重要的著作，Myers對測試定義是：測試是為發現錯誤而執行的一個程序或者系統的過程。Myers和他的同事在20世紀70年代的工作是測試過程發展的里程碑。

20世紀80年代早期，"質量"號角開始吹響。軟件測試定義發生了改變，測試不單純是一個發現錯誤的過程，而且包含軟件質量評價的內容。軟件開發人員和測試人員開始坐在一起討論軟件工程和測試問題，制定了各類標準，包含IEEE（Institute of Electrical and Electronic Engineers）標準、美國ANSI（American National Standard Institute）標準以及ISO（International Standard Organization）國際標準。1983年，Bill Hetzel在《軟件測試完全指南》（Complete Guide of Software Testing）一書中指出：測試是以評價一個程序或者系統屬性為目標的任何一種活動，測試是對軟件質量的度量。Myers和Hetzel的定義至今仍被引用。

20世紀90年代，測試工具開始流行。2002年，Rick和Stefan在《系統的軟件測試》（Systematic Software Testing）書中對軟件測試做了進一步的定義：測試是為了度量和提高被測試軟件的質量，對測試軟件進行工程設計、實施和維護的整個生命周期過程。

隨著計算機和軟件技術的飛速發展，軟件測試技術研究也取得了很大突破，測試專家總結了很好的測試模型，比如V模型、W模型等，在測試過程改進方面提出了TMM（Testing Maturity Model）概念，在單元測試、自動化測試、負載壓力測試以及測試管理等方面也出現了大量優秀的測試工具。

2.軟件測試基礎

2.1.軟件測試和軟件質量

2.1.1.什么是軟件測試

測試（test）最早出現在古拉丁字，它有"罐"或"容器"的含義。在工業制造和生產中，測試被當作一個常規的檢驗產品質量的生產活動。測試的含義：以檢驗產品是否滿足需求為目標。而軟件測試活動包括了很重要的任務，即發現錯誤。

"軟件測試"的經典定義是在規定條件下對程序進行操作以發現錯誤，對軟件質量進行評估。

軟件是由文檔、數據以及程序組成的，那么軟件測試就應該是對軟件形成過程的文檔、數據以及程序進行的測試，而不僅是對程序進行測試。

隨著人們對軟件工程化的重視以及軟件規模的擴大，軟件分析、設計的作用越來越突出，多數軟件錯誤并不是程序錯誤，而是分析和設計錯誤。因此，做好軟件需求和設計階段的測試工作就顯得很重要。這就是提倡軟件全生命周期測試的理念。

2.1.2.什么是軟件質量

1999年，軟件"產品評價"國際標準ISO 14598經典的"軟件質量"定義是：軟件特性的總和，軟件滿足規定或潛在用戶需求的能力。

2001年，軟件"產品質量"國際標準ISO 9126定義的軟件質量包括"內部質量"“外部質量”"使用質量"三部分。也就是說，"軟件滿足規定或潛在用戶需求的能力"要從軟件在內部、外部和使用中的表現來衡量。

2.1.3.測試和質量的區別

軟件測試人員的一項重要任務是提高軟件質量，但不等于說軟件測試人員就是軟件質量保證人員，因為測試只是質量保證工作的一個環節。

質量保證（QA）：質量保證的重要工作通過預防、檢查與改進來保證軟件質量。QA采用"全面質量管理"和"過程改進"的原理開展質量保證工作。所關注的是軟件質量的檢查與測量。QA工作是軟件生命周期的管理以及驗證軟件是否滿足規定的質量和用戶的需求，因此主要關注軟件開發過程、步驟和產物。

軟件測試：測試是對過程的產物以及開發的軟件進行剖析。測試人員要"執行"軟件，對過程中的產物-開發文檔和代碼進行走查，運行軟件，找出問題，報告質量。測試人員必須假設軟件存在問題，測試中的操作是為了找出更多的問題，而不僅僅是為了驗證正確性。對測試中發現的問題的分析、跟蹤與回歸測試也是軟件測試的重要工作，因此軟件測試是保證軟件質量的一個重要環節。

2.2.軟件測試目的

Grenford J. Myers就軟件測試目的提出了以下觀點。

測試是程序的執行過程，目的在于發現錯誤。

一個好的測試用例在于能發現至今未發現的錯誤。

一個成功的測試是發現了至今未發現的錯誤的測試。

Bill Hetzel提出測試目的不僅是發現軟件缺陷與錯誤，也對軟件質量進行度量和評估，以提高軟件質量。

測試的目的是以最少人力、物力和時間找出軟件中潛在錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質量，回避軟件發布后由于潛在軟件缺陷和錯誤造成的隱患所帶來的商業風險。

2.3.軟件測試原則

所有的軟件測試都應追溯到用戶需求。

這是因為軟件的目的是使用戶完成預定的任務，并滿足用戶的需求，而軟件測試所揭示的錯誤和缺陷使軟件達不到用戶需求。

應當把"盡早地和不斷地進行軟件測試"作為軟件測試者的座右銘。

在軟件生命周期各個階段都可能產生錯誤，所以不應把軟件測試看作是軟件開發的一個獨立階段的工作，應當把它貫穿到軟件開發的各個階段中。在需求分析和設計階段就應開始測試工作，編寫相應的測試文檔。同時，堅持在開發的各個階段進行技術評審與驗證，這樣才能盡早發現錯誤與預防錯誤。只要測試在生命周期中進行得夠早，就能夠提高被測軟件的質量，這就是預防性測試的基本原則。

完全測試是不可能的，測試需要終止。

想要進行完全的測試，在有限條件和時間下，找出所有缺陷和錯誤是不可能的。有三個原因：1，輸入量太大。2，輸出結果太多。3，路徑組合太多。因此要根據測試錯誤概率和軟件可靠性要求，確定最佳停止測試時間。

測試無法顯示軟件潛在的缺陷。

進行測試是可以查找并報告發現的軟件缺陷和錯誤，但不能保證能找到所有的缺陷和錯誤。

充分注意測試中的群集現象。

測試后程序殘存的錯誤數目與該程序中已發現的錯誤數目成正比。應對錯誤群集的程序段進行重點測試以提高測試投資的效益。

程序員應避免檢查自己的程序

由于思維定勢，人們難以發現自己的錯誤。因此，應由獨立的測試部門進行測試。

盡量避免測試的隨意性。

應該從工程的角度去理解軟件測試，它是有組織、有計劃、有步驟的活動。

2.4.軟件測試對象

軟件包括程序、數據以及文檔，軟件測試應貫穿整個軟件生命周期中。在軟件生命周期中，各階段有不同的測試對象。需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都是測試的對象。在編碼結束后，對編寫的每一個程序模塊進行測試，稱為"模塊測試"或"單元測試"；在模塊集成后，對集成在一起的模塊組件，稱為"集成測試"；在集成測試后，需要檢測軟件是否滿足軟件需求說明書中規定的要求，稱為"確認測試"；將整個軟件模塊集成為軟件系統，安裝在運行環境下，對硬件、網絡、操作系統及支撐平臺構成的整體系統進行測試，稱為"系統測試"。

驗證（verification）是保證軟件正確實現特定功能的一系列活動和過程，目的是保證軟件生命周期中的每一個階段的成果滿足上一個階段所設定的目標。

確認（validation）是保證軟件滿足用戶需求的一系列活動和過程，目的是在軟件開發完成后保證軟件與用戶需求相符合。

2.5.軟件測試分類

2.5.1.按開發階段劃分

按開發階段劃分軟件測試可分為：單元測試、集成測試、系統測試、確認測試和驗收測試。

單元測試

單元測試也叫模塊測試，針對軟件設計的最小單元-程序模塊進行正確性檢驗。目的在于檢查每個程序單元能否正確實現詳細設計說明中的模塊功能、性能、接口和設計約束等要求，發現各模塊內部存在的錯誤。單元測試需要從程序內部結構出發設計測試用例。多個模塊可以獨立平行進行單元測試。

集成測試

集成測試也叫組裝測試。在單元測試基礎上，將所有程序模塊進行有序遞增的測試。檢驗程序單元或部件的接口關系，逐步集成為符合概要設計的程序部件或整個系統。

集成的過程是一個持續的過程，會形成很多臨時版本，功能集成的穩定性是真正的挑戰。在每個版本提交時，都需要進行冒煙測試，即對程序主要功能進行驗證。冒煙測試也叫版本驗證測試、提交測試。

確認測試

確認測試是通過檢驗和提供客觀證據，證明軟件是否滿足特定預期用途的需求。確認測試是檢測與證實軟件是否滿足需求說明書中規定的要求。

系統測試

系統測試是為驗證和確認系統是否達到其原始目標，而對集成的硬件和軟件系統進行測試。是在真實或模擬系統運行的環境下，檢查完整的程序系統能否和系統（硬件、外設、網絡和系統軟件等）正確配置、連接，并滿足用戶需求。

驗收測試

按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審，決定是否接受或拒收系統。

2.5.2.按測試實施組織劃分

按照實施組織劃分，軟件測試可分為開發方測試、用戶測試（β測試）、第三方測試。

通常叫"驗證測試"或"α測試"。開發方通過檢測和提供客觀證據，證實軟件的實現是否滿足規定的需求。α測試是在軟件開發環境下，有開發者檢測與證實軟件的實現是否滿足軟件設計說明或軟件需求說明的要求。主要是指在軟件開發完成后，開發方對要提交的軟件進行全面的自我檢查與驗證，可以和軟件的"系統測試"一并進行。

在用戶的應用環境下，用戶通過使用軟件，檢測軟件實現是否符合自己預期的要求。通常情況用戶測試不是指用戶的"驗收測試"，而是指用戶的使用性測試，找出軟件應用過程中發現的軟件缺陷問題，對使用質量進行評價。β測試通常看成一種"用戶測試"。β測試是把軟件產品有計劃地免費分發到目標市場，讓用戶大量使用，并評價、檢查軟件。通過用戶各種方式的大量使用，來發現軟件存在的問題與錯誤，把信息反饋給開發者修改。β測試中廠商獲取地信息，可以有助于軟件產品地成功發布。

介于軟件開發方和用戶方之間地測試組織地測試。第三方測試也稱為獨立測試。軟件質量工程強調開展獨立驗證和確認（IV&V）活動。是由在技術、管理和財務上與開發組織具有規定程度獨立地組織執行驗證和確認過程。軟件第三方測試也就是由在技術、管理和財務上與開發方和用戶方相對獨立的組織進行軟件測試。一般情況下是在模擬用戶真實應用環境下，進行軟件確認測試。

2.5.3.按測試技術劃分

按照測試技術劃分：白盒測試、黑盒測試、灰盒測試。也可劃分為靜態測試和動態測試。

靜態測試是指不運行程序，通過人工對程序和文檔進行分析與檢查；又稱為靜態分析技術，靜態測試實際上是對軟件中的需求說明書、設計說明書、程序源代碼等進行非運行的檢查。

靜態測試包括：走查、符號執行、需求確認等。

動態測試是指通過人工或使用工具運行程序進行檢查、分析程序的執行狀態和程序的外部表現。

通過對程序內部結構的分析、檢測來尋找問題。白盒測試可以把程序看成裝在一個透明的白盒子里，也就是清楚了解程序結構和處理過程，檢查是否所有的結構及路徑都是正確的，檢查軟件內部動作是否按照設計說明的規定正常進行。又稱結構測試。

通過軟件的外部表現來發現其缺陷和錯誤。把測試對象看成一個黑盒子，完全不考慮程序內部結構和處理過程。黑盒測試是在程序界面處進行測試，只是檢查程序是否按照需求規格說明書的規定正常實現。

介于白盒和黑盒之間。關注輸出對于輸入的正確性；同時也關注內部表現，但不像白盒測試那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態。

開發文檔和源碼可以應用單元測試應用走查方法；單元測試可應用白盒測試；集成測試應用灰盒測試；系統測試和確認測試應用黑盒測試。

2.6.軟件測試過程模型

2.6.1.V模型

V模型最早是由Paul Rook在20世紀80年代后期提出的，V模型在英國國家計算中心文獻中發布，皆在改進軟件開發的效率和效果。

在傳統開發模型比如瀑布模型中，人們通常把測試過程作為在需求分析、概要設計、詳細設計和編碼全完成后的一個階段，盡管有時測試工作會占用整個項目周期一半的時間，但有人仍認為測試只是一個收尾工作，而不是主要的過程。V模型的推出就是對這種認知的改進。V模型是瀑布模型的變種，反映了測試活動與分析和設計的關系，從左到右，描述了基本的開發過程和測試行為，非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系，如下圖所示，圖中的箭頭代表了時間方向，左邊下降的是開發過程各階段，對應右邊上升部分是各測試過程的各個階段。

V模型的軟測策略既包含低層測試又包含高層測試，低層驗證源代碼正確性，高層驗證整個系統滿足用戶需求。

V模型指出，單元和集成測試是驗證的程序設計，開發人員和測試組應檢測程序的執行是否滿足軟件設計的要求；系統測試應當驗證應當驗證系統設計，檢驗系統功能、性能的質量特性是否達到系統設計的指標，由測試人員和用戶進行軟件的確認測試和驗收測試，追溯軟件需求說明書進行測試，以確定軟件的實現是否滿足用戶需求或合同的要求。

V模型有一定局限性，僅僅把測試過程作為在需求分析、概要設計、詳細設計及編碼之后的一個階段。容易使人理解為測試是在軟件開發的最后一個階段，主要是針對程序進行測試尋找錯誤，而需求分析階段隱藏的問題一直到后期的驗收測試才被發現。

2.6.2.W模型

V模型局限性在于沒有明確地說明早期的測試，不能體現"盡早地和不斷地進行軟件測試"的原則。在V模型中增加軟件各開發階段應同步進行的測試，演化為W模型，實際上開發是"V"，測試的和開發并行的"V"。W模型如下圖所示：

W模型有Evolutif公司提出。它強調：測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。這樣，只要相應的開發活動完成，我們就可以開始執行測試，測試與開發同步進行，有利于盡早發現問題。以需求為例，需求分析一完成，就可以對需求進行測試，不用等到最后才進行針對需求的驗收測試。

W模型有其局限性。W模型和V模型都把軟件的開發視為需求、設計、編碼等一系列串行的活動。同樣的，軟件開發和測試保持一種線性的前后關系，上階段完成才能進行下一階段。這樣就無法支持迭代、自發性以及變更調整。

2.6.3.H模型

V模型和W模型都把軟件的開發視為需求、設計、編碼等一系列串行的活動，而事實上大部分時間內，它們是可以交叉進行的。同時，各層次之間的測試也存在反復觸發、迭代和增量關系。其次，V、W模型沒有很好體現測試流程的完整性。

為了解決以上問題，有專家提出了H模型，它將測試活動完全獨立出來，形成一個獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。H模型的示意圖如下：

示意圖僅僅演示了整個生產周期中某個層次上的一次測試"微循環"。圖中的其他流程可以是任意開發流程。也就是說，只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以進行了。在H模型中，測試模型是一個獨立的流程，貫穿于整個產品周期，與其他流程并發地進行。

H模型揭示了：

軟件測試不僅僅指測試的執行，還包括很多其他活動

軟件測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程并發地進行。

軟件測試要盡早準備，盡早執行。

軟件測試是根據被測物地不同而分層次進行的。不同層次的測試活動可以是按照某個次序先后進行的，也可能是反復的。

2.6.4.X模型

X模型的基本思想是由Marick提出的，目標是彌補V模型的一些缺陷。如下圖所示：

X模型左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后，將進行頻繁的交接，通過集成最終合成為可執行的程序。而且這些可執行程序還需要進行測試，已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規模和范圍內集成的一部分。

X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤。

2.6.5.測試模型的使用

任何模型都是不完美的，盡可能應用模型中對項目有實用價值的方面，不能為使用模型而使用模型。在實際工作中，我們要靈活運用各種模型的優點，在W模型的框架下，運用H模型的思想進行獨立地測試，并同時將測試和開發緊密結合，尋找恰當地就緒點開始測試并反復迭代測試，最終保證按期完成預定的目標。

2.7.軟件生命周期測試策略

2.7.1.軟件開發和軟件測試

軟件開發過程是一個自頂向下，逐步細化的過程。首先，在軟件計劃階段定義了軟件的作用域，然后進行軟件需求分析，建立軟件的數據域、功能和性能需求、約束及一些有效性準則。接著進入軟件開發、軟件設計，把設計用某種編程語言轉換成代碼。而測試過程則是按照相反的順序安排自底向上，逐步集成的過程。低一級測試為上一級測試準備條件。不排除兩者平行進行測試。

如下圖所示，首先對每一個程序模塊進行單元測試，消除程序模塊內部在邏輯上和功能上的錯誤和缺陷。再對照軟件設計進行集成測試，檢測和排除子系統（或系統）結構上的錯誤。隨后再對照需求，進行確認測試。最后從系統整體出發，運行系統，看是否滿足要求。

2.7.2.軟件測試策略

測試過程按4個步驟進行，即單元測試、集成（組裝）測試 、確認測試和系統測試。

開始是單元測試，檢查各個程序是否正確實現規定的功能。然后，把已測試過的模塊組裝起來，進行集成測試（組裝測試），主要對與設計相關的軟件體系結構的構造進行測試。再將一個個實施了單元測試并確保無誤的程序模塊組裝成軟件系統的過程中，對正確性和程序結構等方面進行檢查。確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。最后是系統測試，把已經經過確認的軟件納入實際運行環境中，與其他系統成分組合在一起進行測試。

自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。