一般公司常用的軟件測試工具有哪些?
1、靜態(tài)測試工具:直接對代碼進(jìn)行分析,生成可執行文件。靜態(tài)測試工具一般是對代碼進(jìn)行語(yǔ)法掃描,根據某種質(zhì)量模型評價(jià)代碼的質(zhì)量,生成系統的調用關(guān)系圖等。靜態(tài)測試工具的代表有:Telelogic公司的Logiscope軟件;PR公司的PRQA軟件。
2、動(dòng)態(tài)測試工具:動(dòng)態(tài)測試工具的一般采用"插樁"的方式,向代碼生成的可執行文件中插入一些監測代碼,用來(lái)統計程序運行時(shí)的數據。動(dòng)態(tài)測試工具的代表有:Compuware公司的軟件;Rational公司的Purify系列等。
3、黑盒測試工具
黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback),模擬用戶(hù)的操作。黑盒測試工具的代表有:Rational公司的TeamTest、Robot;Compuware公司的QACenter。
4、性能測試工具
的是一種適用于各種體系架構的自動(dòng)負載測試工具,它能預測系統行為并優(yōu)化系統性能。的測試對象是整個(gè)企業(yè)的系統,它通過(guò)模擬實(shí)際用戶(hù)的操作行為和實(shí)行實(shí)時(shí)性能監測,來(lái)幫助您更快的查找和發(fā)現問(wèn)題。
5、測試管理工具
測試管理工具對測試計劃、測試用例、測試實(shí)施進(jìn)行管理,并且,測試管理工具還包括對缺陷的跟蹤管理。測試管理工具的代表有:Rational公司的;公司的;公司的等軟件。
參考資料:百度百科-軟件測試(第二版)
軟件測試工具有哪些?
1、禪道測試管理工具是功能比較全面的測試管理工具,功能涵蓋軟件研發(fā)的全部生命周期,為軟件測試和產(chǎn)品研發(fā)提供一體化的解決方案,是一款十分優(yōu)秀的國產(chǎn)開(kāi)源測試管理工具。
2、是一種預測系統行為和性能的工業(yè)標準級負載測試工具。通過(guò)模擬上千萬(wàn)用戶(hù)實(shí)施并發(fā)負載及實(shí)時(shí)性能監測的方式來(lái)確認和查找問(wèn)題,它能夠對整個(gè)企業(yè)架構進(jìn)行測試。通過(guò),企業(yè)能*限度地縮短測試時(shí)間,優(yōu)化性能和加速應用系統的發(fā)布周期。它是一種適用于各種體系架構的自動(dòng)負載測試工具,它能預測系統行為并優(yōu)化系統性能。的測試對象是整個(gè)企業(yè)的系統,它通過(guò)模擬實(shí)際用戶(hù)的操作行為和實(shí)時(shí)性能監測,來(lái)幫助更快地查找和發(fā)現問(wèn)題。
3、QTP是一個(gè)B/S系統的自動(dòng)化功能測試的利器,軟件程序測試工具。Mercury的自動(dòng)化功能測試軟件,可以覆蓋絕大多數的軟件開(kāi)發(fā)技術(shù),簡(jiǎn)單高效,并具備測試用例可重用的特點(diǎn)。是一款先進(jìn)的自動(dòng)化測試解決方案,用于創(chuàng )建功能和回歸測試。它自動(dòng)捕獲、驗證和重放用戶(hù)的交互行為。為每一個(gè)重要軟件應用和環(huán)境提供功能和回歸測試自動(dòng)化的行業(yè)*解決方案。
4、Selenium是為正在蓬勃發(fā)展的web應用開(kāi)發(fā)的一套完整的測試系統。Selenium測試直接運行在瀏覽器中,就像真正的用戶(hù)在操作一樣。它的主要功能包括:測試與瀏覽器的兼容性——測試你的應用程序是否能夠很好的在不同瀏覽器和操作系統上工作。測試系統功能——創(chuàng )建衰退測試檢驗軟件功能和用戶(hù)需求。支持自動(dòng)錄制動(dòng)作和自動(dòng)生成。Selenium的核心基于JsUnit,完全由編寫(xiě),因此可運行于任何支持的瀏覽器上,包括IE、、Chrome、Safari等。
軟件測試一般都用到哪些工具
1、企業(yè)級自動(dòng)化測試工具WinRunner,用于檢測應用程序是否能夠達到預期的功能及正常運行。通過(guò)自動(dòng)錄制、檢測和回放用戶(hù)的應用操作,能夠幫助測試人員對復雜的企業(yè)級應用的不同發(fā)布版進(jìn)行測試,確??缙脚_的、復雜的企業(yè)級應用無(wú)故障發(fā)布及長(cháng)期穩定運行。
2、工業(yè)標準級負載測試工具,是一種預測系統行為和性能的負載測試工具。通過(guò)以模擬上千萬(wàn)用戶(hù)實(shí)施并發(fā)負載及實(shí)時(shí)性能監測的方式來(lái)確認和查找問(wèn)題,能夠對整個(gè)企業(yè)架構進(jìn)行測試。企業(yè)能*限度地縮短測試時(shí)間,優(yōu)化性能和加速應用系統的發(fā)布周期。
3、功能測試工具Rational Robot,可以在測試人員學(xué)習高級腳本技術(shù)之前幫助其進(jìn)行成功的測試。它集成在測試人員的桌面IBM Rational 上,測試人員可以計劃、組織、執行、管理和報告所有測試活動(dòng),包括手動(dòng)測試報告。這種測試和管理的雙重功能是自動(dòng)化測試的理想開(kāi)始。
4、功能測試工具SilkTest,是Borland公司所提出軟件質(zhì)量管理解決方案的套件之一。這個(gè)工具采用精靈設定與自動(dòng)化執行測試,無(wú)論是程序設計新手或資深的專(zhuān)家都能快速建立功能測試,并分析功能錯誤。
5、全球測試管理系統,是基于Web的測試管理系統,可以在公司內部或外部進(jìn)行全球范圍內測試的管理。通過(guò)在一個(gè)整體的應用系統中集成了測試管理的各個(gè)部分,包括需求管理,測試計劃,測試執行以及錯誤跟蹤等功能,極大地加速了測試過(guò)程。
擴展資料:
WinRunner可以通過(guò)Function Generator增加測試的功能。使用Function Generator可以從目錄列表中選擇一個(gè)功能增加到測試中以提高測試能力。
針對相當數量的企業(yè)應用里非標準對象,WinRunner提供了Virtual Object Wizard來(lái)識別以前未知的對象。使用Virtual Object Wizard,可以選擇未知對象的類(lèi)型,設定標識和命名。在錄制使用該對象的測試時(shí),WinRunner會(huì )自動(dòng)對應它的名字,從而提高測試腳本的可讀性和測試質(zhì)量。
常用的軟件測試工具有哪些?
在測試工作中,需要接觸到各種類(lèi)型的測試工具。一般來(lái)說(shuō),有以下一些類(lèi)型的工具:測試管理工具:可以幫助完成測試計劃、跟蹤測試運行結果等的工具。這類(lèi)工具還包括有助于需求、設計、編碼測試及缺陷跟蹤的工具;
靜態(tài)分析工具:分析代碼而不執行代碼。這種工具檢測某些缺陷比用其它方法更有效,開(kāi)銷(xiāo)也更小。這種工具一般可以度量代碼的各種指標,如McCabe測定復雜度,Logiscope度量代碼和規范的復合度等等;
覆蓋率工具:這種工具評估通過(guò)一系列測試后,軟件被執行的程度。這種工具大量的被應用于單元測試中,如、、Logiscope等;
動(dòng)態(tài)分析工具:這種工具評估正在運行的系統。例如,檢查系統運行過(guò)程中的內存使用情況,是否有內存越界、內存泄露等等,這類(lèi)工具有Purify、等;
測試執行工具:這類(lèi)工具可使測試能夠自動(dòng)化進(jìn)行,并且各個(gè)層次(單元測試、集成測試、系統測試)的執行工具都有。例如系統測試階段有功能測試自動(dòng)化工具,如Robot、Winrunner、SilkTest等;還有性能測試工具,如、等。
白盒測試工具主要有:
內存資源泄漏檢查:Numega中的,Rational的Purify
代碼覆蓋率檢查:Numega中的,Rational的,Telelogic公司的logiscope,Macabe公司的Macabe
代碼性能檢查:Numega中的truetime,Rational的Quantify
代碼靜態(tài)度量分析質(zhì)量檢查工具:logiscope和Macabe
黑盒測試工具主要有:
客戶(hù)端功能測試:MI公司的winrunner,compuware的qarun,Rational的robot
服務(wù)器端壓力性能測試:MI公司的winload,compuware的qaload,Rational的SQAload等等
Web測試工具:MI公司的Astra系列,rsw公司的e-testsuite
測試管理工具:rational的,compuware的等
缺陷跟蹤工具:,Testtrack
單元測試工具:
測試框架:++cppunit
黑盒測試需要掌握哪些工具,技能?
軟件測試要求知識面廣,但不一定精,編程語(yǔ)言的話(huà),*是什么都學(xué)過(guò),至少幾種主流的程序語(yǔ)言要學(xué)過(guò),如java、.net、C++。還有會(huì )一些腳本語(yǔ)言vba(vb)、sql、 C等。網(wǎng)絡(luò )的話(huà):TCP/IP協(xié)議,局域網(wǎng)廣域網(wǎng)相關(guān)知識等
數據庫:當前主流的mysql、ms-sql、oracle
常用測試工具:HP的三劍客首當其沖了:QTP(自動(dòng)化功能測試工具)、(自動(dòng)化性能測試工具)、QC(TD前身,測試管理追蹤工具)。當然這些都是收費產(chǎn)品。網(wǎng)上有破解版的可供學(xué)習。(一套)
開(kāi)源免費的測試工具:QTP(自動(dòng)化功能測試工具,破解版的可以滿(mǎn)足絕大部分測試需求)、jmeter(自動(dòng)化性能測試工具)、bugzilla(測試管理追蹤工具)。
軟件測試中什么是白盒測試 黑盒測試
白盒測試也稱(chēng)結構測試或邏輯驅動(dòng)測試,它是按照程序內部的結構測試程序,通過(guò)測試來(lái)檢測產(chǎn)品內部動(dòng)作是否按照設計規格說(shuō)明書(shū)的規定正常進(jìn)行,檢驗程序中的每條通路是否都能按預定要求正確工作。這一方法是把測試對象看作一個(gè)打開(kāi)的盒子,測試人員依據程序內部邏輯結構相關(guān)信息,設計或選擇測試用例,對程序所有邏輯路徑進(jìn)行測試,通過(guò)在不同點(diǎn)檢查程序的狀態(tài),確定實(shí)際的狀態(tài)是否與預期的狀態(tài)一致。
采用什么方法對軟件進(jìn)行測試呢?常用的軟件測試方法有兩大類(lèi):靜態(tài)測試方法和動(dòng)態(tài)測試方法。其中軟件的靜態(tài)測試不要求在計算機上實(shí)際執行所測程序,主要以一些人工的模擬技術(shù)對軟件進(jìn)行分析和測試;而軟件的動(dòng)態(tài)測試是通過(guò)輸入一組預先按照一定的測試準則構造的實(shí)例數據來(lái)動(dòng)態(tài)運行程序,而達到發(fā)現程序錯誤的過(guò)程。
白盒測試的測試方法有代碼檢查法、靜態(tài)結構分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。
白盒測試法的覆蓋標準有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
六種覆蓋標準:語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋發(fā)現錯誤的能力呈由弱至強的變化。語(yǔ)句覆蓋每條語(yǔ)句至少執行一次。判定覆蓋每個(gè)判定的每個(gè)分支至少執行一次。條件覆蓋每個(gè)判定的每個(gè)條件應取到各種可能的值。判定/條件覆蓋同時(shí)滿(mǎn)足判定覆蓋條件覆蓋。條件組合覆蓋每個(gè)判定中各條件的每一種組合至少出現一次。路徑覆蓋使程序中每一條可能的路徑至少執行一次。
"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進(jìn)行測試。"白盒"法是窮舉路徑測試。在使用這一方案時(shí),測試者必須檢查程序的內部結構,從檢查程序的邏輯著(zhù)手,得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。*,窮舉路徑測試決不能查出程序違反了設計規范,即程序本身是個(gè)錯誤的程序。第二,窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三,窮舉路徑測試可能發(fā)現不了一些與數據相關(guān)的錯誤。
如何挑選白盒測試工具
白盒測試目前主要用在具有高可靠性要求的軟件領(lǐng)域,例如:軍工軟件、航天航空軟件、工業(yè)控制軟件等等。白盒測試工具在選購時(shí)應當主要是對開(kāi)發(fā)語(yǔ)言的支持、代碼覆蓋的深度、嵌入式軟件的測試、測試的可視化等。
對開(kāi)發(fā)語(yǔ)言的支持:白盒測試工具是對源代碼進(jìn)行的測試,測試的主要內容包括詞法分析與語(yǔ)法分析、靜態(tài)錯誤分析、動(dòng)態(tài)檢測等。但是對于不同的開(kāi)發(fā)語(yǔ)言,測試工具實(shí)現的方式和內容差別是較大的。目前測試工具主要支持的開(kāi)發(fā)語(yǔ)言包括:標準C、C++、Visual C++、Java、Visual J++等。
代碼的覆蓋深度:從覆蓋源程序語(yǔ)句的詳盡程度分析,邏輯覆蓋標準包括以下不同的覆蓋標準:語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、條件判定組合覆蓋、多條件覆蓋和修正判定條件覆蓋。
·語(yǔ)句覆蓋 為了暴露程序中的錯誤,程序中的每條語(yǔ)句至少應該執行一次。因此語(yǔ)句覆蓋(Statement Coverage)的含義是:選擇足夠多的測試數據,使被測程序中每條語(yǔ)句至少執行一次。語(yǔ)句覆蓋是很弱的邏輯覆蓋。
·判定覆蓋 比語(yǔ)句覆蓋稍強的覆蓋標準是判定覆蓋(Decision Coverage)。判定覆蓋的含義是:設計足夠的測試用例,使得程序中的每個(gè)判定至少都獲得一次“真值”或“假值”,或者說(shuō)使得程序中的每一個(gè)取“真”分支和取“假”分支至少經(jīng)歷一次,因此判定覆蓋又稱(chēng)為分支覆蓋。
·條件覆蓋 在設計程序中,一個(gè)判定語(yǔ)句是由多個(gè)條件組合而成的復合判定。為了更徹底地實(shí)現邏輯覆蓋,可以采用條件覆蓋(Condition Coverage)的標準。條件覆蓋的含義是:構造一組測試用例,使得每一判定語(yǔ)句中每個(gè)邏輯條件的可能值至少滿(mǎn)足一次。
·多條件覆蓋 多條件覆蓋也稱(chēng)條件組合覆蓋,它的含義是:設計足夠的測試用例,使得每個(gè)判定中條件的各種可能組合都至少出現一次。顯然滿(mǎn)足多條件覆蓋的測試用例是一定滿(mǎn)足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
·修正條件判定覆蓋 修正條件判定覆蓋是由歐美的航空/航天制造廠(chǎng)商和使用單位聯(lián)合制定的“航空運輸和裝備系統軟件認證標準”,目前在國外的國防、航空航天領(lǐng)域應用廣泛。這個(gè)覆蓋度量需要足夠的測試用例來(lái)確定各個(gè)條件能夠影響到包含的判定的結果。它要求滿(mǎn)足兩個(gè)條件:首先,每一個(gè)程序模塊的入口和出口點(diǎn)都要考慮至少要被調用一次,每個(gè)程序的判定到所有可能的結果值要至少轉換一次;其次,程序的判定被分解為通過(guò)邏輯操作符(and、or)連接的布爾條件,每個(gè)條件對于判定的結果值是獨立的。
不同的測試工具對于代碼的覆蓋能力也是不同的,通常能夠支持修正條件判定覆蓋的測試工具價(jià)格是極其昂貴的。
嵌入式軟件的測試:對于嵌入式軟件的測試,我們還需要一方面進(jìn)一步考慮測試工具對于嵌入式操作系統的支持能力,例如DOS、Vxworks、Neculeus、Linux和Windows CE等;另一方面還需要考慮測試工具對于硬件平臺的支持能力,包括是否支持所有64/32/16位CPU 和 MCU,是否可以支持 PCI/VME/CPCI 總線(xiàn)。
測試的可視化:白盒測試是工作量巨大并且枯燥的工作,可視化的設計對于測試來(lái)說(shuō)是十分重要的。在選購白盒測試工具時(shí),應當考慮該款測試工具的可視化是否良好,例如:測試過(guò)程中是否可以顯示覆蓋率的函數分布圖和上升趨勢圖,是否使用不同的顏色區分已執行和未執行的代碼段顯示分配內存情況實(shí)時(shí)圖表等,這些對于測試效率和測試質(zhì)量的提高是具有很大的作用的。
白盒測試之基本路徑測試法
白盒測試的測試方法有代碼檢查法、靜態(tài)結構分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。
其中運用最為廣泛的是基本路徑測試法。
基本路徑測試法是在程序控制流圖的基礎上,通過(guò)分析控制構造的環(huán)路復雜性,導出基本可執行路徑集合,從而設計測試用例的方法。
設計出的測試用例要保證在測試中程序的每個(gè)可執行語(yǔ)句至少執行一次。
在程序控制流圖的基礎上,通過(guò)分析控制構造的環(huán)路復雜性,導出基本可執行路徑集合,從而設計測試用例。包括以下4個(gè)步驟和一個(gè)工具方法:
1. 程序的控制流圖:描述程序控制流的一種圖示方法。
2. 程序圈復雜度:McCabe復雜性度量。從程序的環(huán)路復雜性可導出程序基本路徑集合中的獨立路徑條數,這是確定程序中每個(gè)可執行語(yǔ)句至少執行一次所必須的測試用例數目的上界。
3. 導出測試用例:根據圈復雜度和程序結構設計用例數據輸入和預期結果。
4. 準備測試用例:確?;韭窂郊械拿恳粭l路徑的執行。
工具方法:
圖形矩陣:是在基本路徑測試中起輔助作用的軟件工具,利用它可以實(shí)現自動(dòng)地確定一個(gè)基本路徑集。
程序的控制流圖:描述程序控制流的一種圖示方法。
圓圈稱(chēng)為控制流圖的一個(gè)結點(diǎn),表示一個(gè)或多個(gè)無(wú)分支的語(yǔ)句或源程序語(yǔ)句
流圖只有二種圖形符號:
圖中的每一個(gè)圓稱(chēng)為流圖的結點(diǎn),代表一條或多條語(yǔ)句。
流圖中的箭頭稱(chēng)為邊或連接,代表控制流
任何過(guò)程設計都要被翻譯成控制流圖。
如何根據程序流程圖畫(huà)出控制流程圖?
在將程序流程圖簡(jiǎn)化成控制流圖時(shí),應注意:
在選擇或多分支結構中,分支的匯聚處應有一個(gè)匯聚結點(diǎn)。
邊和結點(diǎn)圈定的區域叫做區域,當對區域計數時(shí),圖形外的區域也應記為一個(gè)區域。
基本路徑測試法的步驟:
*步:畫(huà)出控制流圖
流程圖用來(lái)描述程序控制結構??蓪⒘鞒虉D映射到一個(gè)相應的流圖(假設流程圖的菱形決定框中不包含復合條件)。在流圖中,每一個(gè)圓,稱(chēng)為流圖的結點(diǎn),代表一個(gè)或多個(gè)語(yǔ)句。一個(gè)處理方框序列和一個(gè)菱形決測框可被映射為一個(gè)結點(diǎn),流圖中的箭頭,稱(chēng)為邊或連接,代表控制流,類(lèi)似于流程圖中的箭頭。一條邊必須終止于一個(gè)結點(diǎn),即使該結點(diǎn)并不代表任何語(yǔ)句(例如:if-else-then結構)。由邊和結點(diǎn)限定的范圍稱(chēng)為區域。計算區域時(shí)應包括圖外部的范圍。
第二步:計算圈復雜度
圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量,將該度量用于計算程序的基本的獨立路徑數目,為確保所有語(yǔ)句至少執行一次的測試數量的上界。獨立路徑必須包含一條在定義之前不曾用到的邊。
有以下三種方法計算圈復雜度:
流圖中區域的數量對應于環(huán)型的復雜性;
給定流圖G的圈復雜度V(G),定義為V(G)=E-N+2,E是流圖中邊的數量,N是流圖中結點(diǎn)的數量;
給定流圖G的圈復雜度V(G),定義為V(G)=P+1,P是流圖G中判定結點(diǎn)的數量。
第三步:導出測試用例 根據上面的計算方法,可得出四個(gè)獨立的路徑。(一條獨立路徑是指,和其他的獨立路徑相比,至少引入一個(gè)新處理語(yǔ)句或一個(gè)新判斷的程序通路。V(G)值正好等于該程序的獨立路徑的條數。)
路徑1:4-14
路徑2:4-6-7-14
路徑3:4-6-8-10-13-4-14
路徑4:4-6-8-11-13-4-14
根據上面的獨立路徑,去設計輸入數據,使程序分別執行到上面四條路徑。
白盒測試三步法
1) 根據代碼的功能,人工設計測試用例進(jìn)行基本功能測試;
2) 統計白盒覆蓋率,為未覆蓋的白盒單位設計測試用例,實(shí)現完整的白盒覆蓋,比較理想的覆蓋率是實(shí)現*語(yǔ)句、條件、分支、路徑覆蓋;
3) 自動(dòng)生成大量的測試用例,捕捉"程序員未處理某些特殊輸入"形成的錯誤。
第1步的測試用例通常是現成的,因為詳細設計文檔會(huì )規定程序的基本功能,沒(méi)有文檔的,程序員在編程時(shí)也要想清楚程序的功能,這些基本功能就是基本測試用例;
第2步是在第1步的基礎上,檢查未覆蓋的白盒單位,由于未覆蓋的邏輯單位通常對應未測試的等價(jià)類(lèi),因此第2步可以找出第1步所遺漏的測試用例;
第3步用自動(dòng)動(dòng)態(tài)測試彌補第2步的固有缺陷。
"三步法"盡量避免重復工作,白盒方法和黑盒方法相結合,人工方法和自動(dòng)方法相補充,如果第2步的覆蓋率比較理想,那么基本上可以保證找出所有等價(jià)類(lèi)。在開(kāi)發(fā)過(guò)程允許的限度內,"三步法"已接近極限,當得起"徹底測試"四個(gè)字。
黑盒測試也稱(chēng)功能測試,它是通過(guò)測試來(lái)檢測每個(gè)功能是否都能正常使用。在測試地,把程序看作一個(gè)不能打開(kāi)的黑盒子,在完全不考慮程序內部結構和內部特性的情況下,在程序接口進(jìn)行測試,它只檢查程序功能是否按照需求規格說(shuō)明書(shū)的規定正常使用,程序是否能適當地接收輸入數據而產(chǎn)生正確的輸出信息。黑盒測試著(zhù)眼于程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進(jìn)行測試。
黑盒測試是以用戶(hù)的角度,從輸入數據與輸出數據的對應關(guān)系出發(fā)進(jìn)行測試的。很明顯,如果外部特性本身有問(wèn)題或規格說(shuō)明的規定有誤,用墨盒測試方法是發(fā)現不了的。
黑盒測試法注重于測試軟件的功能需求,主要試圖發(fā)現下列幾類(lèi)錯誤。
功能不正確或遺漏;
界面錯誤;
數據庫訪(fǎng)問(wèn)錯誤;
性能錯誤;
初始化和終止錯誤等。
從理論上講,黑盒測試只有采用窮舉輸入測試,把所有可能的輸入都作為測試情況考慮,才能查出程序中所有的錯誤。實(shí)際上測試情況有無(wú)窮多個(gè),人們不僅要測試所有合法的輸入,而且還要對那些不合法但可能的輸入進(jìn)行測試。這樣看來(lái),完全測試是不可能的,所以我們要進(jìn)行有針對性的測試,通過(guò)制定測試案例指導測試的實(shí)施,保證軟件測試有組織、按步驟,以及有計劃地進(jìn)行。黑盒測試行為必須能夠加以量化,才能真正保證軟件質(zhì)量,而測試用例就是將測試行為具體量化的方法之一。具體的黑盒測試用例設計方法包括等價(jià)類(lèi)劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動(dòng)法、正交試驗設計法、功能圖法等。
等價(jià)類(lèi)劃分的辦法是把程序的輸入域劃分成若干部分(子集),然后從每個(gè)部分中選取少數代表性數據作為測試用例。每一類(lèi)的代表性數據在測試中的作用等價(jià)于這一類(lèi)中的其他值。該方法是一種重要的,常用的黑盒測試用例設計方法。
1) 劃分等價(jià)類(lèi): 等價(jià)類(lèi)是指某個(gè)輸入域的子集合。在該子集合中,各個(gè)輸入數據對于揭露程序中的錯誤都是等效的,并合理地假定:測試某等價(jià)類(lèi)的代表值就等于對這一類(lèi)其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價(jià)類(lèi),在每一個(gè)等價(jià)類(lèi)中取一個(gè)數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價(jià)類(lèi)劃分可有兩種不同的情況:有效等價(jià)類(lèi)和無(wú)效等價(jià)類(lèi).
有效等價(jià)類(lèi):是指對于程序的規格說(shuō)明來(lái)說(shuō)是合理的,有意義的輸入數據構成的集合.利用有效等價(jià)類(lèi)可檢驗程序是否實(shí)現了規格說(shuō)明中所規定的功能和性能.
無(wú)效等價(jià)類(lèi):與有效等價(jià)類(lèi)的定義恰巧相反.
設計測試用例時(shí),要同時(shí)考慮這兩種等價(jià)類(lèi).因為,軟件不僅要能接收合理的數據,也要能經(jīng)受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性.
2)劃分等價(jià)類(lèi)的方法:下面給出六條確定等價(jià)類(lèi)的原則.
①在輸入條件規定了取值范圍或值的個(gè)數的情況下,則可以確立一個(gè)有效等價(jià)類(lèi)和兩個(gè)無(wú)效等價(jià)類(lèi).
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,可確立一個(gè)有效等價(jià)類(lèi)和一個(gè)無(wú)效等價(jià)類(lèi).
③在輸入條件是一個(gè)布爾量的情況下,可確定一個(gè)有效等價(jià)類(lèi)和一個(gè)無(wú)效等價(jià)類(lèi).
④在規定了輸入數據的一組值(假定n個(gè)),并且程序要對每一個(gè)輸入值分別處理的情況下,可確立n個(gè)有效等價(jià)類(lèi)和一個(gè)無(wú)效等價(jià)類(lèi).
⑤在規定了輸入數據必須遵守的規則的情況下,可確立一個(gè)有效等價(jià)類(lèi)(符合規則)和若干個(gè)無(wú)效等價(jià)類(lèi)(從不同角度違反規則).
⑥在確知已劃分的等價(jià)類(lèi)中各元素在程序處理中的方式不同的情況下,則應再將該等價(jià)類(lèi)進(jìn)一步的劃分為更小的等價(jià)類(lèi).
3)設計測試用例:在確立了等價(jià)類(lèi)后,可建立等價(jià)類(lèi)表,列出所有劃分出的等價(jià)類(lèi):
輸入條件 有效等價(jià)類(lèi) 無(wú)效等價(jià)類(lèi)
... ... ...
... ... ...
然后從劃分出的等價(jià)類(lèi)中按以下三個(gè)原則設計測試用例:
①為每一個(gè)等價(jià)類(lèi)規定一個(gè)*的編號.
②設計一個(gè)新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價(jià)類(lèi),重復這一步.直到所有的有效等價(jià)類(lèi)都被覆蓋為止.
③設計一個(gè)新的測試用例,使其僅覆蓋一個(gè)尚未被覆蓋的無(wú)效等價(jià)類(lèi),重復這一步.直到所有的無(wú)效等價(jià)類(lèi)都被覆蓋為止.
邊界值分析是通過(guò)選擇等價(jià)類(lèi)邊界的測試用例。邊界值分析法不僅重視輸入條件邊界,而且也必須考慮輸出域邊界。它是對等價(jià)類(lèi)劃分方法的補充.
(1)邊界值分析方法的考慮:
長(cháng)期的測試工作經(jīng)驗告訴我們,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價(jià)類(lèi)的邊界,就是應著(zhù)重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價(jià)類(lèi)中的典型值或任意值作為測試數據.
(2)基于邊界值分析方法選擇測試用例的原則:
1)如果輸入條件規定了值的范圍,則應取剛達到這個(gè)范圍的邊界的值,以及剛剛超越這個(gè)范圍邊界的值作為測試輸入數據.
2)如果輸入條件規定了值的個(gè)數,則用*個(gè)數,最小個(gè)數,比最小個(gè)數少一,比*個(gè)數多一的數作為測試數據.
3)根據規格說(shuō)明的每個(gè)輸出條件,使用前面的原則1).
4)根據規格說(shuō)明的每個(gè)輸出條件,應用前面的原則2).
5)如果程序的規格說(shuō)明給出的輸入域或輸出域是有序集合,則應選取集合的*個(gè)元素和*一個(gè)元素作為測試用例.
6)如果程序中使用了一個(gè)內部數據結構,則應當選擇這個(gè)內部數據結構的邊界上的值作為測試用例.
7)分析規格說(shuō)明,找出其它可能的邊界條件.
錯誤推測法是基于經(jīng)驗和直覺(jué)推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時(shí)曾列出的許多在模塊中常見(jiàn)的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現的錯誤等, 這些就是經(jīng)驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
因果圖法:
前面介紹的等價(jià)類(lèi)劃分方法和邊界值分析方法,都是著(zhù)重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì )產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類(lèi),他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設計測試用例. 這就需要利用因果圖(邏輯模型).
因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.
利用因果圖生成測試用例的基本步驟:
(1) 分析軟件規格說(shuō)明描述中, 那些是原因(即輸入條件或輸入條件的等價(jià)類(lèi)),那些是結果(即輸出條件), 并給每個(gè)原因和結果賦予一個(gè)標識符.
(2) 分析軟件規格說(shuō)明描述中的語(yǔ)義.找出原因與結果之間, 原因與原因之間對應的關(guān)系. 根據這些關(guān)系,畫(huà)出因果圖.
(3) 由于語(yǔ)法或環(huán)境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.
(4) 把因果圖轉換為判定表.
(5) 把判定表的每一列拿出來(lái)作為依據,設計測試用例.
從因果圖生成的測試用例(局部,組合關(guān)系下的)包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線(xiàn)性地增加.
前面因果圖方法中已經(jīng)用到了判定表.判定表(Decision Table)是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發(fā)展的初期,判定表就已被當作編寫(xiě)程序的輔助工具了.由于它可以把復雜的邏輯關(guān)系和多種條件組合的情況表達得既具體又明確.
判定表通常由四個(gè)部分組成.
條件樁(Condition Stub):列出了問(wèn)題得所有條件.通常認為列出得條件的次序無(wú)關(guān)緊要.
動(dòng)作樁(Action Stub):列出了問(wèn)題規定可能采取的操作.這些操作的排列順序沒(méi)有約束.
條件項(Condition Entry):列出針對它左列條件的取值.在所有可能情況下的真假值.
動(dòng)作項(Action Entry):列出在條件項的各種取值情況下應該采取的動(dòng)作.
規則:任何一個(gè)條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動(dòng)作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動(dòng)作項有多少列.
判定表的建立步驟:(根據軟件規格說(shuō)明)
①確定規則的個(gè)數.假如有n個(gè)條件.每個(gè)條件有兩個(gè)取值(0,1),故有 種規則.
②列出所有的條件樁和動(dòng)作樁.
③填入條件項.
④填入動(dòng)作項.等到初始判定表.
⑤簡(jiǎn)化.合并相似規則(相同動(dòng)作).
B. Beizer 指出了適合使用判定表設計測試用例的條件:
①規格說(shuō)明以判定表形式給出,或很容易轉換成判定表.
②條件的排列順序不會(huì )也不影響執行哪些操作.
③規則的排列順序不會(huì )也不影響執行哪些操作.
④每當某一規則的條件已經(jīng)滿(mǎn)足,并確定要執行的操作后,不必檢驗別的規則.
⑤如果某一規則得到滿(mǎn)足要執行多個(gè)操作,這些操作的執行順序無(wú)關(guān)緊要.
正交試驗設計法,就是使用已經(jīng)造好了的正交表格來(lái)安排試驗并進(jìn)行數據分析的一種方法,目的是用最少的測試用例達到*的測試覆蓋率。
黑盒測試的優(yōu)點(diǎn)
1. 基本上不用人管著(zhù),如果程序停止運行了一般就是被測試程序crash了
2. 設計完測試例之后,下來(lái)的工作就是爽了,當然更苦悶的是確定crash原因
黑盒測試的缺點(diǎn)
1. 結果取決于測試例的設計,測試例的設計部分來(lái)勢來(lái)源于經(jīng)驗,OUSPG的東西很值得借鑒
2. 沒(méi)有狀態(tài)轉換的概念,目前一些成功的例子基本上都是針對PDU來(lái)做的,還做不到針對被測試程序的狀態(tài)轉換來(lái)作
3. 就沒(méi)有狀態(tài)概念的測試來(lái)說(shuō),尋找和確定造成程序crash的測試例是個(gè)麻煩事情,必須把周?chē)赡艿臏y試例單獨確認一遍。而就有狀態(tài)的測試來(lái)說(shuō),就更麻煩了,尤其不是一個(gè)單獨的testcase造成的問(wèn)題。這些在堆的問(wèn)題中表現的更為突出。
黑盒測試(功能測試)工具的選擇
那么,如何高效地完成功能測試?選擇一款合適的功能測試工具并培訓一支高素質(zhì)的工具使用隊伍無(wú)疑是至關(guān)重要的。盡管現階段存在少數不采用任何功能測試工具,從事功能測試外包項目的軟件服務(wù)企業(yè)。短期來(lái)看,這類(lèi)企業(yè)盈利狀況尚可,但長(cháng)久來(lái)看,它們極有可能被自動(dòng)化程度較高的軟件服務(wù)企業(yè)取代。
目前,用于功能測試的工具軟件有很多,針對不同架構軟件的工具也不斷推陳出新。這里重點(diǎn)介紹的是其中一個(gè)較為典型自動(dòng)化測試工具,即Mercury公司的WinRunner。
WinRunner是一種用于檢驗應用程序能否如期運行的企業(yè)級軟件功能測試工具。通過(guò)自動(dòng)捕獲、檢測和模擬用戶(hù)交互操作,WinRunner能識別出絕大多數軟件功能缺陷,從而確保那些跨越了多個(gè)功能點(diǎn)和數據庫的應用程序在發(fā)布時(shí)盡量不出現功能性故障。
WinRunner的特點(diǎn)在于: 與傳統的手工測試相比,它能快速、批量地完成功能點(diǎn)測試; 能針對相同測試腳本,執行相同的動(dòng)作,從而消除人工測試所帶來(lái)的理解上的誤差; 此外,它還能重復執行相同動(dòng)作,測試工作中最枯燥的部分可交由機器完成; 它支持程序風(fēng)格的測試腳本,一個(gè)高素質(zhì)的測試工程師能借助它完成流程極為復雜的測試,通過(guò)使用通配符、宏、條件語(yǔ)句、循環(huán)語(yǔ)句等,還能較好地完成測試腳本的重用; 它針對于大多數編程語(yǔ)言和Windows技術(shù),提供了較好的集成、支持環(huán)境,這對基于Windows平臺的應用程序實(shí)施功能測試而言帶來(lái)了極大的便利。
WinRunner的工作流程大致可以分為以下六個(gè)步驟:
1.識別應用程序的GUI
在WinRunner中,我們可以使用GUI Spy來(lái)識別各種GUI對象,識別后,WinRunner會(huì )將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其*區別是后者對每個(gè)測試腳本產(chǎn)生一個(gè)GUI文件,它能自動(dòng)建立、存儲、加載,推薦初學(xué)者選用這種模式。但是,這種模式不易于描述對象的改變,其效率比較低,因此對于一個(gè)有經(jīng)驗的測試人員來(lái)說(shuō)前者不失為一種更好的選擇,它只產(chǎn)生一個(gè)共享的GUI文件,這使得測試腳本更容易維護,且效率更高。
2.建立測試腳本
在建立測試腳本時(shí),一般先進(jìn)行錄制,然后在錄制形成的腳本中手工加入需要的TSL(與C語(yǔ)言類(lèi)似的測試腳本語(yǔ)言)。錄制腳本有兩種模式: Context Sensitive和Analog,選擇依據主要在于是否對鼠標軌跡進(jìn)行模擬,在需要回放時(shí)一般選用Analog。在錄制過(guò)程中這兩種模式可以通過(guò)F2鍵相互切換。
只要看看現代軟件的規模和功能點(diǎn)數就可以明白,功能測試早已跨越了單靠手工敲敲鍵盤(pán)、點(diǎn)點(diǎn)鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段,在軟件的能力驗證、能力規劃、性能調優(yōu)、缺陷修復等方面都發(fā)揮著(zhù)重要作用。
3.對測試腳本除錯(debug)
在WinRunner中有專(zhuān)門(mén)一個(gè)Debug Toolbar用于測試腳本除錯??梢允褂胹tep、pause、等來(lái)控制和跟蹤測試腳本和查看各種變量值。
4.在新版應用程序執行測試腳本
當應用程序有新版本發(fā)布時(shí),我們會(huì )對應用程序的各種功能包括新增功能進(jìn)行測試,這時(shí)當然不可能再來(lái)重新錄制和編寫(xiě)所有的測試腳本。我們可以使用已有的腳本,批量運行這些測試腳本測試舊的功能點(diǎn)是否正常工作??梢允褂靡粋€(gè)call命令來(lái)加載各測試腳本。還可在call命令中加各種TSL腳本來(lái)增加批量能力。
5.分析測試結果
分析測試結果在整個(gè)測試過(guò)程中最重要,通過(guò)分析可以發(fā)現應用程序的各種功能性缺陷。當運行完某個(gè)測試腳本后,會(huì )產(chǎn)生一個(gè)測試報告,從這個(gè)測試報告中我們能發(fā)現應用程序的功能性缺陷,能看到實(shí)際結果和期望結果之間的差異,以及在測試過(guò)程中產(chǎn)生的各類(lèi)對話(huà)框等。
6.回報缺陷(defect)
在分析完測試報告后,按照測試流程要回報應用程序的各種缺陷,然后將這些缺陷發(fā)給指定人,以便進(jìn)行修改和維護。
常用的功能測試方法
功能測試就是對產(chǎn)品的各功能進(jìn)行驗證,根據功能測試用例,逐項測試,檢查產(chǎn)品是否達到用戶(hù)要求的功能。
*的軟件測試方法有哪些?
隨著(zhù)軟件測試技術(shù)的不斷發(fā)展,測試方法也越來(lái)越多樣化,針對性更強;選擇合適的軟件測試方法可以讓我們事半功倍。以下是一些常用的軟件測試方法:β測試_Beta測試
β測試,英文是Beta testing。又稱(chēng)Beta測試,用戶(hù)驗收測試(UAT)。
β測試是軟件的多個(gè)用戶(hù)在一個(gè)或多個(gè)用戶(hù)的實(shí)際使用環(huán)境下進(jìn)行的測試。開(kāi)發(fā)者通常不在測試現場(chǎng),Beta測試不能由程序員或測試員完成。
當開(kāi)發(fā)和測試根本完成時(shí)所做的測試,而最終的錯誤和問(wèn)題需要在最終發(fā)行前找到。這種測試一般由最終用戶(hù)或其他人員完成,不能由程序員或測試員完成。
α測試_Alpha測試
α測試,英文是Alpha testing。又稱(chēng)Alpha測試.
Alpha測試是由一個(gè)用戶(hù)在開(kāi)發(fā)環(huán)境下進(jìn)行的測試,也可以是公司內部的用戶(hù)在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測試,Alpha測試不能由該系統的程序員或測試員完成。
在系統開(kāi)發(fā)接近完成時(shí)對應用系統的測試;測試后,仍然會(huì )有少量的設計變更。這種測試一般由最終用戶(hù)或其他人員來(lái)完成,不能由程序員或測試員完成。
可移植性測試
可移植性測試,英文是 testing。又稱(chēng)兼容性測試。
可移植性測試是指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。
用戶(hù)界面測試-UI測試
用戶(hù)界面測試,英文是User interface testing。又稱(chēng)UI測試。
用戶(hù)界面,英文是User interface。是指軟件中的可見(jiàn)外觀(guān)及其底層與用戶(hù)交互的部分(菜單、對話(huà)框、窗口和其它控件)。
用戶(hù)界面測試是指測試用戶(hù)界面的風(fēng)格是否滿(mǎn)足客戶(hù)要求,文字是否正確,頁(yè)面是否美觀(guān),文字,圖片組合是否完美,操作是否友好等等。UI 測試的目標是確保用戶(hù)界面會(huì )通過(guò)測試對象的功能來(lái)為用戶(hù)提供相應的訪(fǎng)問(wèn)或瀏覽功能。確保用戶(hù)界面符合公司或行業(yè)的標準。包括用戶(hù)友好性、人性化、易操作性測試。
用戶(hù)界面測試用戶(hù)分析軟件用戶(hù)界面的設計是否合乎用戶(hù)期望或要求。它常常包括菜單,對話(huà)框及對話(huà)框上所有按鈕,文字,出錯提示,幫助信息 (Menu 和Help content)等方面的測試。比如,測試Microsoft Excel中插入符號功能所用的對話(huà)框的大小,所有按鈕是否對齊,字符串字體大小,出錯信息內容和字體大小,工具欄位置/圖標等等。
冒煙測試
冒煙測試,英文是Smoke testing。
冒煙測試的名稱(chēng)可以理解為該種測試耗時(shí)短,僅用一袋煙功夫足夠了。也有人認為是形象地類(lèi)比新電路板功基本功能檢查。任何新電路板焊好后,先通電檢查,如果存在設計缺陷,電路板可能會(huì )短路,板子冒煙了。
冒煙測試的對象是每一個(gè)新編譯的需要正式測試的軟件版本,目的是確認軟件基本功能正常,可以進(jìn)行后續的正式測試工作。冒煙測試的執行者是版本編譯人員。
隨機測試
隨機測試,英文是Ad hoc testing。
隨機測試沒(méi)有書(shū)面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經(jīng)驗對軟件進(jìn)行功能和性能抽查。隨機測試是根據測試說(shuō)明書(shū)執行用例測試的重要補充手段,是保證測試覆蓋完整性的有效方式和過(guò)程。
隨機測試主要是對被測軟件的一些重要功能進(jìn)行復測,也包括測試那些當前的測試樣例(TestCase)沒(méi)有覆蓋到的部分。另外,對于軟件更新和新增加的功能要重點(diǎn)測試。重點(diǎn)對一些特殊點(diǎn)情況點(diǎn)、特殊的使用環(huán)境、并發(fā)性、進(jìn)行檢查。尤其對以前測試發(fā)現的重大Bug,進(jìn)行再次測試,可以結合回歸測試 ( testing)一起進(jìn)行。
本地化測試
本地化測試,英文是 testing。
本地化就是將軟件版本語(yǔ)言進(jìn)行更改,比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目標區域設置的軟件本地化質(zhì)量。本地化測試的環(huán)境是在本地化的操作系統上安裝本地化的軟件。從測試方法上可以分為基本功能測試,安裝/卸載測試,當地區域的軟硬件兼容性測試。測試的內容主要包括軟件本地化后的界面布局和軟件翻譯的語(yǔ)言質(zhì)量,包含軟件、文檔和聯(lián)機幫助等部分。
本地化能力測試
本地化能力測試,英文是 testing。
本地化能力測試是指不需要重新設計或修改代碼,將程序的用戶(hù)界面翻譯成任何目標語(yǔ)言的能力。為了降低本地化能力測試的成本,提高測試效率,本地化能力側是通常在軟件的偽本地化版本上進(jìn)行。
本地化能力測試中發(fā)現的典型錯誤包括:字符的硬編碼(即軟件中需要本地化的字符寫(xiě)在了代碼內部),對需要本地化的字符長(cháng)度設置了固定值,在軟件運行時(shí)以控件位置定位,圖標和位圖中包含了需要本地化的文本,軟件的用戶(hù)界面與文檔術(shù)語(yǔ)不一致等。
國際化測試
國際化測試,英文是 testing。又稱(chēng)國際化支持測試。
國際化測試的目的是測試軟件的國際化支持能力,發(fā)現軟件的國際化的潛在問(wèn)題,保證軟件在世界不同區域都能正常運行。國際化測試使用每種可能的國際輸入類(lèi)型,針對任何區域性或區域設置檢查產(chǎn)品的功能是否正常,軟件國際化測試的重點(diǎn)在于執行國際字符串的輸入/輸出功能。國際化測試數據必須包含東亞語(yǔ)言、德語(yǔ)、復雜腳本字符和英語(yǔ)(可選)的混合字符。
國際化支持測試是指驗證軟件程序在不同*或區域的平臺上也能夠如預期的那樣運行,而且還可以按照原設計尊重和支持使用當地常用的日期,字體,文字表示,特殊格式等等。比如,用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如,日文版的Microsoft Excel對話(huà)框是否顯示正確翻譯的日語(yǔ)?一旦來(lái)說(shuō)執行國際化支持測試的測試人員往往需要基本上了解這些*或地區的語(yǔ)言要求和期望行為是什么。
安裝測試
安裝測試,英文是 testing。
安裝測試是確保軟件在正常情況和異常情況下,例如,進(jìn)行首次安裝、升級、完整的或自定義的安裝都能進(jìn)行安裝的測試。異常情況包括磁盤(pán)空間不足、缺少目錄創(chuàng )建權限等場(chǎng)景。核實(shí)軟件在安裝后可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進(jìn)行安裝,安裝代碼提供安裝一些程序能夠運行的基礎數據。
白盒測試-結構測試-邏輯驅動(dòng)測試
白盒測試,英文是White Box Testing。又稱(chēng)結構測試或者邏輯驅動(dòng)測試。
白盒測試是把測試對象看作一個(gè)打開(kāi)的盒子。利用白盒測試法進(jìn)行動(dòng)態(tài)測試時(shí),需要測試軟件產(chǎn)品的內部結構和處理過(guò)程,不需測試軟件產(chǎn)品的功能。
白盒測試法的覆蓋標準有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
白盒測試是知道產(chǎn)品內部工作過(guò)程,可通過(guò)測試來(lái)檢測產(chǎn)品內部動(dòng)作是否按照規格說(shuō)明書(shū)的規定正常進(jìn)行,按照程序內部的結構測試程序,檢驗程序中的每條通路是否都有能按預定要求正確工作,而不顧它的功能,白盒測試的主要方法有邏輯驅動(dòng)、基路測試等,主要用于軟件驗證。
白盒測試常用工具有:Jtest、VcSmith、Jcontract、C++ Test、、logiscope。
黑盒測試-功能測試-數據驅動(dòng)測試
黑盒測試,英文是Black Box Testing。又稱(chēng)功能測試或者數據驅動(dòng)測試。
黑盒測試是根據軟件的規格對軟件進(jìn)行的測試,這類(lèi)測試不考慮軟件內部的運作原理,因此軟件對用戶(hù)來(lái)說(shuō)就像一個(gè)黑盒子。
軟件測試人員以用戶(hù)的角度,通過(guò)各種輸入和觀(guān)察軟件的各種輸出結果來(lái)發(fā)現軟件存在的缺陷,而不關(guān)心程序具體如何實(shí)現的一種軟件測試方法。
黑盒測試常用工具有:、winrunner、。
自動(dòng)化測試
自動(dòng)化測試,英文是Automated Testing。
使用自動(dòng)化測試工具來(lái)進(jìn)行測試,這類(lèi)測試一般不需要人干預,通常在GUI、性能等測試和功能測試中用得較多。通過(guò)錄制測試腳本,然后執行這個(gè)測試腳本來(lái)實(shí)現測試過(guò)程的自動(dòng)化。國內領(lǐng)先的自動(dòng)化測試服務(wù)提供商是澤眾軟件。自動(dòng)化測試工具有和TAR等。
回歸測試
回歸測試,英文是 testing。
回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上,軟件產(chǎn)生新版本,都需要進(jìn)行回歸測試,驗證以前發(fā)現和修復的錯誤是否在新軟件版本上再次出現。
根據修復好了的缺陷再重新進(jìn)行測試?;貧w測試的目的在于驗證以前出現過(guò)但已經(jīng)修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來(lái)出現時(shí)的步驟重新測試。通常確定所需的再測試的范圍時(shí)是比較困難的,特別當臨近產(chǎn)品發(fā)布日期時(shí)。因為為了修正某缺陷時(shí)必需更改源代碼,因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時(shí)不僅要服從缺陷原來(lái)出現時(shí)的步驟重新測試,而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進(jìn)行自動(dòng)化測試。
驗收測試
驗收測試,英文是 testing。
驗收測試是指系統開(kāi)發(fā)生命周期方法論的一個(gè)階段,這時(shí)相關(guān)的用戶(hù)或獨立測試人員根據測試計劃和結果對系統進(jìn)行測試和接收。它讓系統用戶(hù)決定是否接收系統。它是一項確定產(chǎn)品是否能夠滿(mǎn)足合同或用戶(hù)所規定需求的測試。
驗收測試一般有三種策略:正式驗收、非正式驗收或Alpha 測試、Beta 測試。
動(dòng)態(tài)測試
動(dòng)態(tài)測試,英文是Moment Testing。
動(dòng)態(tài)測試是指通過(guò)運行軟件來(lái)檢驗軟件的動(dòng)態(tài)行為和運行結果的正確性。
根據動(dòng)態(tài)測試在軟件開(kāi)發(fā)過(guò)程中所處的階段和作用,動(dòng)態(tài)測試可分為如下幾個(gè)步驟:
1、單元測試
2、集成測試
3、系統測試
4、驗收測試
5、回歸測試
探索測試
探索測試,英文是 Testing。
探索測試是指通常用于沒(méi)有產(chǎn)品說(shuō)明書(shū)的測試,這需要把軟件當作產(chǎn)品說(shuō)明書(shū)來(lái)看待,分步驟逐項探索軟件特性,記錄軟件執行情況,詳細描述功能,綜合利用靜態(tài)和動(dòng)態(tài)技術(shù)來(lái)進(jìn)行測試。探索測試人員只靠智能、洞察力和經(jīng)驗來(lái)對bug的位置進(jìn)行判斷,所以探索測試又被稱(chēng)為自由形式測試。
單元測試
單元測試,英文是Unit Testing。
單元測試是最微小規模的測試;以測試某個(gè)功能或代碼塊。典型地由程序員而非測試員來(lái)做,因為它需要知道內部程序設計和編碼的細節知識。這個(gè)工作不容易做好,除非應用系統有一個(gè)設計很好的體系結構; 還可能需要開(kāi)發(fā)測試驅動(dòng)器模塊或測試套具。
集成測試
集成測試,英文是 Testing。
集成測試是指一個(gè)應用系統的各個(gè)部件的聯(lián)合測試,以決定他們能否在一起共同工作并沒(méi)有沖突。部件可以是代碼塊、獨立的應用、網(wǎng)絡(luò )上的客戶(hù)端或服務(wù)器端程序。這種類(lèi)型的測試尤其與客戶(hù)服務(wù)器和分布式系統有關(guān)。一般集成測試以前,單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡(jiǎn)單的形式是:兩個(gè)已經(jīng)測試過(guò)的單元組合成一個(gè)組件,并且測試它們之間的接口。從這一層意義上講,組件是指多個(gè)單元的集成聚合。在現實(shí)方案中,許多單元組合成組件,而這些組件又聚合成程序的更大部分。方法是測試片段的組合,并最終擴展進(jìn)程,將您的模塊與其他組的模塊一起測試。*,將構成進(jìn)程的所有模塊一起測試。此外,如果程序由多個(gè)進(jìn)程組成,應該成對測試它們,而不是同時(shí)測試所有進(jìn)程。
集成測試識別組合單元時(shí)出現的問(wèn)題。通過(guò)使用要求在組合單元前測試每個(gè)單元,并確保每個(gè)單元的生存能力的測試計劃,可以知道在組合單元時(shí)所發(fā)現的任何錯誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數量減少到更簡(jiǎn)單的分析級別
系統測試
系統測試,英文是System Testing。
系統測試是基于系統整體需求說(shuō)明書(shū)的黑盒類(lèi)測試,應覆蓋系統所有聯(lián)合的部件。系統測試是針對整個(gè)產(chǎn)品系統進(jìn)行的測試,目的是驗證系統是否滿(mǎn)足了需求規格的定義,找出與需求規格不相符合或與之矛盾的地方。
系統測試的對象不僅僅包括需要測試的產(chǎn)品系統的軟件,還要包含軟件所依賴(lài)的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此,必須將系統中的軟件與各種依賴(lài)的資源結合起來(lái),在系統實(shí)際運行環(huán)境下來(lái)進(jìn)行測試。
端到端測試
端到端測試,英文是End to End Testing。
端到端測試類(lèi)似于系統測試,測試級的“宏大”的端點(diǎn),涉及整個(gè)應用系統環(huán)境在一個(gè)現實(shí)世界使用時(shí)的模擬情形的所有測試。例如與數據庫對話(huà),用網(wǎng)絡(luò )通訊,或與外部硬件、應用系統或適當的系統對話(huà)。端到端架構測試包含所有訪(fǎng)問(wèn)點(diǎn)的功能測試及性能測試。端到端架構測試實(shí)質(zhì)上是一種"灰盒"測試,一種集合了白盒測試和黑盒測試的優(yōu)點(diǎn)的測試方法。
健全測試
健全測試,英文是Sanity testing。
健全測試是指一個(gè)初始化的測試工作,以決定一個(gè)新的軟件版本測試是否足以執行下一步大的測試能力。例如,如果一個(gè)新版軟件每5分鐘與系統沖突,使系統陷于泥潭,說(shuō)明該軟件不夠“健全”,目前不具備進(jìn)一步測試的條件。
衰竭測試
衰竭測試,英文是Failure Testing。
衰竭測試是指軟件或環(huán)境的修復或更正后的“再測試”??赡芎茈y確定需要多少遍再次測試。尤其在接近開(kāi)發(fā)周期結束時(shí)。自動(dòng)測試工具對這類(lèi)測試尤其有用。
接受測試
接受測試,英文是Accept Testing。
接受測試是基于客戶(hù)或最終用戶(hù)的規格書(shū)的最終測試,或基于用戶(hù)一段時(shí)間的使用后,看軟件是否滿(mǎn)足客戶(hù)要求。一般從功能、用戶(hù)界面、性能、業(yè)務(wù)關(guān)聯(lián)性進(jìn)行測試。
負載測試
負載測試,英文是Load testing。
負載測試是測試一個(gè)應用在重負荷下的表現。例如測試一個(gè) Web 站點(diǎn)在大量的負荷下,何時(shí)系統的響應會(huì )退化或失敗,以發(fā)現設計上的錯誤或驗證系統的負載能力。在這種測試中,將使測試對象承擔不同的工作量,以評測和評估測試對象在不同工作量條件下的性能行為,以及持續正常運行的能力。
負載測試的目標是確定并確保系統在超出*預期工作量的情況下仍能正常運行。此外,負載測試還要評估性能特征,例如,響應時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。
強迫測試
強迫測試,英文是Force Testing。
強迫測試是在交替進(jìn)行負荷和性能測試時(shí)常用的術(shù)語(yǔ)。也用于描述象在異乎尋常的重載下的系統功能測試之類(lèi)的測試,如某個(gè)動(dòng)作或輸入大量的重復,大量數據的輸入,對一個(gè)數據庫系統大量的復雜查詢(xún)等。
壓力測試
壓力測試,英文是Stress Testing。和負載測試差不多。
壓力測試是一種基本的質(zhì)量保證行為,它是每個(gè)重要軟件測試工作的一部分。壓力測試的基本思路很簡(jiǎn)單:不是在常規條件下運行手動(dòng)或自動(dòng)測試,而是在計算機數量較少或系統資源匱乏的條件下運行測試。通常要進(jìn)行壓力測試的資源包括內部?jì)却?、CPU 可用性、磁盤(pán)空間和網(wǎng)絡(luò )帶寬等。一般用并發(fā)來(lái)做壓力測試。
性能測試
性能測試,英文是 Testing。
性能測試是在交替進(jìn)行負荷和強迫測試時(shí)常用的術(shù)語(yǔ)。理想的“性能測試”(和其他類(lèi)型的測試)應在需求文檔或質(zhì)量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。
通常驗證軟件的性能在正常環(huán)境和系統條件下重復使用是否還能滿(mǎn)足性能指標?;蛘邎绦型瑯尤蝿?wù)時(shí)新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時(shí)會(huì )不會(huì )流失(memory leak)。比如,驗證程序保存一個(gè)巨大的文件新版本不比舊版本慢。
可用性測試
可用性測試,英文是Practical Usability Testing。
可用性測試是對“用戶(hù)友好性”的測試。顯然這是主觀(guān)的,且將取決于目標最終用戶(hù)或客戶(hù)。用戶(hù)面談、調查、用戶(hù)對話(huà)的錄象和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。
卸載測試
卸載測試,英文是Uninstall Testing。
卸載測試是對軟件的全部、部分或升級卸載處理過(guò)程的測試。主要是測試軟件能否卸載,卸載是否干凈,對系統有無(wú)更改,在系統中的殘留與后來(lái)的生成文件如何處理等。還有原來(lái)更改的系統值是否修改回去
恢復測試
恢復測試,英文是Recovery testing。
恢復測試是測試一個(gè)系統從如下災難中能否很好地恢復,如遇到系統崩潰、硬件損壞或其他災難性問(wèn)題?;謴蜏y試指通過(guò)人為的讓軟件(或者硬件)出現故障來(lái)檢測系統是否能正確的恢復,通常關(guān)注恢復所需的時(shí)間以及恢復的程度。
恢復測試主要檢查系統的容錯能力。當系統出錯時(shí),能否在指定時(shí)間間隔內修正錯誤并重新啟動(dòng)系統?;謴蜏y試首先要采用各種辦法強迫系統失敗,然后驗證系統是否能盡快恢復。對于自動(dòng)恢復需驗證重新初始化()、檢查點(diǎn)( )、數據恢復(data recovery)和重新啟動(dòng) (restart)等機制的正確性;對于人工干預的恢復系統,還需估測平均修復時(shí)間,確定其是否在可接受的范圍內。
安全測試
安全測試,英文是Security Testing。
安全測試是測試系統在防止非授權的內部或外部用戶(hù)的訪(fǎng)問(wèn)或故意破壞等情況時(shí)怎么樣。這可能需要復雜的測試技術(shù)。安全測試檢查系統對非法侵入的防范能力。安全測試期間,測試人員假扮非法入侵者,采用各種辦法試圖突破防線(xiàn)。例如:
①想方設法截取或破譯口令;
②專(zhuān)門(mén)定做軟件破壞系統的保護機制;
③故意導致系統失敗,企圖趁恢復之機非法進(jìn)入;
④試圖通過(guò)瀏覽非保密數據,推導所需信息,等等。理論上講,只要有足夠的時(shí)間和資源,沒(méi)有不可進(jìn)入的系統。因此系統安全設計的準則是,使非法侵入的代價(jià)超過(guò)被保護信息的價(jià)值。此時(shí)非法侵入者已無(wú)利可圖。
兼容性測試
兼容測試,英文是 Testing。
兼容測試是測試軟件在一個(gè)特定的硬件/軟件/操作系統/網(wǎng)絡(luò )等環(huán)境下的性能如何。向上兼容向下兼容,軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。
比較測試
比較測試,英文是Compare Testing。
比較測試是指與競爭伙伴的產(chǎn)品的比較測試,如軟件的弱點(diǎn)、優(yōu)點(diǎn)或實(shí)力。來(lái)取長(cháng)補短,以增強產(chǎn)品的競爭力。
可接受性測試
可接受性測試,英文是 Testing。
可接受性測試是在把測試的版本交付測試*大范圍測試以前進(jìn)行的對最基本功能的簡(jiǎn)單測試。因為在把測試的版本交付測試*大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩定。必須滿(mǎn)足一些*要求。比如不會(huì )很容易程序就掛起或崩潰。如果一個(gè)新版本沒(méi)通過(guò)可測試性的驗證,就應該阻攔測試*花時(shí)間在該測試版本上測試。同時(shí)還要找到造成該版本不穩定的主要缺陷并督促盡快加以修正
邊界條件測試
邊界條件測試,英文是Boudary Testing。又稱(chēng)邊界值測試。
一種黑盒測試方法,適度等價(jià)類(lèi)分析方法的一種補充,由長(cháng)期的測試工作經(jīng)驗得知,大量的錯誤是發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試用例,可以查出更多的錯誤。
邊界條件測試是環(huán)繞邊界值的測試。通常意味著(zhù)測試軟件各功能是否能正確處理*值,最小值或者所設計軟件能夠處理的最長(cháng)的字符串等等。
強力測試
強力測試,英文是 Testing。
強力測試通常驗證軟件的性能在各種極端的環(huán)境和系統條件下是否還能正常工作?;蛘哒f(shuō)是驗證軟件的性能在各種極端環(huán)境和系統條件下的承受能力。比如,在*的硬盤(pán)驅動(dòng)器空間或系統記憶容量條件下,驗證程序重復執行打開(kāi)和保存一個(gè)巨大的文件1000次后也不會(huì )崩潰或死機。
裝配/安裝/配置測試
裝配/安裝/配置測試是驗證軟件程序在不同廠(chǎng)家的硬件上,所支持的不同語(yǔ)言的新舊版本平臺上,和不同方式安裝的軟件都能夠如預期的那樣正確運行。比如,把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上,再驗證所有功能都正常運行。
靜態(tài)測試
靜態(tài)測試,英文是Static Testing。
靜態(tài)測試指測試不運行的部分,例如測試產(chǎn)品說(shuō)明書(shū),對此進(jìn)行檢查和審閱.。靜態(tài)方法是指不運行被測程序本身,僅通過(guò)分析或檢查源程序的文法、結構、過(guò)程、接口等來(lái)檢查程序的正確性。靜態(tài)方法通過(guò)程序靜態(tài)特性的分析,找出欠缺和可疑之處,例如不匹配的參數、不適當的循環(huán)嵌套和分支嵌套、不允許的遞歸、未使用過(guò)的變量、空指針的引用和可疑的計算等。靜態(tài)測試結果可用于進(jìn)一步的查錯,并為測試用例選取提供指導。
靜態(tài)測試常用工具有:Logiscope、PRQA;
隱藏數據測試
隱藏數據測試在軟件驗收和確認階段是十分必要和重要的一部分。程序的質(zhì)量不僅僅通過(guò)用戶(hù)界面的可視化數據來(lái)驗證,而且必須包括遍歷系統的所有數據。
假設一個(gè)應用程序要求用戶(hù)兩條信息-----用戶(hù)名和密碼來(lái)創(chuàng )建帳戶(hù)。這個(gè)用戶(hù)輸入這兩條數據后保存。*,一個(gè)確認窗口將通過(guò)數據庫中找到這條數據來(lái)顯示用戶(hù)名和密碼給用戶(hù)。為了驗證所有的數據保存是否正確,一個(gè)QA測試人員會(huì )在這個(gè)確認窗口簡(jiǎn)單的查看下用戶(hù)名和密碼。如果他們成功了?假設數據庫記錄了第三條信息----創(chuàng )建日期,它可能不會(huì )出現在確認窗口,而只在存檔中才出現。如果創(chuàng )建日期保留的不正確,而QA測試人員只驗證屏幕上的數據,那么這個(gè)問(wèn)題就不可能被發(fā)現。創(chuàng )建日期可能就是一個(gè)bug,由于一個(gè)用戶(hù)帳戶(hù)保存了一個(gè)錯誤的日期到數據庫中,這個(gè)問(wèn)題也不可能會(huì )被引起注意,因為它被用戶(hù)界面所隱藏。這只是一個(gè)簡(jiǎn)單的例子,但是它卻演化出了一點(diǎn):隱藏數據測試的重要性。
等價(jià)劃分測試
等價(jià)劃分測試的英文是 partition testing。
等價(jià)劃分測試是根據等價(jià)類(lèi)設計測試用例的一種技術(shù)。是黑盒測試的典型方法之一,通過(guò)把被測試程序所有可能的輸入數據域劃分成若干部分。從每一部分中選取少數有代表性的數據作為測試用例,可有效減少測試次數,極大提高軟件測試效率,縮短軟件開(kāi)發(fā)周期.等價(jià)類(lèi)劃分測試的目的就是為了在有限的測試資源的情況下,用少量有代表性的數據得到比較好的測試效果。有效等價(jià)類(lèi)盒無(wú)效等價(jià)類(lèi)。有效等價(jià)類(lèi)中的數據代表的是一組符合需求文檔的正確的有意義數據。無(wú)效等價(jià)類(lèi)則正相反。
判定表
判定表的英文是decision table,是指一個(gè)表格,用于顯示條件和條件導致動(dòng)作的集合。
定義:判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
判定表的優(yōu)點(diǎn):能夠將復雜的問(wèn)題按照各種可能的情況全部列舉出來(lái),簡(jiǎn)明并避免遺漏。因此,利用判定表能夠設計出完整的測試用例集合。
在一些數據處理問(wèn)題當中,某些操作的實(shí)施依賴(lài)于多個(gè)邏輯條件的組合,即:針對不同邏輯條件的組合值,分別執行不同的操作。判定表很適合于處理這類(lèi)問(wèn)題
深度測試
深度測試的英文Depth test ,是指執行一個(gè)產(chǎn)品的一個(gè)特性的所有細節,但不測試所有特性。
當比較函數返回真的時(shí)候才顯示出效果來(lái)。必須啟用“#深度測試”,才能執行測試。不使用的時(shí)候需要關(guān)閉。
基于設計的測試
基于設計的測試的英文是design-based testing,是根據軟件的構架或詳細設計引出測試用例的一種方法。
一種基于設計模型的測試方法(Model Based TestIng System,MATIS).該方法利用用戶(hù)界面自動(dòng)生成方法,把設計模型中的類(lèi)屬性定義和實(shí)現中的控件屬性組織在一起,構建描述界面的邏輯對照表,輔助測試腳本引擎執行自動(dòng)測試腳本.借助設計模型中擴展的類(lèi)定義,MATIS方法可以自動(dòng)生成測試用例和測試數據。
文檔測試
軟件測試的方法有哪些?
測試的有2種方法
答:黑盒測試和白盒測試
黑盒:這種方法是把測試對象看做一個(gè)黑盒子,測試人員完全不考慮程序內部的邏輯結構和內部特性,只依據程序的需求規格說(shuō)明書(shū),檢查程序的功能是否符合它的功能說(shuō)明。
黑盒測試又叫做功能測試或數據驅動(dòng)測試。
白盒:此方法把測試對象看做一個(gè)透明的盒子,它允許測試人員利用程序內部的邏輯結構及有關(guān)信息,設計或選擇測試用例,對程序所有邏輯路徑進(jìn)行測試。
通過(guò)在不同點(diǎn)檢查程序的狀態(tài),確定實(shí)際的狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱(chēng)為結構測試或邏輯驅動(dòng)測試。
軟件測試按過(guò)程分為三個(gè)步驟
答:?jiǎn)卧獪y試:?jiǎn)卧獪y試又稱(chēng)模塊測試,是針對軟件設計的最小單位—程序模塊,進(jìn)行正確性檢驗的測試工作。其目的在于發(fā)現各模塊內部可能存在的各種差錯。
單元測試需要從程序的內部結構出發(fā)設計測試用例。多個(gè)模塊可以平行地獨立進(jìn)行單元測試。
集成測試:在運行(可能是不完整)的應用中保證軟件單元被結合后能正常操作的測試執行的階段
系統測試:當應用作為整體運行時(shí)的測試執行階段
軟件測試的步驟是什么?
1)測試過(guò)程按4個(gè)步驟進(jìn)行,即單元測試()、集成測試()、確認測試()和系統測試()及發(fā)版測試。
2)開(kāi)始是單元測試,集中對用源代碼實(shí)現的每一個(gè)程序單元進(jìn)行測試,檢查各個(gè)程序模塊是否正確地實(shí)現了規定的功能。
3)集成測試把已測試過(guò)的模塊組裝起來(lái),主要對與設計相關(guān)的軟件體系結構的構造進(jìn)行測試。
4)確認測試則是要檢查已實(shí)現的軟件是否滿(mǎn)足了需求規格說(shuō)明中確定了的各種需求,以及軟件配置是否完全、正確。
應該考慮進(jìn)行如何測試的測試方法
黑盒測試()——不考慮內部設計和代碼,根據需求和功能進(jìn)行測試。
白盒測試()——根據應用軟件的代碼的內部邏輯,按照代碼的語(yǔ)句、分支、路徑和條件進(jìn)行測試。
功能測試()——對一個(gè)應用軟件的功能模塊進(jìn)行黑盒測試。這種測試應當由測試人員進(jìn)行。但這并不意味著(zhù)程序員在推出軟件之前不進(jìn)行代碼檢查。(這一原則適用于所有的測試階段。)
系統測試——針對全部需求說(shuō)明進(jìn)行黑盒測試,包括系統中所有的部件。
回歸測試()——每當軟件經(jīng)過(guò)了整理、修改、或者其環(huán)境發(fā)生變化,都重復進(jìn)行測試。很難說(shuō)需要進(jìn)行多少次回歸測試,特別是是到了開(kāi)發(fā)周期的*階段。進(jìn)行此種測試,特別適于使用自動(dòng)測試工具。
負荷試驗()——在大負荷條件下對應用軟件進(jìn)行測試。例如測試一個(gè)網(wǎng)站在不同負荷情況下的狀況,以確定在什么情況下系統響應速度下降或是出現故障。
壓力測試()——經(jīng)??梢耘c“負荷測試”或“性能測試”相互代替。這種測試是用來(lái)檢查系統在下列條件下的情況:在非正常的巨大負荷下、某些動(dòng)作和輸入大量重復、輸入大數、對數據庫進(jìn)行非常復雜的查詢(xún),等等。
性能測試()——經(jīng)??梢耘c“壓力測試”或“負荷測試”相互代替。理想的“性能測試”(也包括其他任何類(lèi)型的測試)都應在質(zhì)量保障和測試計劃的文檔終予以規定。
可用性測試()——是專(zhuān)為“對用戶(hù)友好”的特性進(jìn)行測試。這是一種主觀(guān)的感覺(jué),取決于最終用戶(hù)或顧客??梢赃M(jìn)行用戶(hù)會(huì )見(jiàn)、檢查、對用戶(hù)會(huì )議錄像、或者使用其他技術(shù)。程序員和測試人員通常不參加可用性測試。
安裝/卸載測試(install/)——對安裝/卸載進(jìn)行測試(包括全部、部分、升級操作)。
安全測試()——測試系統在應付非授權的內部/外部訪(fǎng)問(wèn)、故意的損壞時(shí)的防護情況。這需要精密復雜的測試技術(shù)。
兼容性測試()——測試在特殊的硬件/軟件/操作系統/網(wǎng)絡(luò )環(huán)境下的軟件表現。
α測試()——在開(kāi)發(fā)一個(gè)應用軟件即將完成時(shí)所進(jìn)行的測試。此時(shí)還允許有較小的設計修改。通常由最終用戶(hù)或其他人進(jìn)行這種測試,而不是由程序員和測試人員來(lái)進(jìn)行。
β測試()——當開(kāi)發(fā)和測試已基本完成,需要在正式發(fā)行之前*尋找毛病而進(jìn)行的測試。通常由最終用戶(hù)或其他人進(jìn)行這種測試,而不是由程序員和測試人員來(lái)進(jìn)行。
奇米在线7777在线精品|国产成人精品免费视|精品无码不卡一区二区三区|国内综合精品午夜久久资源|亚洲视频在线观看..