前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇軟件測試范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

軟件測試范文第1篇

乙方（供測方）：_________

甲乙雙方經過平等協商，在誠信友好，充分地表達各自意愿的基礎上，根據《中華人民共和國合同法》的規定，達成如下協議，雙方共同遵守。

第一條　合同性質

本合同屬于軟件測試合同。

第二條　合同內容

乙方為甲方提供《_________軟件》的測試。

以下的測試款項，甲方在購買正式的軟件時，可作為正式購買軟件預付款的一部分抵扣，同時，測試期結束，此合同失效。

第三條　測試方式，費用及支付方式

測試方式為：賬號的測試；_________提供測試服務器測試；客戶出服務器，_________提供測試軟件。

支付方式：a．賬號的測試：合同簽訂后，乙方提供2個帶有_________的賬號（每個賬號有30分鐘的話費）話機或網關，提交甲方測試，測試的費用只收硬件的押金即可。測試結束，乙方按硬件的借側合同執行。b．_________提供測試服務器測試：由乙方提供整套的已裝有_________軟件帶有公網ip地址的服務器，其管理權由甲方控制，測試期為一個月，測試費用：_________元，合同簽訂后一次付清，即可將服務器的地址與密碼交予甲方。測試結束后全部收回。c．客戶出服務器，_________提供測試軟件：客戶按照乙方的要求將服務器，中繼網關配好后，提交乙方安裝_________軟件，具體的條款見本合同的第四、五、六、七條。測試期為_________個月，費用為_________元人民幣，合同簽訂后一次性付清。

第四條　合同執行期限

交貨：甲方將所需要的全部硬件設備配好后（硬件設備配置必須符合乙方系統的要求）；乙方應于甲方通知乙方安裝系統之日起_________個工作日內完成軟件系統的安裝和調試。

第五條　驗收標準及時間

乙方安裝和調試竣工資料（包括用戶手冊和／或維護手冊等）。

甲方接到乙方驗收通知后在現場安排驗收，驗收合格后，甲方以書面方式簽收。

第六條　系統培訓

甲方參加系統培訓的人員的基本的要求：熟悉并具有電信操作及運營經驗，熟悉英特網及寬帶網的協議及設計，能熟練操作msie6．0linux9．0cis，熟悉計算機及服務器系統的維護及簡單維修。

第七條　軟件服務內容

7．1　在_________網關及_________接通并通過_________驗收后，_________在_________個工作日內完成遠程_________網關軟件安裝及調試工作。

7．2　在服務器及完整的linux9．0操作系統安裝完畢并通過_________驗收后，_________在_________個工作日內完成遠程軟件安裝及調試工作。

7．3　在以上兩項工作完成之后，_________科技在5個工作日內完成遠程綜合調試工作并提交綜合測試報告。

7．4　售后服務條例：對于使用_________系統服務平臺的運營商，乙方提供許可軟件的售后服務支持

7．5　售后服務指標體系：乙方在接到甲方反映的技術問題30分鐘內電話聯系一級技術支持并開始工作。經常性問題在60分鐘內解決，為解決的問題提供120分鐘進展報告。有難度問題（在24小時內不能解決的問題），提供每12小時進展報告。

7．6　系統的安裝，調試及維護原則上由乙方負責。

7．7　乙方提供的技術支持為_________。

第八條　不可抗力

甲乙雙方的任何一方由于不可抗力的原因不能履行合同時，應及時向對方通報不能履行或不能完全履行的理由，在取得有關主管機關證明以后，允許延期履行，部分履行或者不履行合同，并根據情況可部分或全部免予承擔違約責任。

第九條　爭議解決方式

在合同履行過程中發生爭議，雙方應當協商解決。協商解決不成，雙方商定，采用向合同簽訂地仲裁委員會仲裁。

第十條　合同生效

本合同正本一式二份，甲乙雙方各執一份，經雙方簽字蓋章后生效。

甲方（蓋章）：_________乙方（蓋章）：_________

授權代表（簽字）：_________授權代表（簽字）：_________

軟件測試范文第2篇

關鍵詞：軟件測試；方法；技術

試

