關于軟件測試的基本常識

關于軟件測試的基本常識      軟件測試

一、軟件測試簡介

為了保證軟件的質量和可靠性，應力求在分析、設計等各個開發階段結束前，對軟件進行嚴格的技術評審。但由于人們能力的局限性，審查不能發現所有的錯誤。而且在編碼階段還會引進大量的錯誤。這些錯誤和缺陷如果遺留到軟件交付投入運行之時，終將會暴露出來。但到那時，不僅改正這些錯誤的代價更高，而且往往造成很惡劣的后果。

    軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。如果給軟件測試下定義，可以這樣講：軟件測試是為了發現錯誤而執行程序的過程?；蛘哒f，軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例(即輸入數據及其預期的輸出結果)，并利用這些測試用例去運行程序，以發現程序錯誤的過程。

    軟件測試在軟件生存期中橫跨兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試(稱為單元測試)。編碼與單元測試屬于軟件生存期中的同一個階段。在結束這個階段之后，對軟件系統還要進行各種綜合測試，這是軟件生存期的另一個獨立的階段，

現在，軟件開發機構將研制力量的40％以上投入到軟件測試之中的事例越來越多。特殊情況下，對于性命攸關的軟件，例如飛行控制、核反應堆監控軟件等，其測試費用甚至高達所有其他軟件工程階段費用總和的3～5倍。

二、 軟件測試的內容

軟件測試主要工作內容是驗證(verification)和確認(validation )，下面分別給出其概念：

　　驗證(verification)是保證軟件正確地實現了一些特定功能的一系列活動，即保證軟件做了你所期望的事情。(Do the right thing)

　　1.確定軟件生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程；

　　2.程序正確性的形式證明，即采用形式理論證明程序符合設計規約規定的過程；

　　3.評市、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規定的需求相一致進行判斷和提出報告。

　　確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do it right)

　　1.靜態確認，不在計算機上實際執行程序，通過人工或程序分析來證明軟件的正確性；

　　2.動態確認，通過執行程序做分析，測試程序的動態行為，以證實軟件是否存在問題。

　　軟件測試的對象不僅僅是程序測試，軟件測試應該包括整個軟件開發期間各個階段所產生的文檔，如需求規格說明、概要設計文檔、詳細設計文檔，當然軟件測試的主要對象還是源程序。

三、軟件測試的對象

軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發的整個期間。因此，需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成為軟件測試的對象。軟件測試不應僅限在程序測試的狹小范圍內，而置其他階段的工作于不顧。

    另一方面，由于定義與開發各階段是互相銜接的，前一階段工作中發生的問題如未及時解決，很自然要影響到下一階段。從源程序的測試中找到的程序錯誤不一定都是程序編寫過程中造成的。如果簡單地把程序中的錯誤全都歸罪于程序員，未免冤枉他們。據美國一家公司的統計表明，在查找出的軟件錯誤中，屬于需求分析和軟件設計的錯誤約占64％0，屬于程序編寫的錯誤僅占36~／／oo。這都說明，對程序編寫而言，它的許多錯誤是“先天的”。事實上，到程序的測試為止，軟件開發工作已經經歷了許多環節，每個環節都可能發生問題。
    
    確認(Validation)是一系列的活動和過程，其目的是想證實在一個給定的外部環境中軟件的邏輯正確性。它包括需求規格說明的確認和程序的確認，而程序的確認又分為靜態確認與動態確認。靜態確認一般不在計算機上實際執行程序，而是通過人工分析或者程序正確性證明來確認程序的正確性；動態確認主要通過動態分析和程序測試來檢查程序的執行狀態，以確認程序是否有問題。
    驗證(Verification)則試圖證明在軟件生存期各個階段，以及階段間的邏輯協調性、完備性和正確性。所示的就是軟件生存期各個重要階段之間所要保持的正確性。它們就確認與驗證工作都屬于軟件測試。在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中，任何一個環節上發生了問題都可能在軟件測試中表現出來。

四、軟件測試的目的和原則

