評論(0

軟體測試方法

標籤: 暫無標籤

1 軟體測試方法 -引言

  隨著軟體測試技術的不斷發展,測試方法也越來越多樣化,針對性更強;選擇合適的可以讓我們事半功倍。以下介紹一些常用的軟體測試方法。

2 軟體測試方法 -β測試_Beta測試

  β測試,英文是Beta testing。又稱Beta測試,用戶驗收測試(UAT)。

  β測試是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場,Beta測試不能由程序員或測試員完成。

  當開發和測試根本完成時所做的測試,而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員完成,不能由程序員或測試員完成。

3 軟體測試方法 -α測試_Alpha測試

  α測試,英文是Alpha testing。又稱Alpha測試.

  Alpha測試是由一個用戶在開發環境下進行的測試,也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試,Alpha測試不能由該系統的程序員或測試員完成。

  在系統開發接近完成時對應用系統的測試;測試后,仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員來完成,不能由程序員或測試員完成。

4 軟體測試方法 -可移植性測試

  可移植性測試,英文是Portability testing。又稱兼容性測試。

  可移植性測試是指測試軟體是否可以被成功移植到指定的硬體或軟體平台上。

5 軟體測試方法 -用戶界面測試-UI測試

  用戶界面測試,英文是User interface testing。又稱UI測試。

  用戶界面,英文是User interface。是指軟體中的可見外觀及其底層與用戶交互的部分(菜單、對話框、窗口和其它控制項)。

  用戶界面測試是指測試用戶界面的風格是否滿足客戶要求,文字是否正確,頁面是否美觀,文字,圖片組合是否完美,操作是否友好等等。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操作性測試。

  用戶界面測試用戶分析軟體用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單,對話框及對話框上所有按鈕,文字,出錯提示,幫助信息 (Menu 和Help content)等方面的測試。比如,測試Microsoft Excel中插入符號功能所用的對話框的大小,所有按鈕是否對齊,字元串字體大小,出錯信息內容和字體大小,工具欄位置/圖標等等。

6 軟體測試方法 -冒煙測試

  冒煙測試,英文是Smoke testing。

  冒煙測試的名稱可以理解為該種測試耗時短,僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路板功基本功能檢查。任何新電路板焊好后,先通電檢查,如果存在設計缺陷,電路板可能會短路,板子冒煙了。

  冒煙測試的對象是每一個新編譯的需要正式測試的軟體版本,目的是確認軟體基本功能正常,可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。

7 軟體測試方法 -隨機測試

  隨機測試,英文是Ad hoc testing。

  隨機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟體進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段,是保證測試覆蓋完整性的有效方式和過程。

  隨機測試主要是對被測軟體的一些重要功能進行複測,也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外,對於軟體更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、併發性、進行檢查。尤其對以前測試發現的重大Bug,進行再次測試,可以結合回歸測試 (Regressive testing)一起進行。

8 軟體測試方法 -本地化測試

  本地化測試,英文是Localization testing。

  本地化就是將軟體版本語言進行更改,比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟體的本地化版本。本地化測試的目的是測試特定目標區域設置的軟體本地化質量。本地化測試的環境是在本地化的操作系統上安裝本地化的軟體。從測試方法上可以分為基本功能測試,安裝/卸載測試,當地區域的軟硬體兼容性測試。測試的內容主要包括軟體本地化后的界面布局和軟體翻譯的語言質量,包含軟體、文檔和聯機幫助等部分。

9 軟體測試方法 -本地化能力測試

本地化能力測試,英文是Localizability testing。

  本地化能力測試是指不需要重新設計或修改代碼,將程序的用戶界面翻譯成任何目標語言的能力。為了降低本地化能力測試的成本,提高測試效率,本地化能力測試通常在軟體的偽本地化版本上進行。

  本地化能力測試中發現的典型錯誤包括:字元的硬編碼(即軟體中需要本地化的字元寫在了代碼內部),對需要本地化的字元長度設置了固定值,在軟體運行時以控制項位置定位,圖標和點陣圖中包含了需要本地化的文本,軟體的用戶界面與文檔術語不一致等。

10 軟體測試方法 -國際化測試

  國際化測試,英文是International testing。又稱國際化支持測試。

  國際化測試的目的是測試軟體的國際化支持能力,發現軟體的國際化的潛在問題,保證軟體在世界不同區域都能正常運行。國際化測試使用每種可能的國際輸入類型,針對任何區域性或區域設置檢查產品的功能是否正常,軟體國際化測試的重點在於執行國際字元串的輸入/輸出功能。國際化測試數據必須包含東亞語言、德語、複雜腳本字元和英語(可選)的混合字元。

  國際化支持測試是指驗證軟體程序在不同國家或區域的平台上也能夠如預期的那樣運行,而且還可以按照原設計尊重和支持使用當地常用的日期,字體,文字表示,特殊格式等等。比如,用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字元串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字元串?又比如,日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執行國際化支持測試的測試人員往往需要基本上了解這些國家或地區的語言要求和期望行為是什麼。

11 軟體測試方法 -安裝測試

  安裝測試,英文是Installing testing。

  安裝測試是確保軟體在正常情況和異常情況下,例如,進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁碟空間不足、缺少目錄創建許可權等場景。核實軟體在安裝后可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝,安裝代碼提供安裝一些程序能夠運行的基礎數據。

12 軟體測試方法 -白盒測試

  白盒測試,英文是White Box Testing。又稱結構測試或者邏輯驅動測試。

  白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動態測試時,需要測試軟體產品的內部結構和處理過程,不需測試軟體產品的功能。

  白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。

  白盒測試是知道產品內部工作過程,可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行,按照程序內部的結構測試程序,檢驗程序中的每條通路是否都有能按預定要求正確工作,而不顧它的功能,白盒測試的主要方法有邏輯驅動、基路測試等,主要用於軟體驗證。

  白盒測試常用工具有:jtest、VcSmith、Jcontract、C++ Test、CodeWizard、Logiscope。

13 軟體測試方法 -黑盒測試

  黑盒測試,英文是Black Box Testing。又稱功能測試或者數據驅動測試。

  黑盒測試是根據軟體的規格對軟體進行的測試,這類測試不考慮軟體內部的運作原理,因此軟體對用戶來說就像一個黑盒子。

軟體測試人員以用戶的角度,通過各種輸入和觀察軟體的各種輸出結果來發現軟體存在的缺陷,而不關心程序具體如何實現的一種軟體測試方法。

  黑盒測試常用工具有:AutoRunner、winrunner、loadrunner。

14 軟體測試方法 -自動化測試

  自動化測試,英文是Automated Testing。

  使用自動化測試工具來進行測試,這類測試一般不需要人干預,通常在GUI、性能等測試和功能測試中用得較多。通過錄製測試腳本,然後執行這個測試腳本來實現測試過程的自動化。國內領先的自動化測試服務提供商是澤眾軟體。自動化測試工具有AutoRunner和TAR等。

15 軟體測試方法 -回歸測試

  回歸測試,英文是Regression testing。

  回歸測試是指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上,軟體產生新版本,都需要進行回歸測試,驗證以前發現和修復的錯誤是否在新軟體版本上再次出現。

  根據修復好了的缺陷再重新進行測試。回歸測試的目的在於驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。通常確定所需的再測試的範圍時是比較困難的,特別當臨近產品發布日期時。因為為了修正某缺陷時必需更改源代碼,因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現時的步驟重新測試,而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化測試。

16 軟體測試方法 -驗收測試

  驗收測試,英文是Acceptance testing。

  驗收測試是指系統開發生命周期方法論的一個階段,這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。

  驗收測試一般有三種策略:正式驗收、非正式驗收或Alpha 測試、Beta 測試。

17 軟體測試方法 -動態測試

  動態測試,英文是Moment Testing。

  動態測試是指通過運行軟體來檢驗軟體的動態行為和運行結果的正確性。

  根據動態測試在軟體開發過程中所處的階段和作用,動態測試可分為如下幾個步驟:

  1、單元測試

  2、集成測試

  3、系統測試

  4、驗收測試

  5、回歸測試

18 軟體測試方法 -探索測試

  探索測試,英文是Exploratory Testing。

  探索測試是指通常用於沒有產品說明書的測試,這需要把軟體當作產品說明書來看待,分步驟逐項探索軟體特性,記錄軟體執行情況,詳細描述功能,綜合利用靜態和動態技術來進行測試。探索測試人員只靠智能、洞察力和經驗來對bug的位置進行判斷,所以探索測試又被稱為自由形式測試。

19 軟體測試方法 -單元測試

  單元測試,英文是Unit Testing。

  單元測試是最微小規模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做,因為它需要知道內部程序設計和編碼的細節知識。這個工作不容易做好,除非應用系統有一個設計很好的體系結構; 還可能需要開發測試驅動器模塊或測試套具。

20 軟體測試方法 -集成測試

  集成測試,英文是Integration Testing。

  集成測試是指一個應用系統的各個部件的聯合測試,以決定他們能否在一起共同工作並沒有衝突。部件可以是代碼塊、獨立的應用、網路上的客戶端或伺服器端程序。這種類型的測試尤其與客戶伺服器和分散式系統有關。一般集成測試以前,單元測試需要完成。

  集成測試是單元測試的邏輯擴展。它的最簡單的形式是:兩個已經測試過的單元組合成一個組件,並且測試它們之間的介面。從這一層意義上講,組件是指多個單元的集成聚合。在現實方案中,許多單元組合成組件,而這些組件又聚合成程序的更大部分。方法是測試片段的組合,並最終擴展進程,將您的模塊與其他組的模塊一起測試。最後,將構成進程的所有模塊一起測試。此外,如果程序由多個進程組成,應該成對測試它們,而不是同時測試所有進程。

  集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元,並確保每個單元的生存能力的測試計劃,可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析級別

21 軟體測試方法 -系統測試

  系統測試,英文是System Testing。

  系統測試是基於系統整體需求說明書的黑盒類測試,應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試,目的是驗證系統是否滿足了需求規格的定義,找出與需求規格不相符合或與之矛盾的地方。

  系統測試的對象不僅僅包括需要測試的產品系統的軟體,還要包含軟體所依賴的硬體、外設甚至包括某些數據、某些支持軟體及其介面等。因此,必須將系統中的軟體與各種依賴的資源結合起來,在系統實際運行環境下來進行測試。

22 軟體測試方法 -端到端測試

  端到端測試,英文是End to End Testing。

  端到端測試類似於系統測試,測試級的「宏大」的端點,涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。例如與資料庫對話,用網路通訊,或與外部硬體、應用系統或適當的系統對話。端到端架構測試包含所有訪問點的功能測試及性能測試。端到端架構測試實質上是一種"灰盒"測試,一種集合了白盒測試和黑盒測試的優點的測試方法。

23 軟體測試方法 -健全測試

  健全測試,英文是Sanity testing。

  健全測試是指一個初始化的測試工作,以決定一個新的軟體版本測試是否足以執行下一步大的測試能力。例如,如果一個新版軟體每5分鐘與系統衝突,使系統陷於泥潭,說明該軟體不夠「健全」,目前不具備進一步測試的條件。

24 軟體測試方法 -衰竭測試

  衰竭測試,英文是Failure Testing。

  衰竭測試是指軟體或環境的修復或更正後的「再測試」。可能很難確定需要多少遍再次測試。尤其在接近開發周期結束時。自動測試工具對這類測試尤其有用。

25 軟體測試方法 -接受測試

  接受測試,英文是Accept Testing。

  接受測試是基於客戶或最終用戶的規格書的最終測試,或基於用戶一段時間的使用后,看軟體是否滿足客戶要求。一般從功能、用戶界面、性能、業務關聯性進行測試。

26 軟體測試方法 -負載測試

  負載測試,英文是Load testing。

  負載測試是測試一個應用在重負荷下的表現。例如測試一個 Web 站點在大量的負荷下,何時系統的響應會退化或失敗,以發現設計上的錯誤或驗證系統的負載能力。在這種測試中,將使測試對象承擔不同的工作量,以評測和評估測試對象在不同工作量條件下的性能行為,以及持續正常運行的能力。

  負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外,負載測試還要評估性能特徵,例如,響應時間、事務處理速率和其他與時間相關的方面。

27 軟體測試方法 -強迫測試

  強迫測試,英文是Force Testing。

  強迫測試是在交替進行負荷和性能測試時常用的術語。也用於描述象在異乎尋常的重載下的系統功能測試之類的測試,如某個動作或輸入大量的重複,大量數據的輸入,對一個資料庫系統大量的複雜查詢等。

28 軟體測試方法 -壓力測試

  壓力測試,英文是Stress testing。和負載測試差不多。

  壓力測試是一種基本的質量保證行為,它是每個重要軟體測試工作的一部分。壓力測試的基本思路很簡單:不是在常規條件下運行手動或自動測試,而是在計算機數量較少或系統資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內部內存、CPU 可用性、磁碟空間和網路帶寬等。一般用併發來做壓力測試。

29 軟體測試方法 -性能測試

  性能測試,英文是Performance Testing。

  性能測試是在交替進行負荷和強迫測試時常用的術語。理想的「性能測試」(和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。

  通常驗證軟體的性能在正常環境和系統條件下重複使用是否還能滿足性能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會流失(memory leak)。比如,驗證程序保存一個巨大的文件新版本不比舊版本慢。

30 軟體測試方法 -可用性測試

  可用性測試,英文是Practical Usability Testing。

  可用性測試是對「用戶友好性」的測試。顯然這是主觀的,且將取決於目標最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其他一些技術都可使用。程序員和測試員通常都不宜作可用性測試員。

31 軟體測試方法 -卸載測試

  卸載測試,英文是Uninstall Testing。

  卸載測試是對軟體的全部、部分或升級卸載處理過程的測試。主要是測試軟體能否卸載,卸載是否乾淨,對系統有無更改,在系統中的殘留與後來的生成文件如何處理等。還有原來更改的系統值是否修改回去

32 軟體測試方法 -恢複測試

  恢複測試,英文是Recovery testing。

  恢複測試是測試一個系統從如下災難中能否很好地恢復,如遇到系統崩潰、硬體損壞或其他災難性問題。恢複測試指通過人為的讓軟體(或者硬體)出現故障來檢測系統是否能正確的恢復,通常關注恢復所需的時間以及恢復的程度。

  恢複測試主要檢查系統的容錯能力。當系統出錯時,能否在指定時間間隔內修正錯誤並重新啟動系統。恢複測試首先要採用各種辦法強迫系統失敗,然後驗證系統是否能儘快恢復。對於自動恢復需驗證重新初始化(reinitialization)、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性;對於人工干預的恢復系統,還需估測平均修復時間,確定其是否在可接受的範圍內。

33 軟體測試方法 -安全測試

  安全測試,英文是Security Testing。

  安全測試是測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。安全測試檢查系統對非法侵入的防範能力。安全測試期間,測試人員假扮非法入侵者,採用各種辦法試圖突破防線。例如:

  ①想方設法截取或破譯口令;

  ②專門定做軟體破壞系統的保護機制;

  ③故意導致系統失敗,企圖趁恢復之機非法進入;

  ④試圖通過瀏覽非保密數據,推導所需信息,等等。理論上講,只要有足夠的時間和資源,沒有不可進入的系統。因此系統安全設計的準則是,使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。

34 軟體測試方法 -兼容性測試

  兼容測試,英文是Compatibility Testing。

  兼容測試是測試軟體在一個特定的硬體/軟體/操作系統/網路等環境下的性能如何。向上兼容向下兼容,軟體兼容硬體兼容。軟體的兼容性有很多需要考慮的地方。

35 軟體測試方法 -比較測試

  比較測試,英文是Compare Testing。

  比較測試是指與競爭夥伴的產品的比較測試,如軟體的弱點、優點或實力。來取長補短,以增強產品的競爭力。

36 軟體測試方法 -可接受性測試

  可接受性測試,英文是Acceptability Testing。

  可接受性測試是在把測試的版本交付測試部門大範圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大範圍測試以前應該先驗證該版本對於所測試的功能基本上比較穩定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證,就應該阻攔測試部門花時間在該測試版本上測試。同時還要找到造成該版本不穩定的主要缺陷並督促儘快加以修正

37 軟體測試方法 -邊界條件測試

邊界條件測試,英文是Boudary Testing。又稱邊界值測試。

  一種黑盒測試方法,適度等價類分析方法的一種補充,由長期的測試工作經驗得知,大量的錯誤是發生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試用例,可以查出更多的錯誤。

  邊界條件測試是環繞邊界值的測試。通常意味著測試軟體各功能是否能正確處理最大值,最小值或者所設計軟體能夠處理的最長的字元串等等。

38 軟體測試方法 -強力測試

  強力測試,英文是Mightiness Testing。

  強力測試通常驗證軟體的性能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟體的性能在各種極端環境和系統條件下的承受能力。比如,在最低的硬碟驅動器空間或系統記憶容量條件下,驗證程序重複執行打開和保存一個巨大的文件1000次后也不會崩潰或死機。

39 軟體測試方法 -裝配/安裝/配置測試

  裝配/安裝/配置測試是驗證軟體程序在不同廠家的硬體上,所支持的不同語言的新舊版本平台上,和不同方式安裝的軟體都能夠如預期的那樣正確運行。比如,把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上,再驗證所有功能都正常運行。

40 軟體測試方法 -靜態測試

  靜態測試,英文是Static Testing。

  靜態測試指測試不運行的部分,例如測試產品說明書,對此進行檢查和審閱.。靜態方法是指不運行被測程序本身,僅通過分析或檢查源程序的文法、結構、過程、介面等來檢查程序的正確性。靜態方法通過程序靜態特性的分析,找出欠缺和可疑之處,例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變數、空指針的引用和可疑的計算等。靜態測試結果可用於進一步的查錯,並為測試用例選取提供指導。

  靜態測試常用工具有:Logiscope、PRQA;

41 軟體測試方法 -隱藏數據測試

  隱藏數據測試在軟體驗收和確認階段是十分必要和重要的一部分。程序的質量不僅僅通過用戶界面的可視化數據來驗證,而且必須包括遍歷系統的所有數據。

  假設一個應用程序要求用戶兩條信息-----用戶名和密碼來創建帳戶。這個用戶輸入這兩條數據后保存。最後,一個確認窗口將通過資料庫中找到這條數據來顯示用戶名和密碼給用戶。為了驗證所有的數據保存是否正確,一個QA測試人員會在這個確認窗口簡單的查看下用戶名和密碼。如果他們成功了?假設資料庫記錄了第三條信息----創建日期,它可能不會出現在確認窗口,而只在存檔中才出現。如果創建日期保留的不正確,而QA測試人員只驗證屏幕上的數據,那麼這個問題就不可能被發現。創建日期可能就是一個bug,由於一個用戶帳戶保存了一個錯誤的日期到資料庫中,這個問題也不可能會被引起注意,因為它被用戶界面所隱藏。這只是一個簡單的例子,但是它卻演化出了一點:隱藏數據測試的重要性。

42 軟體測試方法 -等價劃分測試

  等價劃分測試的英文是equivalence partition testing。

  等價劃分測試是根據等價類設計測試用例的一種技術。是黑盒測試的典型方法之一,通過把被測試程序所有可能的輸入數據域劃分成若干部分。從每一部分中選取少數有代表性的數據作為測試用例,可有效減少測試次數,極大提高軟體測試效率,縮短軟體開發周期.等價類劃分測試的目的就是為了在有限的測試資源的情況下,用少量有代表性的數據得到比較好的測試效果。有效等價類盒無效等價類。有效等價類中的數據代表的是一組符合需求文檔的正確的有意義數據。無效等價類則正相反。

43 軟體測試方法 -判定表

  判定表的英文是decision table,是指一個表格,用於顯示條件和條件導致動作的集合。

  定義:判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

  判定表的優點:能夠將複雜的問題按照各種可能的情況全部列舉出來,簡明並避免遺漏。因此,利用判定表能夠設計出完整的測試用例集合。

  在一些數據處理問題當中,某些操作的實施依賴於多個邏輯條件的組合,即:針對不同邏輯條件的組合值,分別執行不同的操作。判定表很適合於處理這類問題

44 軟體測試方法 -深度測試

  深度測試的英文Depth test ,是指執行一個產品的一個特性的所有細節,但不測試所有特性。

  當比較函數返回真的時候才顯示出效果來。必須啟用「#深度測試」,才能執行測試。不使用的時候需要關閉。

45 軟體測試方法 -基於設計的測試

  基於設計的測試的英文是design-based testing,是根據軟體的構架或詳細設計引出測試用例的一種方法。

  一種基於設計模型的測試方法(Model Based TestIng System,MATIS).該方法利用用戶界面自動生成方法,把設計模型中的類屬性定義和實現中的控制項屬性組織在一起,構建描述界面的邏輯對照表,輔助測試腳本引擎執行自動測試腳本.藉助設計模型中擴展的類定義,MATIS方法可以自動生成測試用例和測試數據。

46 軟體測試方法 -文檔測試

  文檔測試的英文是documentation testing,測試關注於文檔的正確性。

  文檔測試有三大類分別是開發文件、用戶文件、管理文件。

  1. 開發文件:可行性研究報告、軟體需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、模塊開發卷宗。

  2.用戶文件:用戶手冊、操作手冊。

  3.管理文件:項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。

  軟體測試中的文檔測試主要是對相關的設計報告和用戶使用說明進行測試,對於設計報告主要是測試程序與設計報告中的設計思想是否一致;對於用戶使用說明進行測試時,主要是測試用戶使用說明書中對程序操作方法的描述是否正確,重點是用戶使用說明中提到的操作例子要進行測試,保證採用的例子能夠在程序中正確完成操作。

  一般來識,文檔是軟體的重要組成部分,因此文檔測試也是軟體測試的主要內容。在軟體的整個生命周期中會出現很多文檔,通常可以把文檔粗略地分為三類:開發文檔,管理文檔和用戶文檔。

  由於文檔與代碼不同,不能直接運行,對於文檔的測試通常只能以文檔審查的方式進行。對於管理文檔和審查通常歸屬於管理範疇,而不是軟體測試範疇,因為對於管理文檔審查的目的不是為了發現和消除用戶所看到的軟體中的缺陷,而是為了更好地管理軟體開發的過程。對於開發文檔,由於這些文檔本身體現了所在開發階段的軟體實際形態,對於這些文檔的測試實際上是早期軟體測試的主要活動。用戶文檔是那些隨程序一起交付給用戶的文檔,它們實際上是交付給用戶的軟體的重要組成部分。對於這些文檔的測試是對最終軟體產品測試的一部分。

47 軟體測試方法 -域測試

  域測試的英文是domain testing,定義參考等價劃分測試(equivalence partition testing);

  一般分為單域測試和多域測試,其中單域測試包括設備測試和業務測試,設備測試包括測試某個系統的軟交換設備、中繼媒體網關設備、信令網關設備、接入媒體網關和IAD等設備。

  等價類劃分有兩種不同的情況:有效等價類和無效等價類。設計時要同時考慮這兩種等價類,因為軟體不僅要能接收合理的數據,也要能經受意外的考驗。

  一有效等價類:是指對於程序的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。

  二無效等價類:與有效等價類的定義恰巧相反。

48 軟體測試方法 -介面測試

  介面測試的英文是interface testing,介面測試測試系統組件間介面的一種測試。

  介面測試的好處:

  由於介面測試代碼本身就是用junit(當然介面的類型不同,不一定是Junit來實現)來實現的,是屬於自動化測試的範疇,因此必定也包含自動化測試所固有的優勢。

  1) 提高測試質量

  軟體開發的過程是一個持續集成和改進的過程,而每一次的改進都可能引進新bug,因此當軟體的一部,或者全部修改時,都需要對軟體產品重新進行測試。其目的是要驗證修改後的產品是符合需求的,而當沒有自動化測試代碼時,往往會由於各種各樣的原因,回歸不充分,導致bug遺漏。

  2) 提高測試效率

  軟體系統的規模越來越大,功能點越來越多,開發人員的自測或者測試人員的人工測試非常耗時和繁瑣,勢必導致測試效率的低下,而自動化測試正好解決這些耗時繁瑣的任務,在對外介面功能不變的情況下,達到了一次編寫,永久使用的效果。

  3) 提高測試覆蓋

  通過手工測試很難測試到一些更深層次的異常和安全的問題,通過一些輔助的一些測試工具,能分析出代碼的覆蓋率,通過覆蓋率的提高來提高測試的深度。

  4) 更好地重現軟體缺陷

  由於每次執行都是相同的代碼,一旦代碼出錯,必定回歸出錯

  5) 更好定位錯誤

  由於介面測試是一種自下向上的測試,因此一量出錯,非常容易定位出錯,不向系統測試那樣了,一旦有Bug,需要幾層驗證之後才能確定出錯位置

  6) 降低修改bug的成本介面測試基本和開發人員的編碼平行工作,因此發現問題會比系統測試早很多,因此減少了修改bug的成本。

  7) 增進測試人員和開發人員之間的合作關係,測試工程師為了更好地開展工作,需要對開發技術有深入的理解和實踐,有了與開發工程師更多的交流。

  8) 降低了項目不能按時發布的風險由於介面測試很早就介入,在提交給系統測試前對項目代碼的核心模塊已經做了詳盡的測試,必定加速系統測試的時間,由此來保證項目的按時發布。

  9)提升測試人員的技能。做介面測試必須了解開發人員的開發流程和一些開發技能,也需要了解測試工具的一些使用方法和一些測試思想,提升了測試人員的技術附加值,提高了自身的競爭力。

  10)促使項目開發過程的規範化

  要進行介面,需要完善的文檔進行保障,沒有測試文檔,介面測試將寸步難行,介面測試將增加開發過程規範化產出,而規範化產出也保證了項目質量。

