測試基本理論

軟件工程模型
談起測試學，不得不討論一下軟件工程模型，因為測試學與軟件工程學的發展依依相關，相輔相成。另外對于比較先進的測試理念，測試工程師應該貫穿于軟件工程的整體過程之中。
瀑布模型
這個模型大概是現在最經典的軟件工程模型，業務建模-〉系統分析-〉概要設計-〉詳細設計-〉編碼-〉測試-〉部署。
但是這個模型存在著比較嚴重的問題：
1，不可反復，不適應與需求變更處理：由于瀑布模型從業務建模到部署一脈相承，不可以回復?，F代軟件項目中需求變更是無處不存在的：唯一不變的就是需求變更。而運用這種模型，只要項目需求發生變化，就要打翻重新進行系統分析，概要設計，詳細設計…
2，用戶很難在項目初期了解項目狀態：由于用戶在項目初期很難提出自己的需求，他們有時候也不知道該做些啥？而利用瀑布模型只有到編碼結束，用戶才可以看到正正他們所需要的產品，而初期這些產品往往是他們所了解不全的，需要補充的，客戶往往在這個時期推翻他們的需求，要求另立需求，這樣往往給客戶方，需求方帶來比較麻煩的結果
迭代模型和螺旋模型：
這兩個模型往往在概念上區別不明顯，許多書上將這兩個模型混為一談。其實這兩個模型的思想本質上是一致的。他將客戶的需求按照用戶的重要等級和模塊自身的等級，從最基礎的進行分析，設計，編碼，測試，然后再進入下一輪迭代。這樣用戶可以在每一輪結束就可以看到產品的一些雛形，進行需求變更和下一輪的建議，由于初期開發工作比較少，用戶又可以在產品初期提出相對可觀的下一輪的需求，所以這樣的模型往往利于現在軟件公司產品的開發，著名的RUP工具每一項都遵循迭代的思想。
測試模型
V模型
²       單元測試相對于編碼進行，這一步往往由測試人員來執行；
²       集成測試相對于詳細設計，他將模塊由上到下，由下到上進行逐步的集成。以測試模塊與模塊，類與類之間的關聯性；
²       系統測試是相對于總體設計而言的，測試人員站在用戶的角度對系統進行全面的測試工作；
²       接收測試是用戶對產品進行測試，一般分為Alpha測試和Beta測試。Alpha測試一般由公司內部的非技術人員或非參與人員對產品進行的測試；Beta測試往往是指定客戶對公司進行測試，是系統推出市場之前，測試階段推出的第二個版本。
V模型可以運用于瀑布模型和迭代模型
X模型
X模型是將軟件系統分為羅干模塊，對每個模塊進行單元，集成以及系統測試，然后統一對模塊進行集成測試，這種測試方法目前軟件行業處于淘汰趨勢。
前置模型
圖示中所列出的是面向對象的前置模型，其他編成方法的前置模型大小意，就是將測試貫穿于軟件開發的全部過程。在需求，設計和編碼階段對產生的工件進行復審，提出自己的建議和意見。對于前置軟件測試法，bug在軟件前期就可以發現從而降低軟件開發成本。
不利用前置方法的bug曲線。
利用前置方法的bug曲線,bug在開始之前就能夠被發現。
軟件測試方法
  白盒 黑盒 
動態 就是利用KDE的調試功能逐步調試程序，進行測試 就是普通所說的通過人工或者自動方法進行測試 
靜態 即test review 就是對需求，設計工件進行審核 