基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。而從軟件開發者的角度出發，則希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。因此，他們會選擇那些導致程序失效概率小的測試用例，回避那些易于暴露程序錯誤的測試用例。同時，也不會著意去檢測、排除程序中可能包含的副作用。

    顯然，這樣的測試對完善和提高軟件質量毫無價值。因為在程序中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把著眼點放在盡可能查找錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運行階段中去。如果站在用戶的角度，替他們設想，就應當把測試活動的目標對準揭露程序中存在的錯誤。在選取測試用例時，考慮那些易于發現程序錯誤的數據。
    有鑒于此，Grenford J．Myers就軟件測試目的提出以下觀點：
    (1)測試是程序的執行過程，目的在于發現錯誤；
    (2)一個好的測試用例在于能發現至今未發現的錯誤；
    (3)一個成功的測試是發現了至今未發現的錯誤的測試。
    測試的目標是想以最少的時間和人力找出軟件中潛在的各種錯誤和缺陷。如果成功地實施了測試，就能夠發現軟件中的錯誤。測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符。此外，實施測試收集到的測試結果數據為可靠性分析提供了依據。
    根據這樣的測試目的，軟件測試的原則應該是：
    (1)應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。
    由于原始問題的復雜性，軟件的復雜性和抽象性，軟件開發各個階段工作的多樣性，以及參加開發各種層次人員之間工作的配合關系等因素，使得開發的每個環節都可能產生錯誤。所以不應把軟件測試僅僅看作是軟件開發的一個獨立階段，而應當把它貫穿到軟件開發的各個階段中。堅持在軟件開發的各個階段的技術評審，這樣才能在開發過程中盡早發現和預防錯
誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質量。
    (2)測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。
    測試以前應當根據測試的要求選擇在測試過程中使用的測試用例(Test case)。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數據，而且需要針對這些輸入數據的預期輸出結果。如果對測試輸入數據沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。
    (3)程序員應避免檢查自己的程序。
    測試工作需要嚴格的作風，客觀的態度和冷靜的情緒。人們常由于各種原因具有一種不愿否定自己工作的心理，認為揭露自己程序中的問題總不是一件愉快的事。這一心理狀態就成為測試自己程序的障礙。另外，程序員對軟件規格說明理解錯誤而引入的錯誤則更難發現。如果由別人來測試程序員編寫的程序，可能會更客觀，更有效，并更容易取得成功。要注意的是，這點不能與程序的調試(debuging)相混淆。調試由程序員自己來做可能更有效。[Page]
    (4)在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。
    合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的，臨界的，可能引起問題異變的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶在鍵盤上按錯了鍵或打入了非法的命令。如果開發的軟件遇到這種情況時不能做出適當的反應，給出相應的信息，那么就容易產生故障，輕則給出錯誤的結果，重則導致軟件失效。因此，軟件系統處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試
程序時，往往比用合理的輸入條件進行測試能發現更多的錯誤。

(5)充分注意測試中的群集現象。
    測試時不要以為找到了幾個錯誤問題就已解決，不需繼續測試了。經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。
    在所測程序段中，若發現錯誤數目多，則殘存錯誤數目也比較多。這種錯誤群集性現象，已為許多程序的測試實踐所證實。例如美國IBM公司的0s／370操作系統中，47 9／6的錯誤僅與該系統的4％的程序模塊有關。這種現象對測試很有用。如果發現某一程序模塊似乎比其他程
序模塊有更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程序模塊。
    (6)嚴格執行測試計劃，排除測試的隨意性。
    測試計劃應包括：所測軟件的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統組裝方式，跟蹤規程，調試規程，以及回歸測試的規定等以及評價標準。
    對于測試計劃，要明確規定，不要隨意解釋。
    (7)應當對每一個測試結果做全面檢查。
    這是一條最明顯的原則，但常常被忽視。有些錯誤的征兆在輸出實測結果時已經明顯地出現了，但是如果不仔細地全面地檢查測試結果，就會使這些錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住征候，暴露錯誤。

(8)妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

原文轉自：http://www.anti-gravitydesign.com