時間：2022-02-01 02:32:47
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇軟件測試，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
關鍵詞：軟件測試；軟件開發；質量
1.組件測試
組件測試又稱單元測試，其目的就是驗證應用程序能夠很好的工作，以及盡早的發現錯誤。所謂組件測試其實就是測試單個組件的過程，是一種細粒度的測試。組件測試其實就是一個缺陷測試的過程，基本上使用結構化測試即白盒測試來對組件進行測試。在軟件中，組件算是最小的單元，因此，組件測試可以對多個組件來進行。
1.1組件測試的類型
在組件測試階段，需要測試不同類型的組件（對象內的單個函數或方法、有多個屬性和方法的對象類、有不同對象或是函數組成的復合組件）。組件測試的內容主要有模塊接口、局部數據結構測試、路徑測試、錯誤處理測試以及邊界測試。從測試的類型可以看出，比較簡單的就是對單個函數或方法的測試，但是當測試多個組件組成的復合組件時，測試組件間的接口是否能正確執行是首要關心的問題，而這個測試中的關鍵就是對組合組件的接口測試。
1.2接口測試
接口測試是組件測試中最常用的一種測試。測試符合組件間的接口就是接口測試。由于在符合組件之間存在很多交互行為，因此，在對復合組件中的單個組件進行訪問時，是要通過接口來對它們進行調用。所以，接口測試就成為組件測試中的重點。
復雜系統中最常見的錯誤形式包括接口錯誤，接口錯誤主要指接口誤用、計時錯誤、接口誤解等等。一般情況在不尋常的條件下、交互雙方都存在接口缺陷，而這是很難發現的，因此，接口測試是非常重要的。
組件的開發和測試都是交叉進行的，組件的設計者對組件是十分熟悉的，因此，由組件的設計者來進行組件測試是在合適不過了。
2.集成測試
所謂集成測試就是指測試時將組件集成為系統來進行。集成測試的目的就是檢查在一起的組件是否工作，能否正確及時進行組件與組件間的交互。集成測試就是將與接口相關的錯誤找出，從而使得添加的功能模塊確保沒有傳播不期望的副作用，并且使得由于新模塊的添加引起的變更不引入需求外的行為或是增加額外的錯誤。集成測試過程如圖1所示。
圖1 集成測試過程
2.1集成系統的策略
集成順序不同，集成測試也將不同，二者密切相關。集成系統的策略從理論上來講，其可分為自上而下的集成和自底而上的集成。但是在實際中，大多數的集成策略都是混合型的。自上而下的集成就是指先把系統框架開發出來，然后再向其中添加組件。這種方法存在一個非常普遍的問題，即在測試下一層時，還要兼測上一層。自底而上的集成就是指集成和測試都是從組件開始。不管使用哪種策略，開發額外的代碼是必須的，通過額外代碼的開發來仿真其他組件，從而使得系統運行起來。
對錯誤的定位就是集成測試中存在的主要問題。由于組件之間有復雜的交互行為存在，因此，當發現一個錯誤時，很難將其出錯的位置找到。
2.2集成測試的方法
集成測試通常采用增量法來進行測試，從而使得集成測試中的主要問題得以解決。使用增量法，從一個集成度最小的系統配置開始，然后測試這個系統，測試完成后，一個增量一個增量地往系統中增加組件，每次增加組件后再進行測試。這種方法其優點在于易于分離和糾正錯誤以及徹底測試接口。這種方法的缺點在于在測試過程中經常會出現重復測試。
2.3回歸測試
回歸測試就是指把測試過的再進行測試。回歸測試雖然出現重復測試，但是其能夠保證新增模塊后不會給原系統組件間的行為產生不期望的變更。回歸測試是保證軟件的正確運行的必要條件，但是，對測試過的再進行重新測試明顯會產生不必要的浪費。
要想在使用回歸測試時減少系統資源的浪費，可以從以下幾個方面進行：（1）引進自動化測試。這種方法的引入，使得測試自動地重復，從而回歸測試對系統資源的浪費得以減少；（2）嚴格規定增加快增加順序。先增加最常用的功能塊，從而對最常用的組件進行多次測試，確保在各種情況下常用功能能夠實現。
集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，集成測試的意義還在于它能間接地驗證概要設計是否具有可行性。
3.性能測試
性能測試就是測試系統對在非正常條件下的運行情況。它的任務是驗證軟件的功能和性能及其他特性是否達到了需求規格書上的要求。一般情況下包括恢復測試、安全測試、壓力測試、性能測試。恢復測試是通過各種方式強制地讓系統發現故障并驗證其能夠重新恢復的一種系統測試。安全測試是驗證在系統內的保護機制是否能夠實際保護系統不受非法入侵。壓力測試是以一種要求反常數量、頻率或容量的方式執行系統的測試方法。
4.接收測試
接收測試是對將要分給客戶的系統版本的測試過程。通常是一個黑盒測試過程，將軟件與計算機的其他系統元素結合在一起，在實際運行環境下，由用戶通過真實的數據測試對軟件在內的計算機系統，以求能發現系統需求定義中的錯誤和遺漏。同時也期望能發現因系統的設施不能滿足用戶的需求或系統的性能無法接受的錯誤。
4.1接收測試的方法
接收測試的最好測試方法是基于腳本的測試，先設計出多個腳本然后再從腳本中開發錯測試用例。
4.2接收測試的分類
接收測試根據用戶的不同可以分為α測試和β測試。無論是α測試還是β測試都是在實際的使用環境下進行的。α測試是測試為特定的用戶開發的系統，且由最終用戶在開發者在場的情況下進行的，開發者在旁邊記錄用戶所遇到的錯誤和使用問題，α測試要持續進行直到開發者和用戶雙方都對最后交付的系統滿意。β測試的對象是一個將要在市場上銷售的軟件產品，β測試是所有愿意使用該軟件的用戶在使用該軟件是所遇到的所有問題，然后在反饋給開發者，開發者再根據反饋回來的信息決定對軟件做如何處理。通常情況下β測試能暴露開發者無法預見得錯誤。
隨著軟件應用越來越廣，所要求的設計也越來越復雜，所需的開發周期越來越短，而質量要求越來越高，那么軟件企業目前面臨著巨大的挑戰。由此，軟件測試變得越來越重要，軟件測試可以有效地提高軟件質量。重視軟件測試過程和技術是軟件企業快速發展的有效途徑。
參考文獻：
關鍵詞：Web；軟件游覽；體系結構；方法
0 引言
隨著Intemet的普及和電子商務應用的深入。Web應用程序得到越來越廣泛的應用，B／$架構也逐漸代替C／S架構成為主流的應用模式。與傳統軟件相比，Web應用程序具有分布式、并發、多用戶異構等特點，這些特點對軟件測試提出了新的要求。Web測試是保證Web應用程序質量的有效手段，目前在Web測試的方法和技術以及相關工具等方面的研究已進行了一些嘗試。軟件測試的自動化技術有助于開發出更高質量的產品，并且可以節省開發時間和開支。
1 Web軟件體系結構
Web應用程序采用B／S結構，它是伴隨著Intemet技術的不斷進步，由C／S結構改進和發展起來的新型體系結構。B／S結構利用不斷成熟和普及的瀏覽器技術實現原來需要復雜專用軟件才能實現的強大功能。是一種全新的軟件系統構造技術。這種結構已成為當今應用軟件開發的首選體系結構。
Web系統的基本工作過程是：在客戶端，用戶通過瀏覽器向Web服務器中的控制模塊和應用程序輸入查詢要求，Web服務器將用戶的數據請求提交給數據庫服務器中的數據庫管理系統DBMS；在服務器端，數據庫服務器將查詢的結果返回給Web服務器，再以網頁的形式發回給客戶端。在此過程中，對數據庫的訪問要通過Web服務器來執行。Web系統的基本體系結構及工作過程如圖1所示。
從上面的體系結構可以看出，Web測試應該分為三個層次，客戶端測試、服務器端測試和數據庫測試。客戶端主要測試用戶瀏覽器的基本功能和頁面現實情況；服務器端主要測試用戶請求響應情況；數據庫端主要測試數據一致性和輸出錯誤。
2 Web軟件測試的主要特點與難點
Web軟件由于其分布式應用、具有各種運行時行為、涉及多種標準協議，可能在硬件、軟件、通信、對象管理等環節出現各種缺陷。其體系結構和應用的復雜性，以及技術和規范不斷地發生變化，對測試提出了新的挑戰。Web軟件測試的特點與難點主要體現在以下幾個方面：
(1)Web軟件的開發環境與其應用環境有很大的不同，在之前，很難對其實際的運行場景進行預測，如用戶類型、并發用戶數量、Web服務調用的裝載模式和訪問方式等，這些差異和應用的不確定性都增加了Web服務測試的困難。
(2)Web軟件測試主要基于軟件接口進行設計和實現，因此必須采用自動化測試方法，與傳統的需要大量人工干預的測試方法截然不同。
(3)Web軟件由于其分布特征，會出現大量用戶通過不同的環境訪問同一個服務的情形，因此，性能和可擴展性是Web軟件測試的重要方面。
(4)Web軟件及軟件集成的、發現和綁定都是動態完成的，其過程的不確定性和不可見性增加了測試難度。
(5)Web軟件訪問接口和訪問方法后增加了Web軟件的安全隱患，提高了被系統攻擊的機會。此外，對于所調用的分散、異構的外部Web服務的安全性的管理也非常困難。如何提高Web軟件的安全性也是測試者要考慮的重要問題。
(6)Web軟件的應用通常涉及到軟件提供者、者和使用者三種角色，都需要參與到測試的不同階段，其分布式合作的特征使得測試的組織、缺陷管理、結果評估等活動都更加困難。
目前。針對Web軟件的測試方法和技術的研究還處于初始階段，代表性的研究主要有基于形式化方法對協議及規格說明的驗證(如WSFL驗證技術、SOAP驗證)和Web服務的集成測試。
3 傳統軟件測試與Web軟件測試
傳統軟件測試經常是靜態、離線的測試，盡管這些傳統的測試技術也可以應用到Web服務的測試當中，然而相當有意義的一部分Web軟件測試都必須是動態的和在運行時間內的即時測試。Web軟件這種動態和即時測試對傳統的測試理論提出了新的挑戰和要求。表1比較了傳統軟件和Web軟件測試的差別。
4 Web軟件測試的內容和方法
Web測試主要目標是確保提交高質量的Web軟件。對于錯綜復雜的Web軟件，從什么地方開始測試。哪些方面是測試的核心，有限的測試資源如何分配，這些都是Web軟件測試需要重點考慮的問題。下面介紹Web軟件測試的主要內容和方法。
4.1 功能測試
鏈接測試 鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面：①測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面。②測試所鏈接的頁面是否存在。③測試Web應用系統上有無孤立的頁面。所謂孤立頁面是指沒有鏈接指向的頁面，只有知道正確的URL地址才能訪問。
表單測試 單元當用戶給Web應用系統管理員提交信息時，就需要使用表單操作。例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。
Cookies潮試Cookies通常用來存儲用戶信息和用戶在某應用系統的操作。當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登錄等信息。如果Web應用系統使用了Cookies。就必須檢查Cookies是否能正常工作而且對存儲的信息已經加密。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。
設計語言測試 Web設計語言版本的差異，例如使用不同版本的HTML等，可以引起客戶端或服務器端嚴重的問題。在分布式開發環境中，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaSeript、ActiveX、VBScript或Perl等也要進行驗證。
數據庫測試 數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的。針對這兩種情況，可分別進行測試。
4.2 性能測試
網站的性能測試對于網站的運行而言異常重要，但是目前對于網站的性能測試做得不夠，我們在進行系統設計時也沒有一個很好的基準可以參考，因而建立一整套網站的性能測試方案將是至關重要的。
連接速度測試 用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。連接速度太慢。還可能引起數據丟失，使用戶得不到真實的頁面。
負載測試 負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線；如果超過了這個數量，會出現什么現象。
壓力測試 壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
4.3接口測試
服務器接口 第一個需要測試的接口是瀏覽器與服務器的接口。測試方式一般是，測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。
外部接口有些Web系統有外部接口，例如，網上商店可能要實時驗證信用卡數據以減少欺詐行為的發生，測試的時候，要使用Web接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。
錯誤處理 最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。為此，可以嘗試在處理過程中中斷事務，看看會發生什么情況，訂單是否完成，嘗試中斷用戶到服務器的網絡連接，系統能否正確處理這些錯誤。
4.4 兼容性測試
平臺測試市場上有很多不同類型的操作系統，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下運行可能會失敗。因此，在Web系統之前，需要在各種操作系統下對其進行兼容性測試。
瀏覽器測試 瀏覽器是Web客戶端最核心的構件。來自不同廠商的瀏覽器對JavadavaScript、ActiveX或不同的HTlML規格有不同的支持，例如，ActiveX是Microsoft的產品，是為Intemet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣，在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
4.5 安全測試
景登 現在的Web應用系統基本采用先注冊，后登錄的方式，因此，必須測試有效和無效的用戶名和密碼。要注意到系統是否對大小寫敏感，可以試行登錄多少次，是否可以不登錄而直接瀏覽某個頁面等。
日志文件為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。
安全漏洞 服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
關鍵詞：軟件測試；系統測試；線索；壓力測試；性能測試
中圖分類號：TP39文獻標識碼：A文章編號：1007-9599 (2012) 05-0000-02
一、引言
軟件測試作為軟件質量保證的關鍵技術之一，其目的就是能夠有效地發現軟件中的錯誤或缺陷。系統測試是對完整集成后的系統進行測試的階段，用來評價系統對具體需求規格說明的符合性，系統測試是在單元、組件和集成測試階段之后進行的。主要針對軟件系統和其他系統元素（及硬件、數據庫和人機交互信息）組合構成完整的計算機應用系統中所有的元素配合是否合適以及整個系統的功能、性能、執行強度、安全性等是否達到規定標準而進行的測試。
二、系統測試概述
（一）系統測試概念
所謂系統測試是將通過集成測試的軟件系統，作為計算機系統的一個重要組成部分，與計算機硬件、外設、某些支撐軟件的系統等其他系統元素組合在一起所進行的測試，目的在于通過與系統的需求定義作比較，發現軟件與系統定義不符合或矛盾的地方。
（二）系統測試前的準備工作
系統測試前的準備工作主要包括：對系統各種功能的描述；系統要求的數據處理及傳輸的速率；對系統性能的要求；對備份及修復的要求；對兼容性的描述；對配置的描述；對安全方面的要求等。
（三）系統測試的測試數據
系統測試所用的數據必須盡可能地像真實數據一樣精確和有代表性。可以使用真實數據或者使用真實數據的一個復制，復制數據的質量、精度和數據量必須盡可能地代表真實的數據。
（四）系統測試與確認測試區別
確認測試始于集成測試的結束，那時已測試完單個構件，軟件已組裝成完整的軟件包，且接口錯誤已被發現和改正。在確認測試時，傳統軟件與面向對象軟件的差別已經消失，測試便集中于用戶可見的動作和用戶可識別的系統輸出。
1.確認測試準則
軟件確認是通過一系列表明已符合軟件需求的測試而獲得的。測試計劃和規程都是用于確保滿足所有的功能需求，具有所有的行為特征，達到所有的性能需求，文檔是正確的、可用的。執行每個確認測試用例之后，存在下面兩種可能條件之一：（1）功能或性能特征符合需求規約，因而被接受；（2）發現了與規約的偏差，創建缺陷列表。
2.配置評審
評審的目的是保證所有的軟件配置元素已正確開發、編目，且具有支持軟件生命周期的支持階段的必要細節。
3.α測試與β測試
α測試是由最終用戶在開發者的場所進行。軟件在自然的環境下使用，開發者站在典型用戶的后面觀看，并記錄錯誤和使用問題。α測試在受控的環境下進行。
β測試是最終用戶場所執行。開發者通常不在場，因此，β測試是在不為開發者控制的環境下軟件的現場應用。最終用戶記錄測試過程中遇見的所有問題(現實存在或想象的)，并將其定期地報告給開發者。接到β測試的問題報告之后，軟件工程師進行修改，然后準備向最終用戶軟件產品。
二、系統級功能測試技術
（一）線索的概念
線索（thread）的概念很難定義。事實上，一些已經公開的定義都是矛盾、容易產生誤導或錯誤的。可以把線索看作是一種不需要形式化定義的原始概念。以下是對線索的多種看法：一般使用的場景；系統級測試用例；激勵/響應對；由系統級輸入序列產生的行為；端口輸入和輸出事件的交替序列；系統狀態機描述中的轉換序列；對象消息和方法執行的交替序列；機器指令序列；源指令序列；MM-路徑序列；原子系統功能序列。
（二）需求規約的基本構造元素
根據一組基本需求規約構造元素，即數據、行動、設備、事件和線索，來討論系統測試。每個系統都可以使用這五種元素表示。
1.數據
主要包括：變量、數據結構、字段、記錄、數據存儲和文件、實體關系模型高層數據描述。
2.行動
以行動為中心建模仍然是需求規約的一種常見形式，這是因為有命令式程序設計語言以行動為中心性質的歷史原因。行動有輸入和輸出，這些輸入和輸出既可以是數據，也可以是端口事件。行動還可以分解為低層活動，例如數據流圖。
3.設備
每個系統都有端口設備，這些端口設備是系統級輸入和輸出（端口事件）的源和目的地。在技術上，端口是I/O設備接入系統的點。
4.事件
事件既有數據方面的一些特征，又有行動方面的一些特征。事件是發生在端口設備上的系統級輸入（或輸出）。可以是離散的，也可以是連續的（例如溫度、高度或壓力）。端口輸入事件是物理到邏輯的轉換，同樣，端口輸出事件是邏輯到物理的轉換。
5.線索
因為要測試線索，因此測試人員通常不能在數據、事件和行動之間的交互中找出線索。線索本身出現在需求規約中的惟一地方，是使用快速原型法并結合場景記錄器。
（三）線索測試的結構策略及功能策略
結構策略實際上是基于有限狀態機的行為建模中的結構來尋找測試線索的。首先自底向上組織各層次的狀態機，然后尋找線索覆蓋每個狀態機的節點和邊，同時還要找出節點與邊覆蓋指標。
線索測試的功能策略
1.基于事件的線索測試
（1）端口輸入事件覆蓋指標
五個覆蓋指標為覆蓋端口輸入事件提供了一組線索：
(1)PI1：每個端口輸入事件發生。
(2)PI2：端口輸入事件的常見序列發生。
(3)PI3：每個端口輸入事件在所有“相關”數據語境中發生。
(4)PI4：對于給定語境，所有“不合適”的輸入事件發生。
(5)Pl5：對于給定語境，所有可能的輸入事件發生。
（2）端口輸出事件覆蓋指標
根據端口輸出事件定義兩種覆蓋指標：
(1)PO1：每個端口輸出事件發生。
(2)PO2：每個端口輸出事件在每種原因下發生
2.基于端口的線索測試
基于端口的測試是基于事件測試的有用補充。
對于每個端口都要詢問端口上會出現什么事件。然后根據每個端口的事件列表尋找使用輸入端口和輸出端口的線索。有些需求規約技術要求提供這種端口的事件列表。
設備和事件之間的多對多測試應該在兩個方向上進行：基于事件的測試覆蓋從事件到端口的一對多關系，反之，基于端口的測試覆蓋從端口到事件的一對多關系。SATM系統不能使用這種測試，因為SATM不發生在多個端口上。
三、系統測試的主要內容
系統測試一般要完成以下幾種測試：功能測試、性能測試、可靠性、穩定性測試、兼容性測試、恢復性測試、安全性測試、強度測試、面向用戶支持方面的測試、其他限制條件的測試。下面就對常用的系統測試做一個介紹：
（一）壓力測試
壓力測試是指模擬巨大的工作負荷以查看或評估應用程序在峰值或超越最大負載使用情況下如何執行操作。壓力測試有如下特點：可以測試系統的穩定性；一般需要對用戶的使用情況進行模擬。壓力測試的方法包括：并發測試法、增加量級法、重復測試法。
（二）性能測試
性能測試一般需進行：對軟件計算的精度有要求時，設計測試用例；對軟件有時間要求時，設計測試用例；測試為完成功能所處理的數據量；測試程序運行所占用的空間；測試對系統的負載潛力；測試配置項各部分的協調性；測試軟件性能和硬件性能的集成；測試系統對并發事務和并發用戶訪問的處理能力。
（三）恢復性測試
多數基于計算機的系統必須從錯誤中恢復并在一定的時間內重新運行。恢復性測試是通過各種方式強制地讓系統發生故障并驗證其能適當恢復的一種系統測試。若恢復是自動的(由系統自身完成)，則對重新初始化、檢查點機制、數據恢復和重新啟動都要進行正確性評估。若恢復需要人工干預，則估算平均恢復時間(mean-time-to-repair，MTTR)以確定其是否在可接受的范圍之內。
（四）安全性測試
安全性測試驗證建立在系統內的保護機制是否能夠實際保護系統不受非法入侵。系統的安全必須經受住正面的攻擊，但是也必須能夠經受住側面和背后的攻擊。在安全性測試過程中，測試者扮演試圖攻擊系統的角色。測試者可以試圖通過外部手段獲取密碼；可以通過瓦解任何防守的定制軟件來攻擊系統；可以“制服”系統使其無法對別人提供服務；可以有目的地引發系統錯誤以期在其恢復過程中入侵系統；可以通過瀏覽非保密數據，從中找到進入系統的鑰匙等等。
四、結語
系統測試有助于在其部署中客戶發現缺陷之前，盡可能多滴發現缺陷，在系統測試期間要驗證完整產品的行為，包括設計多個模塊、程序和功能的測試，測試完整產品的行為是很關鍵的，因為很多人錯誤地認為經過單獨測試的組件放到一起后仍能正常運行。
參考文獻：
[1]薛沖沖,陳堅.軟件測試研究[J].計算機系統應用,2011,2
[2]陶幸輝,宋志剛.軟件系統測試類型及測試用例設計[J].科技經濟市場,2011,6
[3]朱家云.淺析軟件測試[J].信息系統工程,2011,4
[4王麗達.論軟件系統的測試[J].經濟研究導刊,2011,14
隨著信息化軍事技術的不斷發展，裝備仿真訓練軟件也獲得了迅速的發展，其規模越來越龐大、實現的功能越來越多、結構越來越復雜，裝備仿真訓練軟件的性能和可靠性也成為至關重要問題的。因此，軟件測試成為裝備仿真訓練軟件開發過程中一個必要的環節。依據一個科學的測試模型，使用先進的軟件測試技術對裝備仿真訓練軟件進行充分的測試，可以及時發現軟件程序中的錯誤，有效降低軟件錯誤出現的概率，驗證軟件功能的可行性，提高軟件的可靠性和安全性。
1 軟件測試模型
軟件測試是裝備仿真訓練軟件開發過程中一個不可缺少的重要步驟，而且隨著裝備仿真訓練軟件規模的增大、復雜度的增加，軟件測試也變得越來越重要。裝備仿真訓練軟件軟件測試過程與開發過程一樣，都能決定軟件的質量，而且測試過程的質量將直接影響測試結果的準確性和有效性。
在軟件開發幾十年的實踐過程中，人們總結了很多的開發模型，這些模型對于軟件開發過程具有很好的指導作用，由于測試與開發是緊密結合在一起的，所以軟件測試也需要有測試模型去指導實踐。軟件測試模型是將測試過程活動進行抽象的概念模型，用于定義測試活動的流程和方法，是確保軟件工程質量的重要手段。測試專家通過實踐總結出了很多很好的測試模型。這些模型將測試活動進行了抽象，明確了測試與開發之間的關系，更好的分析軟件測試在整個軟件研發中的參與度和工作過程，進而不斷完善軟件質量保證流程，提高軟件產品的質量，并成為了測試管理的重要參考依據。目前，主要的測試模型主要有以下4種：
1.1 V模型
V模型是將傳統測試模型瀑布模型改進后的一種測試模型，如圖1所示，從左到右，分別描述了軟件的基本開發過程和對應的測試行為，清楚地體現出每個測試階段和開發過程各階段的對應關系。但是在V模型當中，測試過程放在了編碼的下一個階段，這就容易使人誤解為測試是軟件開發的最后一個階段，而需求分析的檢驗工作也是在驗收測試才能進行。
1.2 W模型
W模型由兩個V模型組成，分別代表測試與開發過程，非常明確的標注了生產周期中開發與測試之間的對應關系，如圖2所示。但是在W模型中測試和開發也保持著一種線性的前后關系，上一階段工作完全結束，才能正式開始下一階段的工作，這樣就無法支持迭代、自發性以及變更性調整等情況。
1.3 H模型
H模型形成了一個完整獨立的測試過程，并且將測試準備活動和測試執行活動清晰的區別出來，如圖3所示。圖中僅僅演示了在整個生命周期中某個層次上的一次測試“微循環”，圖中的“其他流程”可以是任意開發流程。H模型的特點是軟件測試是一個獨立的流程，貫穿產品整個生命周期，與其他流程并發地進行。當某個測試點就緒時，軟件測試即從測試準備階段進入測試執行階段。
2 裝備仿真軟件測試的特點及關鍵問題
2.1 裝備仿真軟件測試的特點
裝備仿真訓練軟件是一個由系統、分系統/子系統、模塊組成的復雜系統，并隨著系統和操作功能的增多，復雜程度也在增加，系統的好壞歸根結底是由各個分系統和各個模塊的好壞決定的，對各個分系統和各個模塊的測試是一個非常重要的環節。裝備仿真訓練軟件測試具有以下6個特點：
2.1.1 裝備仿真訓練軟件測試主要分為三個階段
從軟件生命周期全過程來看，軟件測試可分為單元測試、功能測試、集成測試、性能測試、系統測試、配置測試、回歸測試等階段。根據裝備仿真訓練軟件的結構、規模、類型和安全性關鍵等級等方面的特點，確定裝備仿真訓練軟件測試主要分為單元測試、集成測試和系統測試三個階段。
2.1.2 單元測試是裝備仿真訓練軟件的測試重點
裝備仿真訓練軟件測試是一項針對性很強的工作，即使對同一類型的功能，可能由于不同型號任務的要求，功能實現也會有所差異，因此要求重點進行單元測試。單元測試是根據詳細設計和源程序，了解每個最小模塊的輸入、輸出條件和邏輯結構是否正確合理。單元測試通常應對模塊內所有控制路徑設計測試用例，以便發現錯誤。
2.1.3 裝備仿真訓練軟件程序內部結構復雜，路徑組合數目龐大
程序的三種基本結構分別是：順序結構、分支結構和循環結構，裝備仿真訓練軟件最小組成模塊的內部程序都可看作是這三種結構按不同方式組合的產物，這其中包含大量多重選擇和循環嵌套的程序，而且模塊與模塊之間存在著大量的交互，所以程序內部包含的不同路徑數目可能是天文數字，尤其對大規模復雜的裝備仿真訓練軟件，窮舉所有的路徑是不可能的，需要根據實際情況去選擇適合的覆蓋測試方法。
2.1.4 裝備仿真訓練軟件黑盒測試用例數量龐大
裝備仿真訓練軟件中包含了不同專業的多個分系統，每個分系統又由多個子系統和模塊組成，其中包含的參數數量龐大，參數與參數之間的進行組合之后的數量將更加龐大，而軟件運行出現的故障時，更多的情況是由于多個參數的相互作用的原因，所以，要想充分考慮到參數與參數之間的關系，需要的測試用例數量是無窮盡的。
2.1.5 裝備仿真訓練軟件測試一般需要特定的測試環境支持
裝備仿真訓練軟件測試可以采用靜態測試方法和動態測試方法。其中，靜態測試以人工檢查為主，不需要特定的測試環境;而動態測試則需要建立驅動軟件模塊執行的測試環境，支持軟件模塊的參數輸入和輸出結果的可視化。
2.1.6 裝備仿真訓練軟件測試一般采用白盒測試與黑盒測試相結合的方法
一般采用白盒測試方法來測試裝備仿真訓練軟件程序內部的邏輯結構;裝備仿真軟件的功能測試部分則需要采用黑盒測試方法。
2.2 裝備仿真軟件測試的關鍵問題
軟件測試的目標是發現軟件中可能存在的設計缺陷和錯誤。測試時驗證得越全面，軟件中可能存在的缺陷就會越少，而每一個項目、每一個軟件的測試都會有不同的特點和測試關鍵問題，測試工作要根據軟件的特點和關鍵問題，設計適合該軟件的測試。裝備仿真訓練軟件測試的關鍵問題主要有以下4點：
2.2.1 測試工作必須由非開發人員來完成
由于許多開發單位對軟件測試的認識水平不夠，自己設計、自己編程、自己測試、自己維護的現象還比較普遍，這樣的結果就是導致測試結果不理想，沒有達到測試的要求。所以，為了保證測試質量，裝備仿真訓練軟件的測試工作必須由非開發人員來進行，保證的效果。
2.2.2 在白盒測試中，采用基本路徑測試方法解決路徑覆蓋率問題
在裝備仿真訓練軟件結構中，路徑組合是一個龐大的數字，所以要在測試中覆蓋所有路徑是不可能的，需要把覆蓋的路徑壓縮到一定范圍內。如：程序的循環部分可以只循環一次。因此，在路徑覆蓋測試上，我們選擇基本路徑測試法。
2.2.3 在黑盒測試中，采用組合覆蓋測試方法解決測試用例無窮盡問題
由于裝備仿真訓練軟件中參數與參數的組合數量龐大，無法設計無窮盡的測試用例滿足覆蓋率問題，為此，采用組合覆蓋測試方法，不僅可以充分考慮到軟件中參數與參數之間的相互作用，更重要的是能以最少的測試用例實現最大程度的覆蓋，具有較好的測試效果。
2.2.4 要有必要的測試文檔
沒有文檔的項目是一個不成功的項目，同樣，沒有文檔的測試也不會是一個成功的測試。測試工作的計劃、設計、實現和問題報告都要以文檔的形式記錄下來留存，方便同項目組人員進行閱讀和修改，更重要的是對于后續同類項目是資源的積累過程和設計的改進依據。
3 裝備仿真軟件測試模型
測試過程模型定義了測試的流程和方法，為測試工作提供了指導。但是傳統的測試模型各有長短，不可能適合所有的測試軟件，軟件測試模型因測試軟件的不同而不同，所以，本文通過對傳統的測試過程模型進行的分析和探討，同時研究分析了裝備仿真訓練軟件的實際情況，進而得到了適合裝備仿真軟件的測試模型，然后從該模型出發，完善軟件測試工作流程。裝備仿真訓練軟件測試模型是一個包含了軟件文檔審查、代碼靜態分析和審查、單元測試、子系統集成測試、系統測試和驗收測試的綜合測試模型，如圖4所示。
3.1 測試準備
測試準備階段是在測試實施之前，構造執行測試所需的要素，這些要素通常包括軟件開發文檔、軟件開發程序、實際執行測試所需的軟件、準備測試環境和測試工具;同時還要為測試過程準備適當的測試用例。
3.2 單元測試
裝備仿真訓練軟件單元測試部分包含靜態測試和動態測試兩個部分。其中靜態測試的對象是裝備仿真訓練軟件單元模塊的文檔和程序代碼，主要通過文檔審查、代碼審查、代碼靜態分析等方法來確保軟件需求和設計文檔的正確性、代碼的規范性、設計或實現的正確性。而軟件結構和功能方面的缺陷則需要采用動態測試的方法來完成。
裝備仿真訓練軟件單元模塊動態測試采用黑盒測試和白盒測試相結合的方法，從模塊級檢查軟件的功能、性能、接口和其他約束條件是否滿足需求。白盒測試技術主要測試每個單元內部邏輯結構的覆蓋率，黑盒測試技術測試模塊單元功能滿足需求情況。
3.3 集成測試
集成測試主要檢驗裝備仿真訓練軟件中經過單元測試的模塊和子系統各部分工作是否實現了相應技術指標、達到了相應的要求。在裝備仿真訓練軟件集成測試部分，既可以彌補單元測試中沒有測試到的Bug，又可以測試單元測試中沒有辦法測試的功能，如裝備仿真訓練軟件中前后臺集成之后的關聯功能。所以集成測試就是測試各個部件之間的配合情況，為系統測試提供基本保證。
裝備仿真訓練軟件的集成測試必須在所有模塊、子系統能夠正常運轉的情況下才能進行，一般采用的方法是數據驅動方法中的自底向上集成測試。具體的步驟是先測試組成子系統的模塊群，由于最底層的單元模塊都已經經過了單元測試，所以各個模塊可以向上集成為各個子系統;然后在此基礎上就可以測試各個子系統能否正常工作，以及進行各個子系統之間的測試工作。
3.4 系統測試
裝備仿真訓練軟件的系統測試是在集成測試的基礎上進行的，不僅是單純的測試軟件部分，而是將硬件、網絡和外設等其他要素結合進來進行綜合性測試。系統測試主要依據系統總體技術方案和需求說明書進行測試，目的是發現系統與用戶需求不符或矛盾的地方。
系統測試的測試類型一般包括功能測試、性能測試、負載測試、強度測試、容量測試、安全性測試、用戶界面測試、有效性測試、配置測試、故障恢復測試、安裝測試和回歸測試。而在裝備仿真訓練軟件的系統測試中，功能測試、性能測試、負載測試、安全性測試、有效性測試、配置測試、故障恢復測試是必須進行的，其他項目可以依據具體項目情況選擇性的進行。
3.5 驗收測試
在完成裝備仿真訓練軟件的系統測試之后，進行驗收測試。只有通過了驗收測試，才標志著項目的結束，軟件產品的完成。一般來說，驗收測試以用戶為主，主要驗證軟件的功能、性能以及其他特性是否與用戶要求相一致。
4 結束語
軟件測試的目的是通過測試來發現缺陷，找出缺陷的分布特征和出現的規律，以便在新的開發項目中改進設計結構，避免缺陷的出現，同時也能夠通過設計有針對性的檢測方法，改善軟件測試的有效性。隨著裝備仿真訓練軟件質量要求的提高，軟件測試在軟件開發中的地位越來越重要。裝備仿真訓練軟件測試模型是從傳統的軟件測試模型中提取出來的，適合裝備仿真訓練軟件的測試模型，不僅可以提高測試在軟件生命周期中的作用，還可以完善軟件部分的工作流程。
作者：鐘尚斌 來源：電子技術與軟件工程 2016年7期
【關鍵詞】軟件測試 技術 管理
隨著經濟社會的不斷進步和信息技術產業的持續發展，我國的軟件業逐步成為了信息技術產業的靈魂與核心。然而與同屬于亞洲的印度相比，我國在全球軟件業的整體地位還遠遠落后，印度目前位列全世界的前五個軟件方面供應大國之一，在計算機的軟件出口方面地位僅在美國之后、位列世界第二。在促使印度的軟件業得以快速成長和發展的原因當中，注重軟件的質量是印度軟件業能夠攻取成功的一個關鍵性因素，印度的軟件企業在世界上所獲得的質量認證也是全球最多的。所以，提升軟件的質量能夠大大地推動我國的軟件業的快速發展。而軟件的測試是把好軟件的質量關口的一個重要的環節，屬于軟件的開發周期當中占據較大比重的一項內容。然而在開發時間延續中，對軟件的缺陷修復的代價會十倍速地增長。所以，加強軟件的測試工作研究，對于提升軟件產品項目的質量，推動我國軟件行業和企業持續健康發展具有十分重要的意義和作用。本文簡要介紹了軟件測試的目的和分類，深入闡述了促進軟件測試技術自動化的措施，研究提出了加強軟件測試管理的對策和建議，希望對于推進軟件測試的研究和實踐工作能夠起到一定的幫助和借鑒作用。
1 軟件測試概述
軟件測試指的是軟件產品在投放市場前，對于軟件產品所進行的需求的分析，設計的規格和編碼等內容的復審，是確保軟件產品質量的關鍵性步驟。
1.1 軟件測試的具體目的
軟件測試的具體目的決定著如何來組織進行測試工作。通常情況下軟件測試工作的目的主要有：一是為發現程序的錯誤從而進行測試，二是測試用以證明軟件的程序存在錯誤，并非證明該程序不存在錯誤；三是好測試其功能在于可以發現以前沒有發現的一些錯誤等等。因此，必須關注測試的具體目的，進行測試用例的選擇時要遵循經濟性原則。
1.2 軟件測試分類
軟件測試通常可以分為黑盒式測試與白盒式測試兩種類型。黑盒式測試就是將軟件系統當作黑盒子而不去考慮相關程序內在的邏輯，按照需求規格的說明書要求對程序功能進行檢查，看能否達到功能說明的要求。白盒式測試就是允許實施測試的人員根據程序內部的邏輯結構和相關信息進行測試用例的設計與選擇，測試程序邏輯的路徑。按照前后的過程分類，測試步驟可分成：單元測試，組裝（集成）測試，確認測試及系統測試等。
2 促進軟件測試技術自動化的措施
2.1 軟件傳統測試方法的主要問題
一是重復性較強。在功能增加及缺陷修復時均可能修改程序的代碼，對改變過的代碼進行測試就要反復地執行測試用例，用手工進行重復操作會增加出錯率；二是測試的周期過長，手工重復測試將會使軟件的測試周期延長；三是測試內容不夠全面，修改代碼之后，手工進行測試會忽略對關聯內容的相應測試；四是不能測試不可視的組件，服務器端重要的程序代碼均處于邏輯層，而采取手工進行測試的方法無法判斷邏輯層相應內容。
2.2 軟件測試自動化技術措施
一是生成測試個案，采用相應的編程語言編制短小程序用以形成測試的輸入，以使自動化的測試和結果的核對程序更易于控制與操作。二是對測試進行寫控制，對單元的測試及集成的測試會采取單機運行的方式，然而對系統的測試及回歸式測試，則可會用到多臺設備在網絡環境下運行，以節省時間。 三是對測試的結果和標準化輸出進行對比，輸出的數據量情況和數據的格式對于對比速度有著直接的影響，應當編制特殊軟件將測試的結果和標準化輸出進行對比。四是利用對比軟件，分類、分析記錄及通報不符合的測試工作結果。五是產生測試總體統計報表，以增強過程管理工作的質量，節省數據統計時間。
3 加強軟件測試管理的對策和建議
3.1 強化軟件測試的過程管理
測試需求階段中，就明確軟件測試的對象與范圍，測試負責與項目組成員應充分溝通，對各種資料進行收集整理，對各階段測試工作需求進行分析，把測試內容細分成測試的需求，并保證其測試的可行性。測試計劃階段中，主要的任務就是按照測試需求來制定測試的計劃，計劃內容應包括：測試的環境、進度、用例及風險的分析等等。測試執行的階段中，應完成測試的實施與過程的監控。在缺陷跟蹤的階段中，主要是及時報告軟件的缺陷，跟蹤修改的進展情況。
3.2 強化對軟件測試突出問題的管理
一是防范思維定勢的問題。克服測試人員由于太過熟悉測試的軟件，從而建立起慣性的思維，造成測試的次數越是多，其發現缺陷機會反而越少的情況；防范方法是：測試人員不斷編制測試新程序及測試的用例，從而發現更多缺陷；還可用新人進行軟件的測試。二是防范定位效應的問題。測試人員的定位效應就是對于已測試功能不能進行認真的測試，由于疏于防范，可能會使缺陷一起存在；解決此問題方法為完整地實施測試用例，或者組織測試的人員進行交叉式的測試。
3.3 強化測試團隊的管理
嚴格員工考核，測試負責人定期組織項目組成員談話，定期評定做過什么和怎樣去做，做好測試人員的績效考核。加大培訓力度，系統學習相關領域的基礎和業務知識，強化日常培訓，深入學習特定的項目及技術，全面提升測試團隊的整體素質和能力。針對測試人員流動帶來的影響，建立相應的健全培訓工作機制，促進新任員工可以盡快地適應測試工作。
4 結語
綜上所述，軟件測試工作是軟件在投放市場使用前，對于軟件產品編碼的實現，設計的規格及需求的分析等內容所進行的最后一次審查，是軟件項目開發的一個重要的環節，對于軟件質量發揮著基礎保障的作用。因此，必須高度重視和加強軟件測試工作，不斷總結技術經驗，持續完善管理措施和辦法，以提升軟件產品的質量、推動軟件研發企業持續健康發展。
參考文獻
[1]楊亞南，孫忠林，李艷.軟件自動化測試淺談[J].科技信息，2007（24）.
[2]肖新鳳.Web應用程序性能測試技術的研究及應用[J].科技信息，2010（27）.
[3]張軍威.淺談如何以軟件測試推動軍工軟件工程化[J].硅谷，2011（14）.
摘要：《軟件測試技術》是一門實踐性很強的課程，需要在實踐中理解和掌握測試思想與方法。采用任務驅動的理論和實踐教學，提出加強實驗教學方法和途徑，強化學生的測試能力。
關鍵詞：軟件測試；任務驅動；實踐教學
0 引言
隨著中國軟件行業的不斷發展。軟件產品的質量關系到企業生存的重大問題。軟件測試是軟件質量的保障，企業對軟件測試投入逐年加大。但是國內軟件業對軟件測試的重要作用認識較晚，軟件測試的人才培養模式還不完善，企業找不到合適的軟件測試人員。由于傳統教學重理論輕實踐。為了適應市場需求，需要調整軟件測試傳統教學方式。
《軟件測試技術》要求有一定實踐動手的能力，能把所學的理論和實際應用聯系起來，才能真正理解測試思想和方法。在實踐教學方法上，采用任務驅動的方式，突出學生實際動手能力的培養。
1 任務驅動教學
任務驅動教學法是特別適合知識性與技能性相結合的學科的課堂教學，在教學過程中，以完成一個個具體的任務為線索，把教學內容蘊涵在每個任務之中，學生運用已有知識完成任務，在完成任務的過程中，發現問題，解決問題，主動、輕松愉快地掌握新知識和新技能。
由于軟件測試伴隨軟件的整個生命周期，《軟件測試技術》課程的理論教學和實驗教學，必須貫穿于軟件開發的全過程。由于軟件測試過程與軟件設計周期有相互對應的關系，軟件測試過程中的單元測試、集成測試、系統測試、驗收測試分別對應軟件設計中的詳細設計、概要設計、系統設計和需求分析。因此，軟件測試實踐教學需要在不同階段安排不同的實驗內容。要求學生扮演不同角色參與一個系統的完整測試過程。
2 實踐教學的前提
《軟件測試技術》課程需要在《軟件工程》和《Java程序設計》之后開設，學生利用前期所學知識完成《基于Web的圖書管理系統》和《簡易計算器》設計與實現。要求學生按照W模型來設計與開發。
3 不同測試階段的實踐教學
3.1測試需求分析的實踐教學
需求規格說明中說明的需求充分描述該系統所應具有的外部行為。測試需求是為了驗證需求的正確性、完整性、一致性等應具有的特性。教師把項目分給三個小組，每組召集相關人員（包含圖書管理人員）評審需求。全面了解需求情況。學生通過制作需求評審檢查表和測試用例設計可以發現需求的錯誤、二義性、不可測試性、遺漏等方面的問題。
學生應從不同于開發的角度進行分析，借助Ratio—nal完成數據流圖、實體關系圖和類圖、狀態轉換圖等完成捕述完整性檢查，需求項之間的不一致檢查等方面的功能，也可獲得軟件質量特性。對于任務是《基于Web的圖書管理系統》需求說明書的驗證和確認活動中。
3.2單元測試的實踐教學
要求學生掌握多種測試技術和測試用例的設計。是軟件開發過程中進行的最基本的測試。單元測試主要按照程序內部的結構測試程序。檢驗程序中的每條通路是否都能按預定要求正確工作。單元測試主要考慮各個模塊接口的輸入和輸出，模塊內部的數據結構，模塊的邊界條件，模塊的基本路徑和模塊的出錯處理。單元測試工具為Junit，在《基于Web的圖書管理系統》登錄功能模塊來實現程序異常情況處理、判定一條件覆蓋和條件組合覆蓋：在查詢模塊采用邊界值分析方法和等價類分析設計測試用例。
3.3類測試和回歸測試
要求學生理解面向對象的封裝、繼承和多態對測試的影響。在測試過程中，當發現一些缺陷需要修正時，會構造一個新的軟件包或補丁，然后進行測試。這時測試不僅要驗證被修復的軟件缺陷是否真正被解決。而且要保證以前所有運行正常的功能依舊保持正常。對應的任務是《簡易計算器》。
3.4集成測試
集成測試是單元測試的邏輯擴展。主要考慮的問題是單元模塊的組合能否正常工作：以及與其他組的模塊能否集成起來工作：全局數據結構是否有問題等。集成測試所持的主要標準是《軟件概要設計規格說明》，任何不符合該說明的程序模塊行為都應該加以記載并上報。要求學生采用自底向上的集成方法。根據《圖書管理系統的概要說明書》編寫測試計劃和設計測試用例，執行測試過程。并要求學生能描述缺陷和跟蹤缺陷。在報告軟件缺陷時不做任何評價。
3.5性能測試
性能測試主要是從系統的響應時間、吞吐量、系統資源利用率、并發用戶數、HTFP事務處理數/秒、會話數/秒和連接建立時間等方面衡量系統的性能。實驗對應于《基于Web的圖書管理系統》。要求采用逐步加壓策略。循環次數：暫定1次，視運行時間長短而定。虛擬用戶數：初始為50個，視測試結果和方案中的公式計算值確定是否需要繼續加壓。壓力機數量：初始為5臺，視測試結果而定。中間件服務器數量：初始1臺，視測試結果而定。要求學生能分析實驗結果，對系統調優。
【關鍵詞】測試模型 川模型 軟件測試 測試體系 川模型架構 測試組織簡圖 川模型價值
隨著科技的不斷進步，計算機應用已經完全深入到我們整個社會的體系中，人們現在已經無法適應沒有軟件的世界，您在讀這篇文章的時候，您的電腦正在工作、手機正在運行。甚至路上的汽車、信號燈都被軟件全副武裝。人們對軟件的依賴越來越大，雖然質量可靠的軟件給我們的工作和生活帶來了前所未有的便利，但是質量不好的軟件也讓我們付出過慘痛的代價，這讓我們充分認識到軟件質量正在牽動著社會的命脈。
為了提高軟件質量，軟件開發人員進行過大量的研究和實踐。從最初的技術革新，如編譯、調試工具等地研究到各種計算機輔助軟件環境，再到軟件開發模型的研究。但是這種以技術和方法為重心的研究沒有真正達到保證軟件質量的目的（但是確實對軟件質量的提高做出了貢獻）。所以，人們開始認識到只有對軟件開發過程的質量加以控制，才有可能大幅度的提高軟件質量。因此，軟件質量保證也從最初的以技術和方法為重心的模式，轉移到以過程管理為重心的實踐。
軟件質量保證的本質是為了確保軟件開發過程和結果符合預期要求而建立的一系列活動及其結果評價，其最終目的是缺陷預防，達到用戶的實際需求，避免安全風險。軟件測試活動是保證軟件質量的有力武器，從最初的調試、驗證，到現在形成的獨立測試體系，無一不體現質量保證的重要性和測試工作的必要性。
本文討論的目的：在現今科技發展的大潮下，為了提高軟件質量及工作效率，提出軟件測試的川模型。希望川模型找出一款適合中國國情的軟件測試思路和測試模型。
1 軟件開發、測試的現狀分析
目前主流的軟件開發模型有：螺旋模型、增量模型、漸進模型、快速軟件開發（RAD）以及Rational統一過程（RUP）等，這些模型對于軟件開發過程具有很好的指導作用，但是這些模型并沒有充分強調測試的價值，也沒有給測試以足夠的重視，利用這些模型不能更好地指導測試實踐。因此，軟件測試模型應運而生，它能夠系統的有計劃的指導測試與研發的一系列活動，對軟件質量的提高有著重要的作用。目前常見的軟件測試模型有V模型、W模型、H模型、X模型、前置測試模型等。
這些測試模型都在一定程度上完善和發展了軟件的測試體系，但是它們仍然存在著或多或少的問題，還沒有充分把測試對質量保證的能力發揮出來。下面分析一下幾款主流測試模型的優劣情況。
1.1 V模型的優劣分析
V模型強調軟件開發的協作和速度，反映測試活動和分析設計關系，將軟件實現和驗證有機結合起來；強調了在整個軟件項目開發中需要經歷的若干測試級別，并與開發級別對應。但是，沒有體現“盡早地、不斷地進行軟件測試”的原則；把測試作為編碼之后的最后一個活動，項目前期產生的錯誤直到后期才能測試發現；沒有明確指出對需求、設計的測試。
1.2 W模型的優劣分析
W模型強調了測試計劃等工作的先行和對系統需求和系統設計的測試；在整個軟件開發周期中，測試與開發并行進行，有利于盡早發現問題；提出了測試的對象包括程序、需求、設計等內容；及時了解項目的測試風險，及早制定應對方案，加快項目進度。但是，它沒有對測試規程進行說明，同時軟件開發和測試保持著線性的前后關系，無法支持迭代、自發性以及需求變更調整等經常面臨的問題。
1.3 H模型的優劣分析
在H模型中，軟件測試活動完全獨立，貫穿于整個軟件周期，與其他流程并發進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段；提出了軟件測試不僅僅指測試的執行，還包括很多其他的活動；測試是根據被測物的不同而分層次進行，不同層次的測試活動可以是按照某個次序先后進行的，但也可能是反復的。
1.4 X模型的優劣分析
X模型要求對每一個程序片段都進行單元測試，但沒能提供是否要跳過單元測試的判斷準則；多根并行的曲線代表著變更可以在各個部分發生，提高了迭代效率；它還定義了探索性測試，這一方式能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤，但對測試人員的能力要求比較高。
1.5 前置測試模型的優劣分析
該模型將開發和測試的生命周期整合在一起，標識了項目生命周期從開始到結束之間的關鍵行為；明確提出了每一個交付的開發結果都必須通過一定的方式進行測試；它還定義了“開發基于需求的測試用例”以及“定義驗收標準”，讓驗收測試和技術測試保持相互獨立。
以上模型都有其優劣，但總體來說，都沒有真正的把測試對質量的保障意義或時機把控好，大部分模型中，測試只是軟件開發過程的一部分，沒有明確獨立成一個體系，雖然H等模型把測試對產品質量保證的地位提升了不少，但是仍然缺少對測試規程、資料等重要性的體現。
2 川模型架構
針對軟件開發、測試的現狀存在的問題（并且結合各已知模型的優點），依據“以測試者引導開發，以文檔化把控質量”的測試實施理念，完善、發展了一個新的測試模型──川模型。
2.1 川模型
川模型由三條相對獨立的測試實施流程組成，因為類似中文的“川”字而得名。其中的三條測試實施流程分別是驗收測試實施流程、需求級測試實施流程、業務級測試實施流程。如圖1所示。
2.1.1 驗收測試實施流程
該流程提出的目的與重點在于保護用戶的真實需求，因為最終產品或項目能否成功交付，驗收結果是重要的依據，而驗收的主導者一定是用戶（代表）。該流程的起始階段就是在投入真正的研發和測試之前，根據項目需求及測試需求設計出驗收方案，以紙質方案的形式與用戶（代表）進行評審，以減少后期由于三方（用戶、研發、測試）需求不一致的原因導致開發迭代增加。同時，以此驗收方案為標尺，約束另兩個流程的實施。
2.1.2 需求級測試實施流程
該階段強調測試伴隨著整個軟件開發周期，測試與開發并行進行，達到盡早發現問題的目的。把測試的對象擴展成程序、設計（文檔資料）、數據等內容，測試工作實時準備，以達到在某個測試點準備就緒時，可迅速切入到測試執行階段。在該流程中，把迭代測試的內容進行了細致的分析與說明，明確提出迭代過程中需要進行單元/集成測試、功能測試、自動化測試、安全性測試以及專項測試。把自動化測試與安全性測試提高到測試指導階段，也是當今科技發展的必然趨勢。
2.1.3 業務級測試實施流程
如果把測試人員按測試能力分為測試負責人、測試執行人員，那么需求級測試實施階段的測試執行可以讓測試執行人員進行，但是業務級測試實施流程的主要執行人員就應該定位成測試負責人，至少應該是測試負責人主導測試。其根本原因在于該階段的意義是業務、風險等的把控，并且引入了探索性測試，是作為需求級測試階段的有利補充。
需求級測試實施流程與研發流程無縫有機結合。業務級測試實施流程存在的價值在于把控與掌握住了產品實際投入使用時的場景、風險等因素，對著重需求進行針對性的設計，滿足“八二法則”的經典理論，該流程即把重點放在了“二”上（用戶使用的80%的場景可能就存在于20%的功能中）。驗收測試實施流程依托于用戶的實際需求與前期的測試分析，它作為軟件生命周期的標尺，運行到產品或項目結項，最大程度上滿足用戶需求。
2.2 川模型的工作組織規程
從圖1可以看出：
川模型突出體現了測試活動對質量把控的重要性。從項目的可行性分析開始，測試人員就擔負著重要的角色。同時，把測試需求說明書、驗收方案、測試方案的重要性與提出時機進行了說明。體現：
（1）需求分析需要產品/項目經理、用戶、測試人員等全程參與；
（2）測試需求說明書需要測試人員起草，由產品/項目經理、用戶、研發等共同審核通過；
（3）驗收方案提前由測試人員編寫，由產品/項目經理、用戶共同審核通過；
（4）研發設計階段主要依據測試需求說明書編寫（其次可參考軟件需求說明書），在還沒有進行完代碼開發之前，測試人員提前輸出依據測試需求說明書編寫的測試案例，由研發人員提前參考，提高研發依據測試案例開發代碼的測試通過率；
（5）迭代階段大部分在需求級測試實施流程，測試工作實時準備，以便迅速切入測試執行；
（6）業務級測試實施階段的執行工作是需求級的補充，在軟件研發的中后期無縫切入；
（7）驗收執行的觸發點是業務級測試通過，驗收工作完成后，進行項目資料歸檔工作；
（8）研發過程中，如果有任何變更，需走變更控制程序，返回測試需求分析階段，并根據實際情況與要害人員輸出變更后的系列資料（驗收方案、測試案例等）。
3 川模型的甘特圖
在圖1中的左半部分，做了時間軸與等時線的定義。并且說明了不同職能人員的參與時機，已給大家在時序上的理解。
4 川模型的價值
4.1 體現測試的使命與重要地位
在川模型上，可以很容易的看出測試工作對軟件質量的保證意義與實施方法。區別于其他模型，該模型更加清晰、系統的說明了測試的使命，并且該模型真正站到了測試的角色，以測試保證最終用戶質量的認可下指導研發的工作，作為研發工作的標尺。
4.2 體現測試先行的重要意義
從產品/項目的可行性分析開始，測試活動就一直伴隨整個生命周期，真正體現了“盡早地、不斷地進行軟件測試”的原則。
4.3 文檔化的重要性與可追溯性的提出
在現今越來越快的產品/項目的交互進程中，人們對文檔化的需求越來越迫切，文檔化不僅可以使研發、測試過程更加有理、有據、科學，也為以后的可追溯性提供了基礎。同時，產品/項目前期就對測試案例化的要求，對研發的指導意義更大，研發完全可以“依據測試案例設計軟件，案例通過即研發完成”的標準進行開發活動，避免了由于需求不一致的情況下導致研發冗余或功能缺失，提高了工作效率。
4.4 提出三種測試技術相結合的規程
川模型第一次提出了三條執行線的工作模式。驗收實施流程作為整個產品/項目的指導流程執行，它與用戶最緊密相關，最能體現用戶的實際需求，同時避免、減少了在工作過程中的隨意變更；需求級實施流程則最有效的保證了測試覆蓋率，并且與研發的交互也更加順暢，提高了測試與研發迭代的敏捷度；業務級實施流程則通過有經驗的測試人員，把最重要需求做了風險、場景、探索等地設計驗證，可以這樣說，經過最后一條執行線的梳理后，用戶的實際并且經常使用的功能都被覆蓋到。
除了需求級實施流程與研發的交互緊密而充分外，另兩個流程相對獨立，降低了研發過程干擾，為保證軟件質量提供了有利基礎。
4.5 等時線為質量保證提供了基礎
該模型首次提出等時線的概念，在時序上，避免了工作重復甚至沒有必要的交叉。正如該模型的約束，我們必須先進行測試需求分析，輸出測試需求說明書后，才可進行驗收測試設計；在驗收測試設計快完成時，才可以進行需求級測試設計，保證了測試設計與驗收標準的高度統一；業務級實施流程通過后，才可進行驗收執行工作。從另一層面，也對測試提出了更高的要求，例如在研發提交代碼之前，測試的準備工作必須完成，可隨時切入工作；有需求變更時，測試人員需要先后更新測試需求說明書、驗收方案、測試方案等內容，審核通過后，實時共享給要害人員，確保項目的順利進行。
5 結束語
川模型的提出時間尚短，只在一兩個公司進行過相關實踐，看到了明顯效果；提高了測試人員的使命感與榮譽感；也減少了軟件開發過程中的冗余、遺漏問題。但是，該模型沒有經過大量的軟件企業實踐，還會存在或多或少的問題，僅作一個初步研究，通過這初步的研究，想拋磚引玉，真正找出一款適合中國國情的軟件測試思路和測試模型，也歡迎大家一起探討。
參考文獻
[1]柳純錄.軟件評測師教程[M].北京：清華大學出版社，2005.
作者簡介
李龍，現為北京賽博興安科技有限公司測試部門經理、北京軟達啟航科技發展有限公司CTO（兼）、濟南得潤萬家農業科技有限公司副總經理（兼）、中國軟件測試聯盟專家。他提出的“以測試者引導開發，以文檔化把控質量”的測試實施理念，在業界得到好評。先后出版《軟件測試實用技術與常用模板》、《云計算基礎與實用技術》、《無線網絡與應用技術》等7部書。
作者單位
1北京軟達啟航科技發展有限公司?CTO 北京市 100000
各位領導、老師，親愛的同學們：
大家下午好！
我叫xx，來自xx班級，很高興能夠代表2018軟件測試國賽隊上臺發言。在這次全國比賽中，xx和xx和xx組成的代表隊很榮幸獲得一等獎，成為此項賽事湖北省唯一獲獎的代表隊。這一成績不僅凝結著我們的汗水，更離不開學校和軟件工程學院領導的關心支持，輔導老師的辛勤培育。
這次參賽，使我們得到了很大提高和鍛煉，使我深深認識到了只要我們自己付出汗水和努力，就一定能夠得到回報。接下來，我代表我的隊員發表一下我們從培訓到參賽期間的心得體會：
1、始終保持一顆學習的心
剛開始訓練的時候，我們每個人對軟件測試都了解的比較淺薄，需要重新去學習這方面的知識，而理論知識的學習上是枯燥的，在這個過程中，我們每個人都戒驕戒躁，認真學習，討論、根據老師給出的測試用例設計方法來舉一反三。同時，我們要端正對訓練期間學習的態度，不能把訓練期間學習的內容當作要去比賽而完成的任務，要真正的探討，把老師教會的知識完全理解、學會，然后運用到實際操作當中。
2、
責任心和毅力是獲獎重要因素
從3月初選拔到5月底競賽，中間經歷了將近3個月的訓練，我們每天早8晚8，訓練12個小時，每天進行2次模擬練習，練習、總結、再練習、再總結。這個過程是枯燥的，別的同學周末、清明節、勞動節在放假、休息時，我們在培訓室敲打著鍵盤，每天都想著自己去提升自己，比如說：比昨天多寫50條測試用例，兩篇文檔的時間再縮短5分鐘，Bug找的更多，性能測試能夠解決環境問題。4個小時的比賽時間，我們訓練時間從最初的4個小時，壓縮到3個半小時，再壓縮到3個小時。時間安排上從剛開始的早上2小時，下午2小時，改到和比賽時間相符的早上9點到下午1點。每次訓練完后我們都會向老師匯報任務完成度，不足之處，進行自我總結，不浪費一絲時間，甚至在去往許昌的高鐵上，我們每個人都拿著一撮打印好的知識要點默讀，直到參賽前一天的晚上，才結束這種狀態。
3、
細節和臨場應對是取勝關鍵
比賽中有很多實力強的團隊，但是有的獲得了一等獎，有的沒有獲得一等獎，其原因就在于細心和臨場應對能力。4個小時，6篇文檔，很多隊都能做到，但是得分的關鍵就在于細節。我們從訓練開始就注重細節問題，盡量不因細節問題丟分。其次是臨場應對，賽場上的環境是多變的，我們訓練的環境并不可能百分百與賽場環境相符，為了保證在比賽期間不因環境問題打亂計劃，在訓練的過程中，出現的環境問題都是我們盡量自己去解決，實在解決不了才會詢問老師。同時，我們還假想了很多賽場上會出現的問題，并且制定了相應的策略，以充足的準備去面對賽場。
4、
團隊協作很重要
1 新時代背景下的ORACLE問題
在軟件工程中，軟件測試地目的是為了能夠發現和找出軟件錯誤運行的情況，專門判斷測試過程是否通過的可驗證即被稱為ORACLE，在如今新時代的背景下，不管是趨勢分析還是相應的圖論計算等，都開始變得越來越困難。新時代的處理模式，主要包括了物理作用下的數據處理和化學作用下的數據處理兩種類型模式。其中，物理作用下的數據處理，主要是在保證其價值的情況下，不斷的縮小其數據的規模，然后由此清洗不變的數據基本屬性。這其中就包含了針對數據處理的多種方式，能夠有效的實現將新時代花銷，的物理式變化。因此，物理作用下的數據處理測試ORACLE本身并沒有問題。
而基于化學作用下的數據處理，則具備最主要的預測和快速算法的問題，這兩個問題都非常經典，直接促使ORACLE的確定變得異常的困難。比如在計算個性化推薦統計學信息當中，經過個性化推薦的商品，更容易獲得用戶們的喜愛，當然也存在一半不喜歡的概率。而經過計算的結果也只是表明此類商品被喜歡的概率相對較高。概率性問題直接導致結果的正確性和確定性產生本質的區別，直接致使ORACLE確定的難度。
2 傳統測試平臺難以符合新時代處理的要求
以往所采用的軟件性能測試，主要是借助控制器協調本地直接向服務器端發出服務的請求，由此實現對服務器壓力的測試，其測試負載產生器都屬于局部的物理主機。相對少量的服務器構成應用系統來說，用戶數在數百上千量級的應用服務，才能有效滿足應用的需求。
如今，隨著云計算的發展，用戶的需求也在不斷的增長，其多個系統所需支持的并發用戶也在不斷的增加，相應的訪問量也在由此攀升。這就需要針對服務端系統是否能夠真正承受如此巨大的用戶訪問量進行有效的測試，可直接在系統上線之前就展開較為充分的測試內容。以往局域網主機測試方法所產生壓力，很難真正滿足服務器對其所產生的壓力測試需求。由此軟件測試工作中開始出現一系列的問題。一是負載產生器的物理機數量很難獲得動態的擴展；二是新時代所驅動的云計算系統，直接采用了廣泛的分布客戶端。三是在網絡海量數據的推動下，控制器所監控的負載產生器狀態直接成為性能測試的瓶頸，很容易由此引發測試失敗。四是控制器對負載產生器的同步問題變得越來越復雜，直接影響到負載測試的效果。
3 軟件服務化所引發的測試挑戰
具體從開發的模式而言，軟件開發的過程，主要包含了完全編碼、構件化、服務以及云計算等多個階段。
3.1 完全編碼階段
主要是相應開發人員直接從零基礎開始對每行代碼的編寫過程，除了系統本身所提供的類庫之外，通常所有的代碼都是直接由相應開發人員所掌握。在此階段當中，用戶們普遍具有良好的可測性，幾乎所有的測試和調試方式都可以實現。
3.2 構件化階段
該階段直接是為了提升軟件開發的效率，要求相應開發組織必須在系統類庫的基礎上，結合業務自身的特點來構建出可復用的業務組件。而通常該組件都是在本地運行，因此其業務系統的耦合度明顯偏高，用戶們對于組件的掌控也明顯較大。
3.3 服務階段
在此階段當中，多數本地組件所提供的調用可轉變成為遠程服務形式。用戶們可對外部的服務控制處于逐漸減少的狀態，只能透過服務的輸入和輸出來實現對服務情況的良好把握。
3.4 云計算階段
這一階段主要是特別架構和PASS之上的應用程序，在處理輸入和輸出的同時，多數用戶并不具備了解PASS服務運行情況的能力，因而導致用戶測試的難度再次增加。
4 殺蟲劑效應
在軟件工程測試領域當中，殺蟲劑效應是指相應的測試軟件越來越多，其免疫能力變得越來越強的現象。這種現象就如同采用農藥殺蟲是一樣的效果，如果持續采用一種單純的農藥，則害蟲將最終在體內產生一定的抗體，在此情形下，農藥將無法發揮出應有的殺蟲效力。而在多種構件化開發當中也是如此，通常在中前期發現多種缺陷的模式，其都可直接通過校驗和驗證的方式集成在構件當中，乃至直接成為構件的必然屬性。此類構件并不需要開發人員進行單獨的代碼編寫，其直接對測試的方式產生了天然性的免疫能力。
在軟件工程中，殺蟲劑效應將有效的促使軟件的測試技術獲得飛躍式的更新升級，可迅速的找出存在軟件當中的缺陷問題。一般在進行測試的初期階段，只需通過較少的測試即可直接發現其中所存在的更多缺陷，而在后期的測試當中，則很容易發現其所存在的缺陷數量，將漸漸趨于平緩，甚至最終在某個周期停止增長。
關鍵詞： 軟件測試 測試用例 復用技術
1.引言
隨著軟件工程領域的拓展，在軟件產業飛速發展的今天，軟件測試成為保證軟件質量的重要手段。測試用例的選擇對于軟件測試的成敗起著決定性作用，因此如何設計最少的測試用例實現最大的測試覆蓋成為自動化測試領域中的主要研究對象。測試用例是確定一組最有可能發現錯誤的測試數據和流程，實現系統對某個功能的測試［1］。而測試用例的設計與測試人員的個人經驗息息相關，不同測試人員的個人經驗和書寫格式的差異導致了測試的盲目性，以至于產生較高的后期維護費用。測試用例的復用技術一方面是為了解決由測試人員經驗不足帶來的問題，同時還避免了在設計測試用例中的重復勞動，有效地提高了測試效率。
2.軟件測試
2.1軟件測試的定義
軟件測試（Software Testing）是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例（包含輸入數據及其預期的輸出結果），并用這些測試用例去運行程序，以發現程序錯誤的過程［2］。
2.2軟件測試的目的
Glenford J.Myers就軟件測試的目的提出了以下觀點：
2.2.1測試是程序的執行過程，目的在于發現錯誤；
2.2.2一個好的測試用例在于能發現至今為止尚未發現的錯誤的用例；
2.2.3一個成功的測試是指揭示了至今為止尚未發現的錯誤的測試。
測試的目的花費最小的代價找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷來提高軟件質量，回避因軟件潛在錯誤和隱患帶來的商業風險［3］。
3.軟件測試用例的復用
3.1軟件測試用例的復用
軟件測試復用可以理解為在兩次或多次不同的軟件測試過程中重復使用相同或相近的測試資源來組織測試的過程［4］。軟件測試的復用主要包括測試流程的復用、測試方法的復用和測試用例的復用。其中測試用例的復用是測試復用中的關鍵技術。所謂測試用例復用是指對一個軟件已執行的測試用例，將其不同程度地應用于該軟件新階段的測試中或其他軟件的測試中。可復用的測試用例具有通用性、獨立性、有效性、標準化和完整性的特點［5］。
3.2可復用測試用例的設計
測試用例能否成功被復用很大程度上取決于測試用例的獨立性，即能否獨立地應用于不同的應用場合和應用環境。在實際應用當中，很多測試用例之間存在著相互的關聯。有的測試用例的運行環境要取決于另外測試用例的執行狀態，當它所依賴的環境變化或失效時，而與之相關聯的其他測試用例的復用屬性也可能隨之消失。那么如何設計不依靠軟件運行環境具有較高獨立性、與其他測試用例減少關聯且具有統一輸入輸出接口的可復用的測試用例就成為問題的關鍵所在。
測試用例是面向不同應用對象的，與被測試軟件具有很高的耦合性。為了使得設計的測試用例能夠實現成功復用，在測試用例的設計上采取如下步驟。
3.2.1共性分析
首先應該對被測軟件進行共性分析，同一應用領域的軟件有相似的需求，分析其諸如工作流程或功能相同等共同特點，并根據他們的共性挖掘可復用因素。
3.2.2測試用例統一建模
根據可復用因素，設計合適的測試策略，對測試用例的設計做出統一的建模組織，設計統一的結構和輸入輸出接口。
3.2.3設計可復用的測試用例
為了盡可能地降低測試用例與被側軟件的相關性，在設計測試用例時應該盡量對其進行通用化處理，同時應保持測試用例的功能單一性。測試用例和被測軟件的高耦合性決定了測試用例的復用大多只在同一軟件的回歸測試或版本升級測試中成功實現，而很難在不同應用領域的軟件測試中使用。
3.2.4測試用例的測評
設計好測試用例之后，組織測試人員和評審專家根據功能需求將測試用例應用于被測軟件的測試中，確保測試用例的正確性。改變軟件運行環境或測試數據后是否能得出合理的測試結果，分析異常和邊界情況的測試結果。
3.2.5完善測試用例
根據測試結果分析測試用例是否覆蓋并測試了全部的共性需求，進一步完善或糾正測試用例。
3.2.6測試用例入庫
將通過測評和完善后的可復用測試用例根據其屬性和功能分門別類并按照一定的組織結構放入測試用例數據庫中。
3.3可復用測試用例的管理
測試人員要對用例數據庫進行統一有效管理，提供測試用例的功能屬性、運行環境、測試方法和項目來源以供測試人員以后的查詢和使用［6］。管理人員要及時刪除冗余，避免重復用例出現。隨著軟件技術的發展和測試用例數目的不斷增加，對那些不再具備復用價值的測試用例移入其他數據庫，以便提高搜索和使用效率。
4.結語
軟件測試的復用是目前測試領域研究的熱點問題，而設計可復用的測試用例又是實現測試復用技術的關鍵。本文介紹軟件測試用例復用的同時，在理論上給出了可復用測試用例設計的思想和具體方法。在實踐中，實際存在的問題往往比我們可以預想到的更多、更復雜，在不同領域和不同功能的軟件中實現測試復用的難度更大，需要我們在不停總結經驗的基礎上還要靈活運用，合理有效管理，才能使測試復用技術進一步發展，提高測試效率，更好地服務于軟件產業。
參考文獻：
［1］張玉彬，謝康林.測試用例的設計和復用［J］.計算機應用與軟件，2008，25，（1）：23-24.
［2］繆靜.基于Web應用的測試研究與應用［D］.成都.電子科技大學，2005.
［3］趙中芳.基于CBR的測試用例復用模型的研究與應用［D］.青島：中國海洋大學，2008.
［4］卜國峰，孫志剛，丁小良.軟件測試用例的復用研究［J］.四川兵工學報.第30卷第5期，2009.5：34-35.
關鍵詞：自動化軟件測試；模糊測試；錯誤定位
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2014）06-1231-04
計算機的應用越來越多地深入到人們的日常生活中，然而計算機軟件還遠沒有達到零錯誤的要求。提高軟件質量已經成為軟件工程領域亟待解決的重要問題。軟件測試，作為一種提高軟件質量的重要手段而備受重視。在軟件的開發生命周期中，軟件測試是一個耗時耗力的過程，已成為軟件開發的瓶頸之一[1]。據統計，軟件測試約占軟件開發和維護成本的50%～75%[2]，因此，改進和改善軟件測試技術變得十分迫切與重要。模糊測試[3]是一種通過提供非預期的輸入并監視異常結果來發現軟件漏洞的技術。模糊測試一般是一個自動或半自動的過程，這個過程包括反復操縱目標軟件并為其提供處理數據。近年來，有很多學者在不同類型軟件的軟件測試中都證實了模糊測試技術的有效性和自動化的特點。模糊測試技術針對不同類型的測試環境有不同的測試策略。例如，張等人[4]提出了一種針對網絡協議及模糊測試框架。沈等人[5]提出了一種基于文件規范描述的文件模糊測試算法，有效避免“無效”測試用例的生成，提高效率同時也增加了測試的全面性。
上面提到的模糊測試的研究重點主要集中在模糊器的設計與實現上，幾乎沒有涉及到錯誤定位的技術。基于頻譜的錯誤定位方法是基于實際執行的動態錯誤定位技術的具體應用。Harrold等人證實了程序頻譜與程序行為之間的關系，論證了通過研究運行失敗測試用例得到的頻譜信息與運行成功測試用例得到的頻譜信息之間的差異性可為定位出錯語句提供幫助[6]。該文調研了模糊測試技術和自動化錯誤定位技術的研究進展；第2節論述了自動化錯誤挖掘與定位技術可行性，并解釋本文技術的動機；第3節介紹自動化錯誤挖掘與定位技術的實現方法；模型的實現將在第4節給出；第5節總結并展望未來的研究方向。
1 研究動機
在軟件的生命周期中，軟件的維護成本所占比例特別大，所以一個好的軟件測試方法是非常必要的。一種優秀的測試方法可以發現軟件中存在的大部分漏洞，從而可以降低軟件的維護成本，提高軟件的質量。模糊測試是1989年由Bartoon Miller教授首先提出的，并通過模糊測試在UNIX存在的大量漏洞。在1999年Oulu大學開發PROTOS測試集，這標志著模糊測試發展歷程的一個重要里程碑。2002年PROTOS開始成熟，在2004年文件模糊測試開始興起，AxtiveX模糊測試在2006年開始流行。到目前為止模糊測試取得了一定的發展，已經是軟件漏洞挖掘中不可或缺的技術，但是這項技術仍然不是特別成熟[3]。圖1給出了模糊測試的過程。
軟件錯誤定位技術是通過運行測試用例得到程序的各條語句被測試用例覆蓋的信息，然后利用覆蓋信息計算出程序中語句的出錯可疑度[7]。在實際的測試過程中，有很多情況是測試用例導致程序的崩潰，程序崩潰時寄存器中的信息也是非常重要的。所以利用程序的覆蓋信息與程序崩潰是寄存器存儲的信息共同來定位程序的出錯信息可以提高定位的精度和速度。利用GCC中的GCOV命令可以收集C程序的運行的詳細信息，包括覆蓋率、代碼的執行路徑、程序的執行結果等信息。利用GDB調試器可以查看程序運行時CPU寄存器的狀態。
隨著計算機的不斷發展，程序的代碼越來越龐大，基于源代碼審核的白盒測試需要大量的人力和時間，這會大大增加軟件開發的成本。軟件測試的自動化是未來軟件測試發展的主要方向，通過把模糊測試技術和軟件錯誤定位技術結合起來，可以實現軟件測試的自動化，提高軟件維護的效率。
2 自動化錯誤挖掘與定位技術
在這一節將介紹自動化錯誤挖掘與定位技術的總體結構，以及對結構中各主要模塊的功能與實現。
2.1 自動化錯誤挖掘與定位技術的總體結構
為了實現軟件測試的自動化，所提出的解決方案由一下幾個模塊組成：模糊器模塊，測試結果記錄模塊，錯誤位置分析模塊。圖2為自動化錯誤挖掘與定位技術的流程圖。
圖2 自動化錯誤挖掘與定位技術的流程圖
2.2 模糊器模塊
模糊器模塊的主要作用是生成測試用例，并把測試用例提交給被測軟件，是模糊測試的核心結構。模糊測試可分為兩類[8]：基于變異的模糊測試和基于生成的模糊測試。對于不同的測試目標有不同的模糊器，其中主要的分類有：
1） 環境變量和參數。測試對象主要是命令行參數和環境變量，主要的模糊器是iFuzz。
2） Web應用程序和服務器。針對Web服務器的存在漏洞的模糊器有Dave Aitel開發的SPIKE和WebScarab。
3） 文件格式。針對特定的文件格式，用于挖掘客戶端文件解析漏洞，主要的模糊器有notSPIKEfile、SPIKEfile和FileFuzz。
4） 網絡協議。通過特定的Socket形式將變異或者含有錯誤的數據包發送給目標程序，相應的模糊器有SPIKE和ProtoFuzz。
此外對于特定的測試目標，我們也可以手動構造模糊器，在構造模糊器時要充分考慮程序中可能存在的問題，例如：拒絕服務、整數處理問題、簡單的棧和堆溢出、格式化字符串和目錄遍歷等。對于不同的問題確定模糊器不同的用例生成規約。例如，對于整數處理問題，我們可以設計這樣的用例規約：生成邊界值附近的測試用例0，-1，1，2，3，0XFFFFFFFF-1，0XFFFFFFFF-2等測試用例。此外，我們還可以直接在網上下載有用的工具和庫，具體請查看文獻[12]。
2.3 測試結果記錄模塊
我們的目標是實現軟件測試的自動化，所以就不能依賴人工識別錯誤。為了實現這個目標，我們需要一種可靠的，可編程的方法。有一種方法是檢查程序的返回代碼[9]，在現在的UNIX和Linux系統中，如果一個應用程序因為一個為處理的信號而中止，那么Shell的返回代碼將等于128加上該信號數字。可以利用這個值來判斷不同的錯誤。還有就是把應用程序連接到調試器，錯誤處理機制將阻止由模糊測試所導致的許多錯誤的明顯標記，但是這些錯誤一般可以通過使用一個調試器來發現。在Linux操作系統中，GDB就是一個特別好的調試器，一般來說，GDB主要幫助你完成下面四個方面的功能：1）啟動你的程序，可以按照你的自定義的要求隨心所欲的運行程序；2）可讓被調試的程序在你所指定的調置的斷點處停住；3）當程序被停住時，可以檢查此時你的程序中所發生的事；4）動態的改變你程序的執行環境。對于有些應用程序，我們也可以通過見識其運行日志帶識別程序的運行結果。
測試用例執行路徑是用于錯誤定位分析的主要數據，檢測程序的主要方法是在程序的源代碼中進行插樁，根據程序的執行結果來得到一個測試用例的執行路徑。但是這種方法是基于語句的，在前期對源代碼的處理中費時費力，效率低下。在這里提出了一種新的插樁策略，在程序運行的時候，有很多語句塊只要語句塊的第一條指令被執行，其后面的所有語句都會被執行，把這樣的代碼塊稱為基本塊。在插樁時以基本塊為單位，這樣可以減少前期的準備工作，又可以提高程序的運行效率。
對于每個測試用例的結果都進行保存，用于最后的定位分析。我們把用例執行的相關信息保存到數據庫中，其中數據庫有三個標，分別用為：
1） 代碼表（codes），用來存儲程序的源代碼；
2） 用例執行信息表（info），用來存儲用例執行的各種信息，主要用，測試用例、執行路徑、執行結果等；
3） 異常表（abnormal），存儲導致程序出現異常時CUP各寄存器以及堆棧中的信息。
下面是記錄模塊的結構圖。
圖3 記錄模塊結構圖
2.4 錯誤位置分析模塊
錯誤位置分析模塊的功能是根據數據庫中的測試數據計算可能出錯或存在漏洞的語句。因為數據庫中記錄了每條測試用例的執行路徑和執行結果。可以利用數據庫強大的數據處理能力，計算出錯路徑中每條語句的可疑度，其計算公式如公式（1）：
[RESULTi（s）=TFi（s）TFi（s）+TP（s）] （1）
其中，TFi（S）經過語句S出錯（錯誤類型為i）的測試用例個數，TP（S）是正常經過語句S的測試用例數。最后得到的結果為一系列語句可疑度的列表，其中可疑度最大的，出錯的可能性也最大。
3 模型實現與實驗
實驗模型是建立在ubuntu 13.04 操作系統上，應用的開發語言是Python 2.7.4，數據庫是Mysql Server 5.5.31。在實驗模型中主要用到的軟件有GCov 4.7.3和GNU gdb （GDB） 7.5.91.20130417-cvs-ubuntu。GCov用于收集用例執行路徑，Gdb用于查看測試軟件的執行細節。實驗用的目標程序是從SIR[10]（http：//sir.unl.edu）網站上下載的grep。實驗中數據庫表結構如下表。
表1 目標程序代碼表
表2 用例執行路徑表
表3 用例執行路徑表
通過簡單的模擬實驗，驗證了該方法在軟件測試中代碼覆蓋率、漏洞定位準確性有明顯的提高，并且為發現的漏洞提供了相應的信息。并且在整個軟件測試過程中，需要人干預的地方很少，基本實現了從用例生成、錯誤檢測和錯誤定位的自動化。
4 總結與展望
本文中提到的軟件測試方法實現了軟件測試中用例生成、測試與錯誤定位分析的自動化，提高了軟件測試的效率，加快了軟件開發的周期，降低了軟件維護的成本。同時該方法也存在一定的局限性，不能測試出軟件中存在的邏輯錯誤，也不能能驗證軟件功能的完整，只對軟件中存在其他錯誤（非法引用、堆棧溢出、格式化字符串等）有效。
在以后的研究中，應探索新的軟件錯誤定位的方法和技術。可以從一下幾個方面展開研究：
1） 利用動態的二進制插樁。在軟件測試中，有很多錯誤不能直接被發現，例如：函數的堆棧溢出，如果溢出只是覆蓋了函數中的一些變量，沒有覆蓋函數的返回地址，即EIP的值。這種情況程序是不會報錯的，根據程序的運行結果很難定位錯誤。所以利用動態二進制插樁來實時監控程序的運行狀態是一個不錯的研究方向。
2） 利用人工只能，實現軟件錯誤定位與自動修復。隨著計算機技術的發展，軟件規模越來越大，Binkley 估計到 2025 年人們開發的代碼將達到萬億行[11]。面對數量龐大的代碼，數據挖掘、機器學習等人工智能技術將會在故障定位方面得到很好的應用。
參考文獻：
[1] Zhang Yu-Qian，Zheng Zheng，Ji Xiao-Hui. Markov Mpdel-Based Effectiveness Predicting for Software Fault Location[J].Chinese Journal of Computer， 2013，36（2）：445-448.
[2] Yu Kai，Lin Meng-Xiang.Advances in automatic fault localization techniques.Chinese Journal of Computer，2011，34（8）：1411-1422.
[3] Sutton M，Amini A G P.Fuzzing： Brute Force Vulnerability Discovery[M]. 黃隴，于莉莉，李虎，譯.北京：機械工業出版社，2009：13-20.
[4] 張寶峰，張斌，許源.基于模糊測試的網絡協議漏洞挖掘[J].清華大學學報：自然科學版，2009，49（S2）：2113-2118.
[5] 沈亞楠，趙榮彩，王小芹，等.基于規范生成的文件模糊測試[J].計算機工程與設計，2010，31（16）：3591-3594.
[6] Harrol M J，Rothermel G，Wu R，Yi L.An empirical investigation of program spectra[C].Proceedings of the ACM SIGPLAN/SIGSOFT Workshop Program Analysis for Software Tools and Eng （PASTE' 98）. Montreal， Quebec，Canada，1998：83-90.
[7] 譚德貴，陳林，王子元，等.通過增大邊際權重提高基于頻譜的錯誤定位效率[J]. 計算機學報，2010，33（12）：2335-2338.
[8] 陳衍鈴，王正.模糊測試研究進展[J].計算機應用與軟件，2011，28（7）：291-293.
[9] Sutton M，Amini A G P.Fuzzing：Brute Force Vulnerability Discovery[M].黃隴，于莉莉，李虎，譯.北京：機械工業出版社，2009：65-66.
[10] Do H，Elbaum S G，Rothermel G.Supporting controlled experimentation with testing techniques： an infrastructure and its potential impact[J]. Empirical Software Engineering，2005，10（4）：405-435.
【關鍵詞】軟件測試；安全測試；測試要點；策略
軟件開發的完善給測試人員帶來巨大的壓力，從開發至軟件投入使用，都不缺測試工程師的身影。其中過程需要六大質量特性的測試、性能測試、甚至安全測試。針對安全保密性方面，測試工程師需要利用資源進行測試要點的收集及測試用例的設計，從而更多的發現軟件運行時可能出現的安全漏洞。
一、數據庫安全的測試策略
數據庫安全是整個系統的核心，系統中所有用戶的信息全依靠數據庫的校驗。在數據庫測試策略中，針對B/S架構軟件最常用的有身份鑒別、安全審計、漏洞安全等三方面。
（一）身份鑒別：為的是測試數據庫系統賬戶口令和傳輸的安全性，執行過程中主用SELECT * FROM DBA_PROFILES命令，其中包涵的內容有：1.數據庫系統密碼復雜度函數必須實現配置，以避免密碼被破解而導致用戶敏感信息泄露。2.用戶登錄系統失敗有處理機制，以避免有意人員利用會話失敗，進行用戶并發攻擊數據庫，致使數據庫崩潰。3.在用戶連接數據庫后閑置超時，必須有配置自動退出，以避免用戶敏感信息被惡意抓包。
（二）安全審計：對數據庫系統日志審計的安全性進行測試，保證數據庫審計策略配置必須達到基線要求。
（三）漏洞安全：同樣是對數據庫系統日志審計的安全進行測試，保證數據庫能達到安全配置要求：1.數據庫必須存在拒絕服務攻擊配置。2.不能有遠程溢出等安全漏洞。3.數據庫組件必須安全配置完備，無漏洞。4.數據庫內核漏洞均已修復。
二、WEB應用安全：B/S架構已成為市場信息系統開發的主流，而WEB應用的安全防護更需要謹而慎之，下面羅列出針對WEB應用安全的常見的測試策略
（一）密鑰管理：要求根據某個指定的標準規定的算法和密鑰長度來生成密鑰。操作步驟：1.進入Web應用系統，打開密碼修改功能；2.查看Web應用的密碼修改功能是否需要輸入原密碼。3.設置簡單密碼123456，記錄返回結果。期望結果：修改密碼是需要輸入原密碼，并且不能設置簡單密碼。
（二）輸出到TSF控制之外：經由本功能輸出的用戶數據輸出時沒有輸出相關的安全屬性。操作步驟：1.使用webscarab對登錄操作進行抓包；2.查看數據包內容是否為明文傳輸。期望結果：數據包中的密碼已進行加密處理。
（三）信息流控制功能：對每一個操作，主體和信息的安全屬性之間必須支持基于安全屬性的關系，TSF應允許信息在受控主體和受控信息之間經由受控操作流動。操作步驟：1.打開appscanweb安全掃描軟件；2.新建任務；3.輸入域名；4.開始掃描；5.記錄掃描結果。期望結果：不存在注入漏洞及跨站漏洞。
（四）TOE內部傳送：數據在傳輸過程中，期間的所有設備都必須對傳輸數據的完整性座監視。操作步驟：1.使用webscarab進行抓包；2.修改數據包中內容；3.查看返回信息。期望結果：無法修改數據包中內容
（五）殘余信息保護（TSF數據管理）：確保系統內文件、目錄等資源所在的存儲空間，被釋放或重新分配給其它用戶前得到完全清除。
（六）訪問控制功能：提供訪問控制功能，依據安全策略控制用戶組對系統功能、文件、數據庫表等客體的訪問。
（七）鑒別失敗：檢測系統對用戶多次嘗試登錄失敗，系統做出相應的處理。操作步驟：1.連續輸入十次賬號密碼；2.查看系統對該賬號是否鎖定。期望結果：賬號被鎖定。
（八）用戶標識：在登錄網站前要求用戶必須輸入用戶名。操作步驟：1.打開web登錄頁面；2.查看是否需要輸入用戶名和密碼才可登錄。期望結果：必須輸入用戶名和密碼。
（九）不可觀察性：要求功能或資源的使用不能被規定的用戶或主體觀察到，規定用戶隱私有關的信息在評估對象內是分布式的。期望結果：1.進入應用系統-使用最高權限管理員登錄系統，在用戶管理中查看有哪些級別用戶和用戶的權限；2.退出系統使用普通用戶登錄系統，去訪問非授權資源，和查看非授權的信息。期望結果：無敏感信息泄露。
（十）時間戳：評估對象的安全功能需為它自己的使用提供可靠的時間源。
（十一）評估對象訪問旗標：在建立一個用戶會話之前，評估對象安全功能應顯示有關未授權使用評估對象的一個勸告性警示信息。
（十二）會話鎖定：在一定時間內，用戶沒有做任何操作，系統則自動鎖屏或顯示一個非重要功能的頁面，當用戶再次使用時，需要重新登錄。操作步驟：1.進入web系統；2.閑置5-10分鐘；3.刷新頁面；4.記錄返回結果。期望結果：賬戶已自動退出。
三、主機安全：主機是系統客戶端與數據庫進行數據交換的中心，在其上的安全跟數據庫安全相同，需要針對身份鑒別、安全審計、漏洞安全進行探察
（一）身份鑒別：1.系統配置避免重復UID策略。2.系統配置密碼安全策略。
（二）安全審計：操作系統中必須開啟安全審計策略。
（三）漏洞安全：系統不存在高風險安全漏洞。
總之上述只是簡單常見的安全測試要點，安全測試涉及的知識面很廣，不同的軟件領域需要的測試點不同，此時則需要我們在實際工作過程中自我總結出屬于自己并適合公司的測試要點。
參考文獻：
[1]GB-T 16260.1-2006 軟件工程 產品質量.