白盒測試也稱結構測試或邏輯驅動測試。它是按照程序內部的邏輯結構測試程序，主要關注代碼是否能夠正確執行。通過白盒測試可以檢測出產品內部動作是否按照設計規格說明書的規定正常工作，并檢驗程序中的每條通路是否都能按預定要求正確工作。白盒測試是把測試對象看作一個透明的盒子，軟件測試人員能夠依據程序內部邏輯結構等相關信息，設計或選擇測試用例，對程序進行測試。通過在不同的節點檢查程序的狀態，以保證實際的狀態和預期的狀態一致。

3.灰盒測試

灰盒測試，是介于白盒測試與黑盒測試之間的。可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不像白那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。

二、 軟件測試技術的策略

軟件測試并不單是軟件開發完成后的一個獨立的過程，而是貫穿于整個軟件開發的過程，根據軟件開發的周期不同，可以將軟件測試分為：單元測試、集成測試、確認測試、系統測試和驗收測試。

1.單元測試（Unit Testing）

單元測試是在軟件開發過程中能夠進行的最基礎的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重復的，無論是在軟件修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟件系統的生命周期中進行維護。

2.集成測試（Integrated Testing）

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求(如根據結構圖)組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。因此，單元測試后，有必要進行集成測試，發現并排除在模塊連接中可能發生的問題，最終構成要求的軟件子系統或系統。對子系統，集成測試也叫部件測試。

3.確認測試（Validation Testing）

確認測試又稱有效性測試。有效性測試是在模擬的環境下，運用黑盒測試的方法，驗證被測軟件是否能夠按照需求規格說明書中所要求的工作。任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規格說明書中已經明確規定，它包含的信息就是軟件確認測試的基礎。確認測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

4.系統測試（System Testing）

系統測試的任務是盡可能徹底地檢查出程序中的錯誤，提高軟件系統的可靠性，其目的是檢驗系統“做得怎樣”。這階段又可分為三個步驟：模塊測試，測試每個模塊的程序是否有錯誤；組裝測試，測試模塊之間的接口是否正確；確認測試，測試整個軟件系統是否滿足用戶功能和性能的要求。該階段結束應交付測試報告，說明測試數據的選擇，測試用例以及測試結果是否符合預期結果。

三、軟件測試未來發展方向

目前，軟件測試存在4個發展方向。

1.驗證技術

驗證的目的在于證明在軟件生命期各個階段，以及階段間的邏輯協調性和正確性。驗證技術目前僅適用于特殊用途的小程序。

2.靜態測試

正逐步地從代碼的靜態測試往高層開發產品的靜態測試發展。

3.測試用例的選擇

什么樣的測試用例是好的測試用例?可以從4個特性描述測試用例的質量，即有效性、仿效性、經濟性和修改性。

4.測試技術的自動化

這是一個最新的發展方向。自動測試也是一門技術，但與測試技術存在很大的區別。

參考文獻：

軟件測試范文第3篇

關鍵詞：軟件測試；集成測試；調用圖；MM-路徑

中圖分類號：TP317文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02

Analysis of Integration Testing of Software Testing

Hou Yanfang,Chu Shulai

(Zhoukou Vocational and Technical College,Zhoukou466001,China)

Abstract:The integration testing plays a very important role in software testing,the concept of integration testing,integration testing strategy and the main types of integration testing (phase) briefly discusses the analysis of several key integration testing.

Keywords:Software testing;Integration testing;Call graph;MM-path

軟件測試作為軟件質量保證的關鍵技術之一，其目的就是能夠有效地發現軟件中的錯誤或缺陷。集成測試是軟件測試中處于組件測試和系統測試之間一個非常重要的環節，這是因為所有組件都經過測試并能正常運行并不意味著這些組件放到一起經過集成后還能正常運行，正是基于這一點，很多大的軟件公司成立了專門關注集成測試的測試團隊，如能恰當實施，集成測試能大大減少一些在系統測試階段才會發現的缺陷。

一、集成測試的概念

（一）集成測試的定義

集成測試是構造軟件體系結構的系統化技術，同時也是進行一些旨在發現與接口相關的錯誤的測試。其目標是利用已通過單元測試的構件建立設計中描述的程序結構。

（二）集成測試遵循的原則

集成測試遵循的原則主要包括：所有公共接口都要被測試到；關鍵模塊必須進行充分的測試；集成測試應當按一定的層次進行；集成測試的策略選擇應當綜合考慮質量、成本和進度之間的關系；集成測試應當盡早開始，并已總體設計為基礎；在模塊與接口的劃分上，測試人員應當和開發人員進行充分的溝通；當接口發生修改時，涉及的相關接口必須進行再測試；測試執行結果應當如實的記錄；集成測試應根據集成測試計劃和方案進行，不能隨意測試；項目管理者應保證審核測試用例。

