軟件測試:實際輸出與預期輸出間的比較過程-中文百科頻道

概述

軟件測試是伴随着軟件的産生而産生的。早期的軟件開發過程中軟件規模都很小、複雜程度低，軟件開發的過程混亂無序、相當随意，測試的含義比較狹窄，開發人員将測試等同于“調試”，目的是糾正軟件中已經知道的故障，常常由開發人員自己完成這部分的工作。對測試的投入極少，測試介入也晚，常常是等到形成代碼，産品已經基本完成時才進行測試。到了上世紀80年代初期，軟件和IT行業進入了大發展，軟件趨向大型化、高複雜度，軟件的質量越來越重要。這個時候，一些軟件測試的基礎理論和實用技術開始形成，并且人們開始為軟件開發設計了各種流程和管理方法，軟件開發的方式也逐漸由混亂無序的開發過程過渡到結構化的開發過程，以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征。人們還将“質量”的概念融入其中，軟件測試定義發生了改變，測試不單純是一個發現錯誤的過程，而且将測試作為軟件質量保證(SQA)的主要職能，包含軟件質量評價的内容，Bill Hetzel在《軟件測試完全指南》(Complete Guide of Software Testing)一書中指出：“測試是以評價一個程序或者系統屬性為目标的任何一種活動。測試是對軟件質量的度量。”這個定義至今仍被引用。軟件開發人員和測試人員開始坐在一起探讨軟件工程和測試問題。

軟件測試已有了行業标準(IEEE/ANSI )，1983年IEEE提出的軟件工程術語中給軟件測試下的定義是：“使用人工或自動的手段來運行或測定某個軟件系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差别”。這個定義明确指出:軟件測試的目的是為了檢驗軟件系統是否滿足需求。它再也不是一個一次性的，而且隻是開發後期的活動，而是與整個開發流程融合成一體。軟件測試已成為一個專業，需要運用專門的方法和手段，需要專門人才和專家來承擔。

測試原則

對計算機軟件進行測試前，首先需遵循軟件測試原則，即不完全原則的遵守。不完全原則即為若測試不完全、測試過程中涉及免疫性原則的部分較多，可對軟件測試起到一定幫助。因軟件測試因此類因素具有一定程度的免疫性，測試人員能夠完成的測試内容與其免疫性成正比，若想使軟件測試更為流暢、測試效果更為有效，首先需遵循此類原則，将此類原則貫穿整個開發流程，不斷進行測試，而并非一次性全程測試。

測試方法

1、靜态測試方法

靜态測試方式指軟件代碼的靜态分析測驗，此類過程中應用數據較少，主要過程為通過軟件的靜态性測試（即人工推斷或計算機輔助測試）測試程序中運算方式、算法的正确性，進而完成測試過程，此類測試的優點在于能夠消耗較短時間、較少資源完成對軟件、軟件代碼的測試，能夠較為明顯地發現此類代碼中出現的錯誤。靜态測試方法适用範圍較大，尤其适用于較大型的軟件測試。

2、動态測試

計算機動态測試的主要目的為檢測軟件運行中出現的問題，較靜态測試方式相比，其被稱為動态的原因即為其測試方式主要依賴程序的運用，主要為檢測軟件中動态行為是否缺失、軟件運行效果是否良好。其最為明顯的特征即為進行動态測試時軟件為運轉狀态，隻有如此才能于使用過程中發現軟件缺陷，進而對此類缺陷進行修複。動态測試過程中可包括兩類因素，即被測試軟件與測試中所需數據，兩類因素決定動态測試正确展開、有效展開。

3、黑盒測試

黑盒測試，顧名思義即為将軟件測試環境模拟為不可見的“黑盒”。通過數據輸入觀察數據輸出，檢查軟件内部功能是否正常。測試展開時，數據輸入軟件中，等待數據輸出。數據輸出時若與預計數據一緻，則證明該軟件通過測試，若數據與預計數據有出入，即便出入較小亦證明軟件程序内部出現問題，需盡快解決。

4、白盒測試

白盒測試相對于黑盒測試而言具有一定透明性，原理為根據軟件内部應用、源代碼等對産品内部工作過程進行調試。測試過程中常将其與軟件内部結構協同展開分析，最大優點即為其能夠有效解決軟件内部應用程序出現的問題，測試過程中常将其與黑盒測試方式結合，當測試軟件功能較多時，白盒測試法亦可對此類情況展開有效調試。其中，判定測試作為白盒測試法中最為主要的測試程序結構之一，此類程序結構作為對程序邏輯結構的整體實現，對于程序測試而言具有較為重要的作用。此類測試方式針對程序中各類型的代碼進行覆蓋式檢測，覆蓋範圍較廣，适用于多類型程序。實際檢測中，白盒測試法常與黑盒檢測法并用，以動态檢測方式中測試出的未知錯誤為例，首先使用黑盒檢測法，若程序輸入數據與輸出數據相同，則證明内部數據未出現問題，應從代碼方面進行分析，若出現問題則使用白盒測試法，針對軟件内部結構進行分析，直至檢測出問題所在，及時加以修改。 [1]

測試策略

1、單元測試

單元測試即為将整個軟件分解為各個單元，随後對單元進行測試。此類測試策略的優點在于所需分析數據較少，且針對性較強，程序開發者于開發過程中可通過操作經驗明确出現問題的大緻區域，随後針對此類問題對相關單元展開分析，進行問題排查。但需注意的是，某些程序中無具體單元驅動程序，即單個單元無法有效驅動，易出現問題，若針對此類軟件展開測試，需重點注意此類分解單元。

2、集成測試

集成測試與單元測試相反，原理為将部分需測試部分作為整體進行集成，随後針對此類集成部分進行測試。測試要求為此類被測試集成題應具有一定的結構，且屬于非漸增方式集成。對于較大軟件而言，集成測試方式較單元測試方式而言較為繁瑣，多數大型軟件的測試皆采取漸增方式進行測試。漸增測試方式為集成測試方式的衍生，其能夠按照不同次序對軟件進行測試，日常測試中，常将兩類方式進行集成測試，随後按照次序展開選擇。

發展現狀

軟件系統越來越複雜，一個軟件不能夠由單獨的軟件工程師單獨編寫，而是由團隊進行配合，每個人可能隻負責一個模塊，對于全局沒有過多的了解，這時如果運行軟件就會容易産生很多的錯誤。在行業内将這些錯誤叫做BUG。并且每一個軟件工程師都會有思維的死角，自己不容易發現自己編寫出來的錯誤。所以這個時候就需要專門的軟件測試工程師用專業的測試方式來檢查軟件。檢查該軟件是否符合客戶要求的産品設計，是否能夠符合大多數用戶的使用習慣，如果發現異常狀态及時進行處理。軟件市場雖然遠遠沒有達到飽和但是各種各樣功能的軟件也層出不窮競争激烈，對軟件開發的質量要求也是日益增高。

所以軟件測試是由于軟件開發編程行業高度成熟後所形成的産物。從行業的整體成熟度來講，軟件開發行業的整體成熟度更高，人們對軟件開發的理解也更為全面深入。故此通常将軟件測試和軟件開發放在一起做比較。縱然二者都屬于産品研發但通常人們的關注點有所傾斜。所以經常用軟件開發設計工程師的要求來評價軟件測試工程師，僅看到軟件測試和軟件開發相比的弱勢卻看不到優勢。