软件测试方法大全
發(fā)布時間: 2009-8-31 12:22??? 作者: 未知??? 來源: 51Testing博客轉(zhuǎn)載
?
β測試_Beta測試
β測試，英文是Beta testing。又稱Beta測試，用戶驗收測試（UAT）。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。
當開發(fā)和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。
?
α測試_Alpha測試
α測試，英文是Alpha testing。又稱Alpha測試.
Alpha測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由該系統(tǒng)的程序員或測試員完成。
在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試;測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。
?
可移植性測試
可移植性測試，英文是Portability testing。又稱兼容性測試。
可移植性測試是指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。
?
用戶界面測試-UI測試
用戶界面測試，英文是User interface testing。又稱UI測試。
用戶界面，英文是User interface。是指軟件中的可見外觀及其底層與用戶交互的部分（菜單、對話框、窗口和其它控件）。
用戶界面測試是指測試用戶界面的風(fēng)格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。確保用戶界面符合公司或行業(yè)的標準。包括用戶友好性、人性化、易操作性測試。
用戶界面測試用戶分析軟件用戶界面的設(shè)計是否合乎用戶期望或要求。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息 (Menu 和Help content)等方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息內(nèi)容和字體大小，工具欄位置/圖標等等。
?
冒煙測試
冒煙測試，英文是Smoke testing。
冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路板功基本功能檢查。任何新電路板焊好后，先通電檢查，如果存在設(shè)計缺陷，電路板可能會短路，板子冒煙了。
冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員。
?
隨機測試
隨機測試，英文是Ad hoc testing。
隨機測試沒有書面測試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測試。主要是根據(jù)測試者的經(jīng)驗對軟件進行功能和性能抽查。隨機測試是根據(jù)測試說明書執(zhí)行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。
隨機測試主要是對被測軟件的一些重要功能進行復(fù)測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進行檢查。尤其對以前測試發(fā)現(xiàn)的重大Bug，進行再次測試，可以結(jié)合回歸測試 (Regressive testing)一起進行。
?
本地化測試
本地化測試，英文是Localization testing。
本地化就是將軟件版本語言進行更改，比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目標區(qū)域設(shè)置的軟件本地化質(zhì)量。本地化測試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟件。從測試方法上可以分為基本功能測試，安裝/卸載測試，當?shù)貐^(qū)域的軟硬件兼容性測試。測試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語言質(zhì)量，包含軟件、文檔和聯(lián)機幫助等部分。
?
本地化能力測試
本地化能力測試，英文是Localizability testing。
本地化能力測試是指不需要重新設(shè)計或修改代碼，將程序的用戶界面翻譯成任何目標語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力側(cè)是通常在軟件的偽本地化版本上進行。
本地化能力測試中發(fā)現(xiàn)的典型錯誤包括：字符的硬編碼（即軟件中需要本地化的字符寫在了代碼內(nèi)部），對需要本地化的字符長度設(shè)置了國定值，在軟件運行時以控件位置定位，圖標和位圖中包含了需要本地化的文本，軟件的用戶界面與文檔術(shù)語不一致等。
?
國際化測試
國際化測試，英文是International testing。又稱國際化支持測試。
國際化測試的目的是測試軟件的國際化支持能力，發(fā)現(xiàn)軟件的國際化的潛在問題，保證軟件在世界不同區(qū)域都能正常運行。國際化測試使用每種可能的國際輸入類型，針對任何區(qū)域性或區(qū)域設(shè)置檢查產(chǎn)品的功能是否正常，軟件國際化測試的重點在于執(zhí)行國際字符串的輸入/輸出功能。國際化測試數(shù)據(jù)必須包含東亞語言、德語、復(fù)雜腳本字符和英語（可選）的混合字符。
國際化支持測試是指驗證軟件程序在不同國家或區(qū)域的平臺上也能夠如預(yù)期的那樣運行，而且還可以按照原設(shè)計尊重和支持使用當?shù)爻Ｓ玫娜掌?#xff0c;字體，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如，日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執(zhí)行國際化支持測試的測試人員往往需要基本上了解這些國家或地區(qū)的語言要求和期望行為是什么。
?
安裝測試
安裝測試，英文是Installing testing。
安裝測試是確保軟件在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等場景。核實軟件在安裝后可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝，安裝代碼提供安裝一些程序能夠運行的基礎(chǔ)數(shù)據(jù)。
?
白盒測試-結(jié)構(gòu)測試-邏輯驅(qū)動測試
?
白盒測試，英文是White Box Testing。又稱結(jié)構(gòu)測試或者邏輯驅(qū)動測試。
白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需測試軟件產(chǎn)品的功能。
白盒測試法的覆蓋標準有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
白盒測試是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。
白盒測試常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。
?
黑盒測試-功能測試-數(shù)據(jù)驅(qū)動測試
黑盒測試，英文是Black Box Testing。又稱功能測試或者數(shù)據(jù)驅(qū)動測試。
黑盒測試是根據(jù)軟件的規(guī)格對軟件進行的測試，這類測試不考慮軟件內(nèi)部的運作原理，因此軟件對用戶來說就像一個黑盒子。
軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種軟件測試方法。
黑盒測試常用工具有：AutoRunner、winrunner、loadrunner。
?
自動化測試
自動化測試，英文是Automated Testing。
使用自動化測試工具來進行測試，這類測試一般不需要人干預(yù)，通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本，然后執(zhí)行這個測試腳本來實現(xiàn)測試過程的自動化。國內(nèi)領(lǐng)先的自動化測試服務(wù)提供商是澤眾軟件。自動化測試工具有AutoRunner和TAR等。
?
回歸測試
回歸測試，英文是Regression testing。
回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，軟件產(chǎn)生新版本，都需要進行回歸測試，驗證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再次出現(xiàn)。
根據(jù)修復(fù)好了的缺陷再重新進行測試?；貧w測試的目的在于驗證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的，特別當臨近產(chǎn)品發(fā)布日期時。因為為了修正某缺陷時必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應(yīng)當鼓勵對所有回歸測試用例進行自動化測試。
?
驗收測試
驗收測試，英文是Acceptance testing。
驗收測試是指系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關(guān)的用戶或獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。
驗收測試一般有三種策略：正式驗收、非正式驗收活A(yù)lpha 測試、Beta 測試。
?
動態(tài)測試
動態(tài)測試，英文是Moment Testing。
動態(tài)測試是指通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。
根據(jù)動態(tài)測試在軟件開發(fā)過程中所處的階段和作用，動態(tài)測試可分為如下幾個步驟：
1、單元測試 2、集成測試
3、系統(tǒng)測試 4、驗收測試
5、回歸測試
?
探索測試
探索測試，英文是Exploratory Testing。
探索測試是指通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說明書來看待，分步驟逐項探索軟件特性，記錄軟件執(zhí)行情況，詳細描述功能，綜合利用靜態(tài)和動態(tài)技術(shù)來進行測試。探索測試人員只靠智能、洞察力和經(jīng)驗來對bug的位置進行判斷,所以探索測試又被稱為自由形式測試。
?
單元測試
單元測試，英文是Unit Testing。
單元測試是最微小規(guī)模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因為它需要知道內(nèi)部程序設(shè)計和編碼的細節(jié)知識。這個工作不容易做好，除非應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu); 還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。
?
集成測試
集成測試，英文是Integration Testing。
集成測試是指一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶服務(wù)器和分布式系統(tǒng)有關(guān)。一般集成測試以前，單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應(yīng)該成對測試它們，而不是同時測試所有進程。
集成測試識別組合單元時出現(xiàn)的問題。通過使用要求在組合單元前測試每個單元，并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發(fā)現(xiàn)的任何錯誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡單的分析級別
?
系統(tǒng)測試
系統(tǒng)測試，英文是System Testing。
系統(tǒng)測試是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。
系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來，在系統(tǒng)實際運行環(huán)境下來進行測試。
?
端到端測試
端到端測試，英文是End to End Testing。
端到端測試類似于系統(tǒng)測試，測試級的“宏大”的端點，涉及整個應(yīng)用系統(tǒng)環(huán)境在一個現(xiàn)實世界使用時的模擬情形的所有測試。例如與數(shù)據(jù)庫對話，用網(wǎng)絡(luò)通訊，或與外部硬件、應(yīng)用系統(tǒng)或適當?shù)南到y(tǒng)對話。端到端架構(gòu)測試包含所有訪問點的功能測試及性能測試。端到端架構(gòu)測試實質(zhì)上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的優(yōu)點的測試方法。
?
健全測試
健全測試，英文是Sanity testing。
健全測試是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執(zhí)行下一步大的測試努力。例如，如果一個新版軟件每5分鐘與系統(tǒng)沖突，使系統(tǒng)陷于泥潭，說明該軟件不夠“健全”，目前不具備進一步測試的條件。
?
衰竭測試
衰竭測試，英文是Failure Testing。
衰竭測試是指軟件或環(huán)境的修復(fù)或更正后的“再測試”?？赡芎茈y確定需要多少遍再次測試。尤其在接近開發(fā)周期結(jié)束時。自動測試工具對這類測試尤其有用。
?
接受測試
接受測試，英文是Accept Testing。
接受測試是基于客戶或最終用戶的規(guī)格書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。一般從功能、用戶界面、性能、業(yè)務(wù)關(guān)聯(lián)性進行測試。
?
負載測試
負載測試，英文是Load testing。
負載測試是測試一個應(yīng)用在重負荷下的表現(xiàn)。例如測試一個 Web 站點在大量的負荷下，何時系統(tǒng)的響應(yīng)會退化或失敗，以發(fā)現(xiàn)設(shè)計上的錯誤或驗證系統(tǒng)的負載能力。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運行的能力。
負載測試的目標是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的方面。
?
強迫測試
強迫測試，英文是Force Testing。
強迫測試是在交替進行負荷和性能測試時常用的術(shù)語。也用于描述象在異乎尋常的重載下的系統(tǒng)功能測試之類的測試，如某個動作或輸入大量的重復(fù)，大量數(shù)據(jù)的輸入，對一個數(shù)據(jù)庫系統(tǒng)大量的復(fù)雜查詢等。
壓力測試
壓力測試，英文是Stress Testing。和負載測試差不多。
壓力測試是一種基本的質(zhì)量保證行為，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規(guī)條件下運行手動或自動測試，而是在計算機數(shù)量較少或系統(tǒng)資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內(nèi)部內(nèi)存、CPU 可用性、磁盤空間和網(wǎng)絡(luò)帶寬等。一般用并發(fā)來做壓力測試。
?
性能測試
性能測試，英文是Performance Testing。
性能測試是在交替進行負荷和強迫測試時常用的術(shù)語。理想的“性能測試”(和其他類型的測試)應(yīng)在需求文檔或質(zhì)量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。
通常驗證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標?；蛘邎?zhí)行同樣任務(wù)時新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運行程序時會不會流失(memory leak)。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。
?
可用性測試
可用性測試，英文是Practical Usability Testing。
可用性測試是對“用戶友好性”的測試。顯然這是主觀的，且將取決于目標最終用戶或客戶。用戶面談、調(diào)查、用戶對話的錄象和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。
?
卸載測試
卸載測試，英文是Uninstall Testing。
卸載測試是對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸載，卸載是否干凈，對系統(tǒng)有無更改，在系統(tǒng)中的殘留與后來的生成文件如何處理等。還有原來更改的系統(tǒng)值是否修改回去
?
恢復(fù)測試
恢復(fù)測試，英文是Recovery testing。
恢復(fù)測試是測試一個系統(tǒng)從如下災(zāi)難中能否很好地恢復(fù)，如遇到系統(tǒng)崩潰、硬件損壞或其他災(zāi)難性問題。恢復(fù)測試指通過人為的讓軟件（或者硬件）出現(xiàn)故障來檢測系統(tǒng)是否能正確的恢復(fù)，通常關(guān)注恢復(fù)所需的時間以及恢復(fù)的程度。
恢復(fù)測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)?；謴?fù)測試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復(fù)。對于自動恢復(fù)需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數(shù)據(jù)恢復(fù)(data recovery)和重新啟動 (restart)等機制的正確性；對于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時間，確定其是否在可接受的范圍內(nèi)。
?
安全測試
安全測試，英文是Security Testing。
安全測試是測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復(fù)雜的測試技術(shù)。安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：
?、傧敕皆O(shè)法截取或破譯口令；
?、趯ｉT定做軟件破壞系統(tǒng)的保護機制；
③故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機非法進入；
?、茉噲D通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
?
兼容性測試
兼容測試，英文是Compatibility Testing。
兼容測試是測試軟件在一個特定的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)等環(huán)境下的性能如何。向上兼容向下兼容，軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。
?
比較測試
比較測試，英文是Compare Testing。
比較測試是指與競爭伙伴的產(chǎn)品的比較測試，如軟件的弱點、優(yōu)點或?qū)嵙?。來取長補短，以增強產(chǎn)品的競爭力。
?
可接受性測試
可接受性測試，英文是Acceptability Testing。
可接受性測試是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應(yīng)該先驗證該版本對于所測試的功能基本上比較穩(wěn)定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應(yīng)該阻攔測試部門花時間在該測試版本上測試。同時還要找到造成該版本不穩(wěn)定的主要缺陷并督促盡快加以修正
?
邊界條件測試
邊界條件測試，英文是Boudary Testing。又稱邊界值測試。
一種黑盒測試方法，適度等價類分析方法的一種補充,由長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。
邊界條件測試是環(huán)繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理最大值，最小值或者所設(shè)計軟件能夠處理的最長的字符串等等。
?
強力測試
強力測試，英文是Mightiness Testing。
強力測試通常驗證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作。或者說是驗證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如，在最低的硬盤驅(qū)動器空間或系統(tǒng)記憶容量條件下，驗證程序重復(fù)執(zhí)行打開和保存一個巨大的文件1000次后也不會崩潰或死機。
?
裝配/安裝/配置測試
裝配/安裝/配置測試是驗證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺上，和不同方式安裝的軟件都能夠如預(yù)期的那樣正確運行。比如，把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上，再驗證所有功能都正常運行。
靜態(tài)測試
靜態(tài)測試，英文是Static Testing。
靜態(tài)測試指測試不運行的部分，例如測試產(chǎn)品說明書，對此進行檢查和審閱.。靜態(tài)方法是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹配的參數(shù)、不適當?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態(tài)測試結(jié)果可用于進一步的查錯，并為測試用例選取提供指導(dǎo)。
靜態(tài)測試常用工具有：Logiscope、PRQA；
?
隱藏數(shù)據(jù)測試
隱藏數(shù)據(jù)測試在軟件驗收和確認階段是十分必要和重要的一部分。程序的質(zhì)量不僅僅通過用戶界面的可視化數(shù)據(jù)來驗證，而且必須包括遍歷系統(tǒng)的所有數(shù)據(jù)。
假設(shè)一個應(yīng)用程序要求用戶兩條信息-----用戶名和密碼來創(chuàng)建帳戶。這個用戶輸入這兩條數(shù)據(jù)后保存。最后，一個確認窗口將通過數(shù)據(jù)庫中找到這條數(shù)據(jù)來顯示用戶名和密碼給用戶。為了驗證所有的數(shù)據(jù)保存是否正確，一個QA測試人員會在這個確認窗口簡單的查看下用戶名和密碼。如果他們成功了？假設(shè)數(shù)據(jù)庫記錄了第三條信息----創(chuàng)建日期，它可能不會出現(xiàn)在確認窗口，而只在存檔中才出現(xiàn)。如果創(chuàng)建日期保留的不正確，而QA測試人員只驗證屏幕上的數(shù)據(jù)，那么這個問題就不可能被發(fā)現(xiàn)。創(chuàng)建日期可能就是一個bug，由于一個用戶帳戶保存了一個錯誤的日期到數(shù)據(jù)庫中，這個問題也不可能會被引起注意，因為它被用戶界面所隱藏。這只是一個簡單的例子，但是它卻演化出了一點：隱藏數(shù)據(jù)測試的重要性。
等價劃分測試
等價劃分測試的英文是equivalence partition testing。
等價劃分測試是根據(jù)等價類設(shè)計測試用例的一種技術(shù)。是黑盒測試的典型方法之一，通過把被測試程序所有可能的輸入數(shù)據(jù)域劃分成若干部分。從每一部分中選取少數(shù)有代表性的數(shù)據(jù)作為測試用例，可有效減少測試次數(shù)，極大提高軟件測試效率，縮短軟件開發(fā)周期．等價類劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的數(shù)據(jù)得到比較好的測試效果。有效等價類盒無效等價類。有效等價類中的數(shù)據(jù)代表的是一組符合需求文檔的正確的有意義數(shù)據(jù)。無效等價類則正相反。
?
判定表
判定表的英文是decision table，是指一個表格，用于顯示條件和條件導(dǎo)致動作的集合。
定義：判定表是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具。
判定表的優(yōu)點：能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設(shè)計出完整的測試用例集合。
在一些數(shù)據(jù)處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執(zhí)行不同的操作。判定表很適合于處理這類問題
?
深度測試
深度測試的英文Depth test ，是指執(zhí)行一個產(chǎn)品的一個特性的所有細節(jié)，但不測試所有特性。
當比較函數(shù)返回真的時候才顯示出效果來。必須啟用“#深度測試”，才能執(zhí)行測試。不使用的時候需要關(guān)閉。
?
基于設(shè)計的測試
基于設(shè)計的測試的英文是design-based testing，是根據(jù)軟件的構(gòu)架或詳細設(shè)計引出測試用例的一種方法。
一種基于設(shè)計模型的測試方法(Model Based? TestIng System,MATIS).該方法利用用戶界面自動生成方法,把設(shè)計模型中的類屬性定義和實現(xiàn)中的控件屬性組織在一起,構(gòu)建描述界面的邏輯對照表,輔助測試腳本引擎執(zhí)行自動測試腳本.借助設(shè)計模型中擴展的類定義,MATIS方法可以自動生成測試用例和測試數(shù)據(jù)。
?
文檔測試
文檔測試的英文是documentation testing，測試關(guān)注于文檔的正確性。
文檔測試有三大類分別是開發(fā)文件、用戶文件、管理文件。
1. 開發(fā)文件：可行性研究報告、軟件需求說明書、數(shù)據(jù)要求說明書、概要設(shè)計說明書、詳細設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、模塊開發(fā)卷宗。
2.用戶文件：用戶手冊、操作手冊。
3.管理文件：項目開發(fā)計劃、測試計劃、測試分析報告、開發(fā)進度月報、項目開發(fā)總結(jié)報告。
軟件測試中的文檔測試主要是對相關(guān)的設(shè)計報告和用戶使用說明進行測試，對于設(shè)計報告主要是測試程序與設(shè)計報告中的設(shè)計思想是否一致；對于用戶使用說明進行測試時，主要是測試用戶使用說明書中對程序操作方法的描述是否正確，重點是用戶使用說明中提到的操作例子要進行測試，保證采用的例子能夠在程序中正確完成操作。
?
域測試
域測試的英文是domain testing，定義參考等價劃分測試（equivalence partition testing）；
一般分為單域測試和多域測試，其中單域測試包括設(shè)備測試和業(yè)務(wù)測試，設(shè)備測試包括測試某個系統(tǒng)的軟交換設(shè)備、中繼媒體網(wǎng)關(guān)設(shè)備、信令網(wǎng)關(guān)設(shè)備、接入媒體網(wǎng)關(guān)和IAD等設(shè)備。
等價類劃分有兩種不同的情況：有效等價類和無效等價類。設(shè)計時要同時考慮這兩種等價類，因為軟件不僅要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗。
一有效等價類：是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價類可檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。
二無效等價類：與有效等價類的定義恰巧相反。
?
接口測試
接口測試的英文是interface testing，接口測試測試系統(tǒng)組件間接口的一種測試。
接口測試的好處：
由于接口測試代碼本身就是用junit（當然接口的類型不同，不一定是Junit來實現(xiàn)）來實現(xiàn)的，是屬于自動化測試的范疇，因此必定也包含自動化測試所固有的優(yōu)勢。
1） 提高測試質(zhì)量
軟件開發(fā)的過程是一個持續(xù)集成和改進的過程，而每一次的改進都可能引進新bug,因此當軟件的一部，或者全部修改時，都需要對軟件產(chǎn)品重新進行測試。其目的是要驗證修改后的產(chǎn)品是符合需求的，而當沒有自動化測試代碼時，往往會由于各種各樣的原因，回歸不充分，導(dǎo)致bug遺漏。
2） 提高測試效率
軟件系統(tǒng)的規(guī)模越來越大，功能點越來越多，開發(fā)人員的自測或者測試人員的人工測試非常耗時和繁瑣，勢必導(dǎo)致測試效率的低下，而自動化測試正好解決這些耗時繁瑣的任務(wù)，在對外接口功能不變的情況下，達到了一次編寫，永久使用的效果。
3） 提高測試覆蓋
通過手工測試很難測試到一些更深層次的異常和安全的問題，通過一些輔助的一些測試工具，能分析出代碼的覆蓋率，通過覆蓋率的提高來提高測試的深度。
4） 更好地重現(xiàn)軟件缺陷
由于每次執(zhí)行都是相同的代碼，一旦代碼出錯，必定回歸出錯
5） 更好定位錯誤
由于接口測試是一種自下向上的測試，因此一量出錯，非常容易定位出錯，不向系統(tǒng)測試那樣了，一旦有Bug，需要幾層驗證之后才能確定出錯位置
6） 降低修改bug的成本接口測試基本和開發(fā)人員的編碼平行工作，因此發(fā)現(xiàn)問題會比系統(tǒng)測試早很多，因此減少了修改bug的成本。
7） 增進測試人員和開發(fā)人員之間的合作關(guān)系，測試工程師為了更好地開展工作，需要對開發(fā)技術(shù)有深入的理解和實踐，有了與開發(fā)工程師更多的交流。
8） 降低了項目不能按時發(fā)布的風(fēng)險由于接口測試很早就介入，在提交給系統(tǒng)測試前對項目代碼的核心模塊已經(jīng)做了詳盡的測試，必定加速系統(tǒng)測試的時間，由此來保證項目的按時發(fā)布。
9）提升測試人員的技能。做接口測試必須了解開發(fā)人員的開發(fā)流程和一些開發(fā)技能，也需要了解測試工具的一些使用方法和一些測試思想，提升了測試人員的技術(shù)附加值，提高了自身的竟爭力。
10）促使項目開發(fā)過程的規(guī)范化
要進行接口，需要完善的文檔進行保障，沒有測試文檔，接口測試將寸步難行，接口測試將增加開發(fā)過程規(guī)范化產(chǎn)出，而規(guī)范化產(chǎn)出也保證了項目質(zhì)量。
?
逆向測試，反向測試，負面測試
逆向測試/反向測試/負面測試的英文是Negative Testing，測試瞄準于使系統(tǒng)不能工作。
負面測試與正面測試的比較：
負面測試（Negative testing）是相對于正面測試（Positive testing）而言的。它們也是測試設(shè)計時的兩個非常重要的劃分。簡單點說，正面測試就是測試系統(tǒng)是否完成了它應(yīng)該完成的工作；而負面測試就是測試系統(tǒng)是否不執(zhí)行它不應(yīng)該完成的操作。形象一點，正面測試就象一個畢恭畢敬的小學(xué)生，老師叫我做什么，我就做什么；而負面測試就象一個調(diào)皮搗蛋的孩子，你叫我這樣做，我偏不這樣做，而且和你對著干。開發(fā)人員也是最討厭修改此類bug的。
?
非功能性需求測試
非功能性需求測試的英文是non-functional requirements testing ，是與功能不相關(guān)的需求測試，如：性能測試、可用性測試等。
為什么非功能性需求很重要？
在您設(shè)計解決方案的過程中滿足功能性需求當然是很重要的。但是，如果沒有考慮非功能性需求，您的解決方案則很難取得實效。
非功能性需求特點：1.不要脫離實際環(huán)境；2.可靠性；3.可用性；4.有效性；5.可維護性；6.可移植性。
?
轉(zhuǎn)載于:https://www.cnblogs.com/eagleking0318/archive/2010/07/14/6521486.html
《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
- 上一篇： 生产线称重实时打印条码标签
- 下一篇： JavaScript与C# Window