（三）集成測試的任務

集成測試的主要任務包括：將各模塊連接起來，檢查模塊相互調用時，數據經過接口是否丟失；將各個子功能組合起來，檢查能否達到預期要求的各項功能；一個模塊的功能是否會對另一個模塊的功能產生不利的影響；全局數據結構是否有問題，會不會被異常修改；單個模塊的誤差積累起來，是否被放大，從而達到不可接受的程度。

（四）集成測試的文檔

軟件集成的總體計劃和特定的測試描述應該在測試規約中文檔化。這個文檔包含測試計劃和測試規程，它是軟件過程的工作產品，也是軟件配置的一部分。

下列準則和相應的測試可應用于所有的測試階段：接口一致性。當每個模塊（或簇）引入程序結構中時，要對其內部和外部接口進行測試；功能有效性。執行的測試旨在發現功能錯誤；信息內容。執行的測試旨在發現與局部或全局數據結構相關的錯誤；性能。執行的測試旨在驗證軟件設計期間建立的性能邊界。

測試計劃主要包括：集成測試的進度，確定每個階段的開始和結束時間；附加軟件（樁模塊及驅動模塊）的簡要描述側重于專門進行的工作的特征；描述測試環境和資源；特殊的硬件配置、特殊的仿真器和專門的測試工具或技術也是需要討論的問題；詳細測試規程。

測試規約：集成策略（包含在測試計劃中）和測試細節（在測試規程中描述）是最基本的成分，因此必須要有。

二、集成測試的策略

驅動模塊（Driver）：用來模擬待測模塊的上級模塊。驅動模塊在集成測試中接受測試數據，將相關的數據傳送給待測模塊，啟動待測模塊，并打印出相應的結果。樁模塊（Stub）：也稱為存根程序，用以模擬待測模塊工作過程中所調用的模塊。樁模塊由待測模塊調用，它們一般只進行很少的數據處理，例如打印入口和返回，以便于檢驗待測模塊與下級模塊的接口。

一般可分為非增量集成和增量式集成，其中增量集成指的是程序以小增量的方式逐步進行構造和測試，這樣錯誤易于分離和糾正，更易于對接口進行徹底測試，而且可以運用系統化的測試方法，傳統的將增量測試策略分為自頂向下集成、自底向上集成以及三明治集成。

三、集成測試的主要類型（階段）

（一）基于功能分解的集成

在討論集成測試時，測試方法都基于采用樹或文字形式來表示的功能分解。這類討論不可避免地要深入到將要集成的模塊的順序。

1.自頂向下集成（從樹頂開始向下）。深度優先集成是首先集成結構中主控路徑下的所有模塊。

2.自底向上集成（從樹底開始向上）。自底向上集成是自頂向下順序的“鏡像”，不同的是，樁由模擬功能分解樹上一層單元的驅動模塊替代。在自底向上集成中，首先從分解樹的葉子開始，并用特別編寫的驅動模塊進行測試。驅動模塊中的一次性代碼比樁中的少。大多數系統在接近葉子節點時都有相當高的扇出數，因此在自底向上集成順序中，不需要同樣數量的驅動模塊，不過代價是驅動模塊都比較復雜。

3.三明治集成（前兩種方法的某種組合）。三明治集成測試是將自頂向下測試與自底向上測試兩種模式有機結合起來，采用并行的自頂向下、自底向上集成方式，形成的方法。三明治集成測試更重要的是采取持續集成的策略。樁和驅動的開發工作都比較小，不過代價是作為大爆炸集成的后果，在一定程度上增加了定位缺陷的難度。

（二）基于功能分解方法的優缺點

1.自頂向下集成，其優點：在于它可以自然地做到逐步求精，一開始就能讓測試者看到系統的框架。缺點：需要提供樁模塊，樁模塊是對被調用子模塊的模擬，可能不能反映真實情況，因此測試有可能不充分。

由于被調用模擬子模塊不能模擬數據，如果模塊間的數據流不能構成有向無環圖，一些模塊的測試數據便難以生成。同時，觀察和解釋測試輸出往往也是困難的。