軟件測試步驟
²       測試計劃
²       書寫測試用例
²       開發測試代碼
²       開展測試工作（往往需要進行幾次輪測包括測試和復測，每次對于測試中的bug，要求開發人員給與明確答復修改完畢，非法bug以及下一版中解決）
²       評估測試
軟件測試類型
1.數據和數據庫完整性測試
在項目名稱中，數據庫和數據庫進程應作為一個子系統來進行測試。在測試這些子系統時，不應將測試對象的用戶界面用作數據的接口。對于數據庫管理系統 (DBMS)，還需要進行深入的研究，以確定可以支持以下測試的工具和技術。
2.功能測試
對測試對象的功能測試應側重于所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。此類測試基于黑盒技術，該技術通過圖形用戶界面 (GUI) 與應用程序進行交互，并對交互的輸出或結果進行分析，以此來核實應用程序及其內部進程。以下為各種應用程序列出了推薦使用的測試概要：
3.UI測試
用戶界面 (UI) 測試用于核實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預期的方式運行，并符合公司或行業的標準。包括用戶友好性，人性化測試。
4.性能測試
4.1負載測試：
負載測試是一種性能測試。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。
4.2強度測試
是一種性能測試，實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫鎖或網絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。
4.3容量測試
容量測試使測試對象處理大量的數據，以確定是否達到了將使軟件發生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。例如，如果測試對象正在為生成一份報表而處理一組數據庫記錄，那么容量測試就會使用一個大型的測試數據庫，檢驗該軟件是否正常運行并生成了正確的報表。
4.4基準測試
與已知系統的比較
4.5競爭測試
軟件競爭使用各種資源（數據紀錄，內存等）
5. 安全性和訪問控制測試
安全性和訪問控制測試側重于安全性的兩個關鍵方面：
應用程序級別的安全性，包括對數據或業務功能的訪問
系統級別的安全性，包括對系統的登錄或遠程訪問。
應用程序級別的安全性可確保：在預期的安全性情況下，主角只能訪問特定的功能或用例，或者只能訪問有限的數據。例如，可能會允許所有人輸入數據，創建新賬戶，但只有管理員才能刪除這些數據或賬戶。如果具有數據級別的安全性，測試就可確?！坝脩纛愋鸵弧蹦軌蚩吹剿锌蛻粝ⅲòㄘ攧諗祿?，而“用戶二”只能看見同一客戶的統計數據。
系統級別的安全性可確保只有具備系統訪問權限的用戶才能訪問應用程序，而且只能通過相應的網關來訪問。
6.故障轉移和恢復測試
可確保測試對象能成功完成故障轉移，并能從導致意外數據損失或數據完整性破壞的各種硬件、軟件或網絡故障中恢復。 
故障轉移測試可確保：對于必須持續運行的系統，一旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統，以避免丟失任何數據或事務。
恢復測試是一種對抗性的測試過程。在這種測試中，將把應用程序或系統置于極端的條件下（或者是模擬的極端條件下），以產生故障（例如設備輸入/輸出 (I/O) 故障或無效的數據庫指針和關健字）。然后調用恢復進程并監測和檢查應用程序和系統，核實應用程序或系統和數據已得到了正確的恢復。
7.配置測試
配置測試核實測試對象在不同的軟件和硬件配置中的運行情況。在大多數生產環境中，客戶機工作站、網絡連接和數據庫服務器的具體硬件規格會有所不同?？蛻魴C工作站可能會安裝不同的軟件例如，應用程序、驅動程序等而且在任何時候，都可能運行許多不同的軟件組合，從而占用不同的資源。（如瀏覽器版本。OS版本等）
8.安裝測試
安裝測試有兩個目的。第一個目的是確保該軟件在正常情況和異常情況的不同條件下: 例如，進行首次安裝、升級、完整的或自定義的安裝_都能進行安裝。異常情況包括磁盤空間不足、缺少目錄創建權限等。第二個目的是核實軟件在安裝后可立即正常運行。這通常是指運行大量為功能測試制定的測試。
 
10.本地化測試
又稱本地化測試，是指為各個地方開發產品的測試，如英文版，中文版等等，包括程序是否能夠正常運行，界面是否符合當地習俗，快捷鍵是否正常起作用等等，特別測試在A語言環境下運行B語言軟件（比如在英文win98下試圖運行中文版的程序），出現現象是否正常。
11.文字測試
測試文字是否拼寫正確，是否易懂，不存在二義性，沒有語法錯誤；文字與內容是否由出入等等，包括圖片文字
12.分辨率測試
測試在不同分辨率下，界面的美觀程度,分為800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字體下測試
13發布測試
主要在產品發布前對一些附帶產品，比如說明書，廣告稿等進行測試
13.1說明書測試
主要為語言檢查，功能檢查，圖片檢查
語言檢查：檢查說明書語言是否正確，用詞是否易于理解；
功能檢查：功能是否描述完全，或者描述了并沒有的功能等；
圖片檢查:：檢查圖片是否正確
13.2宣傳材料測試
主要測試產品中的附帶的宣傳材料中的語言，描述功能，圖片
13.3幫助文件測試
幫助文件是否正確，易懂，是否人性化
13.4廣告用語
產品出公司前的廣告材料文字，功能，圖片，人性化的檢查
軟件測試曲線
大家都知道軟件的bug是不可能為零的，它一般隨著時間的推移bug數逼近于零，用一個曲線圖表示：
這里橫坐標是時間，縱坐標是還沒有發現的bugs數。項目開始之前bug為無窮大，隨著時間的推移，bug趨于零但是不會等于零。
由于bug不會等于零，難道產品就不發布了嗎？還有一種bug可以確定產品發布時間。
橫坐標為時間，縱坐標是已經發現的bugs數，當這個曲線趨于平穩，也就是說它的斜率趨于零的時候，這個產品就可以發布了。
軟件的殺蟲劑現象
由于測試人員的思路不盡相同，每個人測試的側重點不同，由于都按照測試用例進行測試，但是測試用例一般僅描述系統的一些基本測試項，不會將所有的測試用例方方面面都寫到，有時還需要測試人員的經驗和素質。所以A測試某個產品用了七個工作日，第一天到第四天報出許多bug,但從第五天開始幾乎報不出啥bug了。七天后換了B,B一下子又測試出一堆bug,不能說A的水平差，只能說，該產品已經對A產生了抗藥性，這就是測試學中的殺蟲劑現象。用圖表示：
所以在測試中每次輪流測試最好安排不同的測試人員進行不同模塊測試工作，以避免殺蟲劑現象產生。

 

【作者介紹】 Jerry

97年畢業于北京某高校計算級專業，先后在軟件公司和網絡公司從事軟件開發，系統分析和設計工作。2001年涉及軟件質量保證，先后擔任測試工程師，測試部經理，副經理。精通軟件工程和測試流程，精通RUP, CMM, ISO, 6SIGMA軟件質量保證工作。
作者Email地址：xianggu@yahoo.com

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