49 軟體測試方法 -逆向測試

  逆向測試/反向測試/負面測試的英文是Negative Testing,測試瞄準於使系統不能工作。

  負面測試與正面測試的比較:

  負面測試(Negative testing)是相對於正面測試(Positive testing)而言的。它們也是測試設計時的兩個非常重要的劃分。簡單點說,正面測試就是測試系統是否完成了它應該完成的工作;而負面測試就是測試系統是否不執行它不應該完成的操作。形象一點,正面測試就象一個畢恭畢敬的小學生,老師叫我做什麼,我就做什麼;而負面測試就象一個調皮搗蛋的孩子,你叫我這樣做,我偏不這樣做,而且和你對著干。開發人員也是最討厭修改此類bug的。

50 軟體測試方法 -非功能性需求測試

  非功能性需求測試的英文是non-functional requirements testing ,是與功能不相關的需求測試,如:性能測試、可用性測試等。

  為什麼非功能性需求很重要?

  在您設計解決方案的過程中滿足功能性需求當然是很重要的。但是,如果沒有考慮非功能性需求,您的解決方案則很難取得實效。

  非功能性需求特點:1.不要脫離實際環境;2.可靠性;3.可用性;4.有效性;5.可維護性;6.可移植性。

51 軟體測試方法 -極限測試] b]

簡介

  極限測試本質上是為了滿足極限測試的思想和流程而設計的一套測試策略和流程,其本身並不局限於使用特定的測試技術和方法。

過程

  1.單元測試

  2.驗收測試

上一篇[自然人流動]  

相關評論

同義詞:暫無同義詞