2.自底向上集成，其優點：由于驅動模塊模擬了所有調用參數，即便數據流并未構成有向無環圖，生成測試數據也沒有困難。如果關鍵的模塊是在結構圖的底部，那么自底向上測試是有優越性的。缺點：直到最后一個模塊被加入進去之后才能看到整個程序(系統)的框架。

3.三明治集成測試采用自頂向下、自底向上集成相結合的方式，并采取持續集成的策略，有助于盡早發現缺陷，也有利于提高工作效率。

4.功能分解缺點。為了滿足項目管理的需要，而不是為了滿足軟件開發人員的需要。樁或驅動的開發工作量，此外還有重新測試所需工作量的問題。對于自頂向下集成，需要開發（節點-1個）樁模塊；對于自底向上集成，需要開發（節點-葉子）個驅動模塊。

（三）基于調用圖的集成

基于調用圖的集成一般分為成對集成和相鄰集成。基于調用圖方法的優點：偏離了純結構基礎，轉向行為基礎，因此底層假設是一種改進；這些技術還免除了樁／驅動器開發工作量；與以構建和合成為特征的開發匹配得很好。缺點：缺陷隔離問題，尤其是對有大量鄰居的情況；清除缺陷后，意味著以前測試過的包含已變更代碼的鄰居，都需要重新進行測試。

（四）基于路徑的集成

將集成測試的側重點由測試單獨開發并通過測試的單元之間的接口，轉移到這些單元的交互上，即它們的“協同功能”上。接口是結構性的，而交互是功能性的。

MM-路徑是功能性測試和結構性測試的一種混合，其優點：它與實際系統行為結合緊密，而不依賴于基于分解和調用圖集成的結構性推動。基于路徑集成測試也適用于面向對象的軟件測試。缺點：需要更多的工作量標識MM-路徑。這種工作量可能會與樁和驅動的開發所需工作量有偏差。

（五）面向對象環境中的集成測試

兩種不同的策略：

1.基于線程的測試(thread-based testing）。

2.基于使用的測試（use-based testing）。

驅動程序和樁程序：驅動程序可用于測試低層中的操作和整組類的測試。驅動程序也可用于代替用戶界面以便在界面實現之前就可以進行系統功能的測試。樁程序可用于在需要類間的協作但其中的一個或多個協作類仍未完全實現的情況下。

四、結語

集成測試既是一種測試類型也是一個測試階段，因為集成定義為一組交互，因此組件之間的所有已定義的交互都需要測試，體系結構和設計可以提供系統內部的交互細節，但是測試一個系統與另一個系統之間的交互要求對這些系統一起工作的方式有深刻理解，此時的集成測試是一個階段。由于集成測試的目標是模塊之間的交互，這種測試就像白盒、黑盒及其它類型的測試一樣，也有一套技術和方法，因此集成測試也被看作是一種測試類型。

參考文獻：

[1]周燕,宋敬華.面向對象的集成測試順序的研究[J].計算機測量與控制,2010,9

[2]張云崗,劉春茂.軟件測試技術淺析[J].技術與市場,2011,2

[3]朱家云.淺析軟件測試[J].信息系統工程,2011,4

[4王麗達.論軟件系統的測試[J].經濟研究導刊,2011,14

[5]劉欣.軟件測試方法分析與實踐[D].北京郵電大學,2009

[6]趙,孫寧.軟件測試技術：基于案例的測試[M].北京:機械工業出版社,2011

軟件測試范文第4篇

1.1軟件測試的含義

軟件測試根據用戶的使用目的,將成功開發的軟件進行相應的糾錯動作,從而披露該軟件的各種問題及缺失因素,促進研發人員進行相應的改進,從而達到完善軟件的目的。

1.2軟件測試的關鍵性階段

主要有以下兩個關鍵性的檢測階段。第一階段是軟件開發過程中各主要單元模塊完成后進行測試。這一階段測試可以將缺陷控制在最小單元模塊內,給研發人員最快的測試反饋,促使其完善單元模塊的功能,達到用戶的使用要求;第二階段測試是軟件系統全部完成后,進行全方位的綜合測試,查找系統在使用過程中可能存在的問題。此時,需要根據系統要實現的功能進行多種測試工具的應用,以其找到系統不符合要求的功能或性能瑕疵。

1.3軟件工程中軟件測試的方法

對軟件工程進行軟件測試時,不同軟件可以運用不同的測試方法。現階段,主要以軟件測試在測試過程中是否需要將程序進行完全運行來判斷測試方法,不需要系統程序運行就能完成測試的方法稱為靜態方法;需要系統時時傳送相應數據,并通過相應程序檢測系統是否達到用戶的期望值,是否存在運行邏輯上的問題和算法上的缺陷等的測試方法稱為動態方法。目前,靜態測試方法應用較廣的有靜態排演法、軟件檢查法和軟件審查法。隨著軟件測試方法的不斷創新和完善,新興的測試方法如靜態自動分析、分析模型等方法不斷得到應用;動態測試方法隨著精細化測試進程的深入逐漸細分為單元測試方法、集成測試方法、系統測試方法。這些測試方法相較于靜態測試方法,具有范圍廣、測試成功率高、內容覆蓋面大、應用程度高等特點。如白盒測試、代碼覆蓋測試等。

2軟件測試在軟件工程中的作用分析

2.1軟件工程項目需要軟件測試進行全方位的輔助管理

所謂軟件工程項目就是將用戶的要求進行立項管理,通過建立項目組、研究用戶的使用目標來確立項目目標,對目標現狀進行系統研究與分析、總體目標細分階段性目標以及規劃項目總體方案等,將軟件開發過程建立在項目管理過程中。在這一過程中,各階段性成果都需要軟件測試來校驗其可行性,從而輔助軟件工程項目步入更完善的項目管理中。首先,軟件工程項目需要精細化項目管理和集中項目管理兩者協調統一。因此,需要設立軟件測試機構,能夠對項目細分的各階段、各模塊進行軟件測試。其次,項目組人員組成和責任落實要依照規章制度實施。要體現軟件測試的重要性和實際意義,測試機構負責人為項目組組長的最佳人選。其組員為各項目負責人和其他測試人員組成。軟件測試結果必須立即反饋到軟件研發人員、程序員及系統分析人員等相關人員手中,以期促進其團結協作,將軟件各部分呈現出的問題解決。最終滿足用戶的使用要求,實現軟件設計的目標。可見,軟件測試的輔助作用,對于軟件工程項目的精細化管理、軟件相關技術的綜合管理等至關重要。

2.2軟件工程項目實施反促軟件測試發展

研發一個新的軟件系統時,其核心內容包括目標確定、框架設計、分支設計和編碼應用等,這些核心內容均需要軟件測試來實現其統一性和兼容性。系統目標是軟件測試的最終目的,軟件測試需要圍繞系統目標進行缺陷的發現和反饋,從而實現各階段測試的統一性和完整性,從而促進系統的協調和完善。經過軟件測試的系統,必須保證達到項目目標,且在長時間運行下無重大bug。從這一過程來看,軟件測試是在軟件工程項目實施中得以發展的。軟件測試機構并不是真正意義上的獨立,其“獨立”僅是功能上的獨立。實際上,在進行軟件工程項目實施的整個過程中,無論是整體設計還是精細化管理,都需要軟件測試參與其中,以測試角度對軟件工程項目的設計和實施進行指導和輔助,從而糾正一些設計上的錯誤和細節上的缺陷。這種參與的直接性促進軟件測試必須緊跟項目研發現狀,才能提出及時有效的參考意見,促進項目順利開發。軟件編碼規范是軟件研發團隊必須規范執行的,而這種規范的編碼剛是軟件測試機構的首要任務,制定規范要嚴肅,執行規范要嚴格,才能給用戶呈現出高質量的軟件產品。

2.3軟件測試原則

軟件測試的原則是在其測試的基本目的和要求下產生的,因此,在進行軟件測試時,必須注意其原則性。(1)堅持用戶使用目的,堅持項目總體目標和階段性目標的實現原則;(2)測試“精細化”即細分分支、單元模塊、階段性成果、系統全面測試等隨時進行;(3)測試時間要越早越好,頻率越高越好;(4)測試中邏輯性檢測和算法檢測要注重;(5)測試要結合數據檢測進行;(6)保證測試的嚴肅性;(7)測試堅持第三方進行原則;(8)不合理條件值都要進行測試;(9)測試過程、方法、用便、結果、完善等都要記錄在案,便于故障定位和日常維護。

3自動化軟件測試技術分析

隨著智能化技術和自動化技術的不斷深入應用,在軟件測試中,自動化軟件測試技術得到創新和發展,并在軟件開發中應用得越來越廣泛。所以,人們將各種自動測試的效果進行評估,將成功案例進行相似引用,來判斷檢測的可行性。最初的自動化測試具有較嚴格的針對性,運用特定的測試原則和測試方法,將統計指標運用其中,從而得到測試結果,并對其進行全面評估,從而得出自動化測試的嚴密性。隨著自動化測試的不斷深入推進和創新,其測試準則和自動測試技術越來越成熟,逐漸過渡到自動測試模型化階段。逐漸形成自動測試的等級制度,使得自動軟件測試技術成為測試控制能力高低優劣的一個重要判斷依據。

4結語

軟件測試范文第5篇

軟件工程目前一直缺少一個明確的定義，但是目前業內專家都一致認為軟件工程一般分為需求分析、設計、編碼及測試4個環節。其中前面3個環節是整個軟件的編寫，而最后1個環節的軟件測試，則是通過各種專業測試方法來測試軟件是否滿足軟件工程下的10種特性：可修改性、有效性、可靠性、可理解性、可維護性、可重用性、可適應性、可移植性、可追蹤性和可互操作性。

2當前軟件測試的現狀

從對軟件工程的分析來看，軟件測試是保證軟件最終健壯性的最后一個工序。但是，當前很多軟件設計公司，在軟件測試方面投入的人力物力都非常低，甚至沒有專門的軟件測試部門，而是由一些軟件設計人員兼職。雖然這樣也有了所謂的軟件測試這道工序，顯然因為軟件設計人員本身的先入為主，所以在軟件測試的過程中，往往不容易發現潛在的問題。另外有的軟件測試人員僅僅把軟件推到市場上，部分使用人員來進行測試，雖然這也是一種測試方法，但是這種由用戶測試的軟件測試環節，更多的是在軟件的操作體驗的測試，并不能夠發現軟件潛在的bug，正確的軟件測試流程，應該設計專業的測試軟件，通過白盒測試的方法來針對軟件代碼進行測試。而上述的僅僅測試界面和操作，那只是軟件測試中的黑盒測試法，只有綜合白盒和黑盒，才可能獲得更好的軟件測試效果。但是，目前能夠綜合這2種測試方法的專業軟件測試部門，還是非常稀缺的。這自然導致了國內整個軟件行業的軟件健壯性存在缺陷的主要原因之一。

3軟件測試重要性分析

3.1軟件危機下凸顯軟件測試的重要性

軟件危機一直是IT行業的最重要的話題，其實在軟件危機這個名詞出來之前，軟件工程就已經初步有了核心流程，不過正是因為很多專家有著自己的理論，所以讓軟件工程這門技術的解釋出現了很多不同的版本，不過在眾多版本中，軟件測試始終占據一個重要的模塊。軟件危機常見的表現就是因為軟件在開發的過程中，成本失控、時間跳水、穩定性和兼容性欠缺等諸多問題，而不得不一而再再而三的重新開發，特別是軟件在設計的過程中，對于可維護性、可修復性不重視，導致維護的成本占據了整個軟件生存周期的90%以上，這很明顯是不正常的。通常而言，軟件維護的成本應該是軟件生存周期的70%以下，超過70%，這個軟件最終的結局一定會失敗。軟件測試的過程，除了針對軟件的運行是否穩定，同樣也會對軟件的可維護性進行有效的判斷，盡可能的避免軟件危機的產生，所以從軟件危機的角度上來看，軟件測試在軟件工程中的地位無疑是非常重要的。

3.2軟件測試的必要性

（1）是交流的問題，容易導致軟件接口處的錯誤。現代軟件設計已經不是單人作戰的模式，已經上升到團隊甚至全球軟件工程師通過互聯網這個大平臺進行合作，這種方式顯然對軟件工程規范要求更高。其中交流往往就成了一個很重要的問題，很多軟件工程師在設計的過程中，盡可能的將自己負責的模塊做到完美，甚至也能夠考慮到模塊間的借口問題。但是因為交流上的不便，或者忽視交流，往往會產生2個模塊接口不兼容，甚至還會發生軟件需要重新改寫的問題。

（2）軟件結構有越來越復雜的趨勢。雖然軟件開始實施模塊化設計方式，將一個軟件整體拆解成無數個小的系統模塊進行設計，然后將設計好的模塊進行統一封裝。這種化整為零的軟件設計方式的確有效的改善了軟件復雜性的問題，但是同樣也面臨著模塊間的兼容問題，不同設計師的設計風格可能會導致軟件可維護性降低及可移植性降低，特別是一些軟件開發公司，根本就沒有軟件工程的概念，其研發的軟件產品，更是漏洞百出，自然很難保證軟件產品的健壯性。

（3）程序代碼的設計問題。目前一個軟件的誕生，往往會有好幾千萬行的代碼，而且在軟件正式代碼編寫之前，還需要撰寫概要設計代碼和詳細設計代碼，這些往往都給錯誤埋下伏筆。如果程序設計代碼撰寫不規范，沒有相應的注釋，沒有相應的模塊設計，往往計算式發現了軟件的錯誤，最終維護起來，也很難讓維護工程師定位，甚至連測試工程師也很難找到錯誤的地方。

（4）設計文檔的組成非常少。一個軟件產品的誕生，除了優秀的代碼設計之外，還要一份完善的代碼文檔，包括軟件的可行性研究、需求分析、詳細設計、代碼編寫，以及軟件測試等工作流程中所需要的一切的代碼文檔。如果代碼文檔貧乏，甚至沒有，那么一旦在軟件測試環節，或者在軟件使用環節，出現錯誤時，那就很難進行維護調試了。這時候的維護成本往往會比重新編寫一款軟件的成本還要低，可見設計文檔的錯誤撰寫給軟件健壯性的影響。

（5）一些軟件測試工具和開發工具本身的問題，往往導致軟件出現嚴重的bug。而且在設計階段，還很難發現，因為是本身軟件測試工具和軟件開發工具引起的，因為軟件測試工具和開發工具實際上也是一種軟件，如果這些軟件的健壯性有問題，自然也會導致測試結果出現偏差，最終影響到軟件的健壯性。

3.3軟件測試成本過半證明了軟件測試的重要性

軟件工程雖然在很多專家和權威機構的定義有所偏差，但是無一例外，對于軟件成本構成的分析上，軟件測試的成本一直占據了主要部分，最低的認為，軟件測試成本要占據30%，最高的則認為占據到50%。如果將后期維護成本也放在軟件測試板塊中，那么這個測試成本就會變得更高。因為軟件進入維護期時，一旦出現軟件需要進行調試，那么修復后的軟件依然要進行軟件測試，否則很難保證調試后軟件依然能夠保證健壯性。作為一個軟件系統的所有代碼，都是牽一發而動全身，修改了某處代碼，可能會影響到另外一個模塊的功能，所以在維護期內，對軟件的任何變動，都需要進行軟件測試，才能夠保證軟件接下來的健壯性。但很明顯，如果將軟件測試工作放在軟件推出市場之前，就來進行有效的測試，那么對于軟件整個生命周期的成本，將能夠得到有效的降低。軟件測試的成本的高低，往往和軟件的質量成正比，而軟件質量提升了，后期的維護成本就能夠有效的降低，所以綜合起來，軟件測試這部分的成本支出是非常有必要的。

4軟件測試流程分析

（1）建立獨立的軟件測試部門，測試部門領導應該對這個專業非常精通，而不是簡單的由開發人員兼職，這個測試部門需要從可行性研究開始就應該著手對軟件研發進行測試，可行性研究的最終確認應該也有軟件測試主管部門的簽字確認才能夠進行下一步的工作。

（2）軟件測試工作不是等到軟件全部開發完畢才來進行測試，而是跟隨軟件設計的整改生命周期，針對每一個環節進行測試，軟件測試部門應該擁有獨立的物理部門和獨立于開放環境的測試環境，這樣才能夠提供更加完善的軟件測試，盡可能的將軟件bug扼殺在搖籃里。

（3）軟件模塊測試，因為現在軟件設計都已經進入模塊化設計標準，比如一個完整的軟件是S，它有A、B、C、D等模塊構成，那么對于A模塊的軟件設計過程中，就應該有獨立的軟件測試人員進行跟蹤，直到A模塊被測試證明沒有隱患。以此類推，分別對B、C、D等模塊分別進行測試，合格以后，組裝后的軟件依然進行測試，這樣才能夠最終提升軟件健壯性。在軟件設計的過程中，其實測試人員是和軟件開發人員并行工作的，而不是等到軟件設計完畢之后，再來對模塊進行測試，這種方法才能夠提升軟件測試的效果。

5結語