軟件測試方法大全|49種測試方法羽利,你知道幾個这弧?

β測試_Beta測試

β測試虚汛,英文是Beta testing。又稱Beta測試蛋辈,用戶驗(yàn)收測試(UAT)将谊。

β測試是軟件的多個用戶在一個或多個用戶的實(shí)際使用環(huán)境下進(jìn)行的測試尊浓。開發(fā)者通常不在測試現(xiàn)場栋齿,Beta測試不能由程序員或測試員完成。

當(dāng)開發(fā)和測試根本完成時所做的測試柒巫,而最終的錯誤和問題需要在最終發(fā)行前找到谷丸。這種測試一般由最終用戶或其他人員員完成刨疼,不能由程序員或測試員完成揩慕。

α測試_Alpha測試

α測試,英文是Alpha testing拴鸵。又稱Alpha測試劲藐。

Alpha測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試,也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測試兄渺,Alpha測試不能由該系統(tǒng)的程序員或測試員完成挂谍。

在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試;測試后口叙,仍然會有少量的設(shè)計(jì)變更嗅战。這種測試一般由最終用戶或其他人員來完成仗哨,不能由程序員或測試員完成铅辞。

可移植性測試

可移植性測試斟珊,英文是Portability testing囤踩。又稱兼容性測試∽凵鳎可移植性測試是指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上示惊。

用戶界面測試-UI測試

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

用戶界面塘秦,英文是User interface嗤形。是指軟件中的可見外觀及其底層與用戶交互的部分(菜單赋兵、對話框搔预、窗口和其它控件)拯田。

用戶界面測試是指測試用戶界面的風(fēng)格是否滿足客戶要求船庇,文字是否正確,頁面是否美觀臣淤,文字邑蒋,圖片組合是否完美按厘,操作是否友好等等逮京。UI 測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覽功能懒棉。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)漓藕。包括用戶友好性、人性化揍诽、易操作性測試暑脆。

用戶界面測試用戶分析軟件用戶界面的設(shè)計(jì)是否合乎用戶期望或要求添吗。它常常包括菜單,對話框及對話框上所有按鈕妓美,文字壶栋,出錯提示普监,幫助信息 (Menu 和Help content)等方面的測試凯正。比如廊散,測試Microsoft Excel中插入符號功能所用的對話框的大小奸汇,所有按鈕是否對齊往声,字符串字體大小浩销,出錯信息內(nèi)容和字體大小慢洋,工具欄位置/圖標(biāo)等等。

冒煙測試

冒煙測試败明,英文是Smoke testing妻顶。

冒煙測試的名稱可以理解為該種測試耗時短讳嘱,僅用一袋煙功夫足夠了沥潭。也有人認(rèn)為是形象地類比新電路板功基本功能檢查。任何新電路板焊好后汇恤,先通電檢查屁置,如果存在設(shè)計(jì)缺陷蓝角,電路板可能會短路使鹅,板子冒煙了昌抠。

冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本炊苫,目的是確認(rèn)軟件基本功能正常侨艾,可以進(jìn)行后續(xù)的正式測試工作唠梨。冒煙測試的執(zhí)行者是版本編譯人員。

隨機(jī)測試

隨機(jī)測試茬故,英文是Ad hoc testing磺芭。

隨機(jī)測試沒有書面測試用例钾腺、記錄期望結(jié)果垮庐、檢查列表哨查、腳本或指令的測試。主要是根據(jù)測試者的經(jīng)驗(yàn)對軟件進(jìn)行功能和性能抽查邮府。隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段褂傀,是保證測試覆蓋完整性的有效方式和過程。

隨機(jī)測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測沙兰,也包括測試那些當(dāng)前的測試樣例(TestCase)沒有覆蓋到的部分。另外,對于軟件更新和新增加的功能要重點(diǎn)測試粟焊。重點(diǎn)對一些特殊點(diǎn)情況點(diǎn)项棠、特殊的使用環(huán)境香追、并發(fā)性翅阵、進(jìn)行檢查。尤其對以前測試發(fā)現(xiàn)的重大Bug岖圈,進(jìn)行再次測試蜂科,可以結(jié)合回歸測試 (Regressive testing)一起進(jìn)行。

本地化測試

本地化測試才菠,英文是Localization testing赋访。

本地化就是將軟件版本語言進(jìn)行更改蚓耽,比如將英文的windows改成中文的windows就是本地化步悠。本地化測試的對象是軟件的本地化版本鼎兽。本地化測試的目的是測試特定目標(biāo)區(qū)域設(shè)置的軟件本地化質(zhì)量接奈。本地化測試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟件序宦。從測試方法上可以分為基本功能測試互捌,安裝/卸載測試行剂,當(dāng)?shù)貐^(qū)域的軟硬件兼容性測試厚宰。測試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語言質(zhì)量铲觉,包含軟件撵幽、文檔和聯(lián)機(jī)幫助等部分盐杂。

本地化能力測試

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

本地化能力測試是指不需要重新設(shè)計(jì)或修改代碼秧均,將程序的用戶界面翻譯成任何目標(biāo)語言的能力目胡。為了降低本地化能力測試的成本誉己,提高測試效率巨双,本地化能力側(cè)是通常在軟件的偽本地化版本上進(jìn)行霉祸。

本地化能力測試中發(fā)現(xiàn)的典型錯誤包括:字符的硬編碼(即軟件中需要本地化的字符寫在了代碼內(nèi)部)慢宗,對需要本地化的字符長度設(shè)置了國定值镜沽,在軟件運(yùn)行時以控件位置定位缅茉,圖標(biāo)和位圖中包含了需要本地化的文本男摧,軟件的用戶界面與文檔術(shù)語不一致等耗拓。

國際化測試

國際化測試蔬蕊,英文是International testing岸夯。又稱國際化支持測試们妥。

國際化測試的目的是測試軟件的國際化支持能力监婶,發(fā)現(xiàn)軟件的國際化的潛在問題煮盼,保證軟件在世界不同區(qū)域都能正常運(yùn)行僵控。國際化測試使用每種可能的國際輸入類型报破,針對任何區(qū)域性或區(qū)域設(shè)置檢查產(chǎn)品的功能是否正常充易,軟件國際化測試的重點(diǎn)在于執(zhí)行國際字符串的輸入/輸出功能盹靴。國際化測試數(shù)據(jù)必須包含東亞語言鹉究、德語自赔、復(fù)雜腳本字符和英語(可選)的混合字符绍妨。

國際化支持測試是指驗(yàn)證軟件程序在不同國家或區(qū)域的平臺上也能夠如預(yù)期的那樣運(yùn)行他去,而且還可以按照原設(shè)計(jì)尊重和支持使用當(dāng)?shù)爻S玫娜掌谠植猓煮w媳搪,文字表示秦爆,特殊格式等等等限。比如望门,用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如桐早,日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執(zhí)行國際化支持測試的測試人員往往需要基本上了解這些國家或地區(qū)的語言要求和期望行為是什么纫事。

安裝測試

安裝測試勘畔,英文是Installing testing。

安裝測試是確保軟件在正常情況和異常情況下丽惶,例如炫七,進(jìn)行首次安裝、升級钾唬、完整的或自定義的安裝都能進(jìn)行安裝的測試万哪。異常情況包括磁盤空間不足抡秆、缺少目錄創(chuàng)建權(quán)限等場景奕巍。核實(shí)軟件在安裝后可立即正常運(yùn)行。安裝測試包括測試安裝代碼以及安裝手冊儒士。安裝手冊提供如何進(jìn)行安裝的止,安裝代碼提供安裝一些程序能夠運(yùn)行的基礎(chǔ)數(shù)據(jù)。

白盒測試-結(jié)構(gòu)測試-邏輯驅(qū)動測試

白盒測試着撩,英文是White Box Testing诅福。又稱結(jié)構(gòu)測試或者邏輯驅(qū)動測試。

白盒測試是把測試對象看作一個打開的盒子拖叙。利用白盒測試法進(jìn)行動態(tài)測試時氓润,需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程,不需測試軟件產(chǎn)品的功能薯鳍。

白盒測試法的覆蓋標(biāo)準(zhǔn)有邏輯覆蓋咖气、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋崩溪、條件覆蓋浅役、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋悯舟。

白盒測試是知道產(chǎn)品內(nèi)部工作過程担租,可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行砸民,按照程序內(nèi)部的結(jié)構(gòu)測試程序抵怎,檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作,而不顧它的功能岭参,白盒測試的主要方法有邏輯驅(qū)動反惕、基路測試等,主要用于軟件驗(yàn)證演侯。

白盒測試常用工具有:Jtest姿染、VcSmith、Jcontract秒际、C++ Test悬赏、CodeWizard、logiscope娄徊。

黑盒測試-功能測試-數(shù)據(jù)驅(qū)動測試

黑盒測試闽颇,英文是Black Box Testing。又稱功能測試或者數(shù)據(jù)驅(qū)動測試寄锐。

黑盒測試是根據(jù)軟件的規(guī)格對軟件進(jìn)行的測試兵多,這類測試不考慮軟件內(nèi)部的運(yùn)作原理,因此軟件對用戶來說就像一個黑盒子橄仆。軟件測試人員以用戶的角度剩膘,通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺陷,而不關(guān)心程序具體如何實(shí)現(xiàn)的一種軟件測試方法盆顾。

黑盒測試常用工具有:AutoRunner怠褐、winrunner、loadrunner您宪。

自動化測試(1079636098:技術(shù)交流群推薦)

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

使用自動化測試工具來進(jìn)行測試蚕涤,這類測試一般不需要人干預(yù)筐赔,通常在GUI、性能等測試和功能測試中用得較多揖铜。通過錄制測試腳本茴丰,然后執(zhí)行這個測試腳本來實(shí)現(xiàn)測試過程的自動化。國內(nèi)領(lǐng)先的自動化測試服務(wù)提供商是澤眾軟件。自動化測試工具有AutoRunner和TAR等贿肩。

回歸測試

回歸測試峦椰,英文是Regression testing。

回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性汰规。理論上汤功,軟件產(chǎn)生新版本,都需要進(jìn)行回歸測試溜哮,驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再次出現(xiàn)滔金。

根據(jù)修復(fù)好了的缺陷再重新進(jìn)行測試∶ぃ回歸測試的目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)餐茵。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的述吸,特別當(dāng)臨近產(chǎn)品發(fā)布日期時忿族。因?yàn)闉榱诵拚橙毕輹r必需更改源代碼,因而就有可能影響這部分源代碼所控制的功能蝌矛。所以在驗(yàn)證修好的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試道批,而且還要測試有可能受影響的所有功能。因此應(yīng)當(dāng)鼓勵對所有回歸測試用例進(jìn)行自動化測試入撒。

驗(yàn)收測試

驗(yàn)收測試隆豹,英文是Acceptance testing。

驗(yàn)收測試是指系統(tǒng)開發(fā)生命周期方法論的一個階段衅金,這時相關(guān)的用戶或獨(dú)立測試人員根據(jù)測試計(jì)劃和結(jié)果對系統(tǒng)進(jìn)行測試和接收噪伊。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項(xiàng)確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試氮唯。

驗(yàn)收測試一般有三種策略:正式驗(yàn)收鉴吹、非正式驗(yàn)收活A(yù)lpha 測試、Beta 測試惩琉。

動態(tài)測試

動態(tài)測試豆励,英文是Moment Testing。

動態(tài)測試是指通過運(yùn)行軟件來檢驗(yàn)軟件的動態(tài)行為和運(yùn)行結(jié)果的正確性瞒渠。根據(jù)動態(tài)測試在軟件開發(fā)過程中所處的階段和作用良蒸,動態(tài)測試可分為如下幾個步驟:

1、單元測試

2伍玖、集成測試

3嫩痰、系統(tǒng)測試

4、驗(yàn)收測試

5窍箍、回歸測試

探索測試

探索測試串纺,英文是Exploratory Testing丽旅。

探索測試是指通常用于沒有產(chǎn)品說明書的測試,這需要把軟件當(dāng)作產(chǎn)品說明書來看待纺棺,分步驟逐項(xiàng)探索軟件特性榄笙,記錄軟件執(zhí)行情況,詳細(xì)描述功能祷蝌,綜合利用靜態(tài)和動態(tài)技術(shù)來進(jìn)行測試茅撞。探索測試人員只靠智能、洞察力和經(jīng)驗(yàn)來對bug的位置進(jìn)行判斷,所以探索測試又被稱為自由形式測試巨朦。

單元測試

單元測試米丘,英文是Unit Testing。

單元測試是最微小規(guī)模的測試;以測試某個功能或代碼塊罪郊。典型地由程序員而非測試員來做蠕蚜,因?yàn)樗枰纼?nèi)部程序設(shè)計(jì)和編碼的細(xì)節(jié)知識尚洽。這個工作不容易做好悔橄,除非應(yīng)用系統(tǒng)有一個設(shè)計(jì)很好的體系結(jié)構(gòu); 還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。

集成測試

集成測試腺毫,英文是Integration Testing癣疟。

集成測試是指一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試,以決定他們能否在一起共同工作并沒有沖突潮酒。部件可以是代碼塊睛挚、獨(dú)立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序急黎。這種類型的測試尤其與客戶服務(wù)器和分布式系統(tǒng)有關(guān)扎狱。一般集成測試以前,單元測試需要完成勃教。

集成測試是單元測試的邏輯擴(kuò)展淤击。它的最簡單的形式是:兩個已經(jīng)測試過的單元組合成一個組件,并且測試它們之間的接口故源。從這一層意義上講污抬,組件是指多個單元的集成聚合。在現(xiàn)實(shí)方案中绳军,許多單元組合成組件印机,而這些組件又聚合成程序的更大部分。方法是測試片段的組合门驾,并最終擴(kuò)展進(jìn)程射赛,將您的模塊與其他組的模塊一起測試。最后奶是,將構(gòu)成進(jìn)程的所有模塊一起測試楣责。此外顷蟆,如果程序由多個進(jìn)程組成,應(yīng)該成對測試它們腐魂,而不是同時測試所有進(jìn)程帐偎。

集成測試識別組合單元時出現(xiàn)的問題。通過使用要求在組合單元前測試每個單元蛔屹,并確保每個單元的生存能力的測試計(jì)劃削樊,可以知道在組合單元時所發(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)進(jìn)行的測試,目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義豪嗽,找出與需求規(guī)格不相符合或與之矛盾的地方谴蔑。

系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件,還要包含軟件所依賴的硬件龟梦、外設(shè)甚至包括某些數(shù)據(jù)隐锭、某些支持軟件及其接口等。因此计贰,必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來钦睡,在系統(tǒng)實(shí)際運(yùn)行環(huán)境下來進(jìn)行測試。

端到端測試

端到端測試躁倒,英文是End to End Testing荞怒。

端到端測試類似于系統(tǒng)測試,測試級的“宏大”的端點(diǎn)秧秉,涉及整個應(yīng)用系統(tǒng)環(huán)境在一個現(xiàn)實(shí)世界使用時的模擬情形的所有測試褐桌。例如與數(shù)據(jù)庫對話,用網(wǎng)絡(luò)通訊福贞,或與外部硬件撩嚼、應(yīng)用系統(tǒng)或適當(dāng)?shù)南到y(tǒng)對話。端到端架構(gòu)測試包含所有訪問點(diǎn)的功能測試及性能測試挖帘。端到端架構(gòu)測試實(shí)質(zhì)上是一種"灰盒"測試完丽,一種集合了白盒測試和黑盒測試的優(yōu)點(diǎn)的測試方法。

健全測試

健全測試拇舀,英文是Sanity testing逻族。

健全測試是指一個初始化的測試工作,以決定一個新的軟件版本測試是否足以執(zhí)行下一步大的測試努力骄崩。例如聘鳞,如果一個新版軟件每5分鐘與系統(tǒng)沖突薄辅,使系統(tǒng)陷于泥潭,說明該軟件不夠“健全”抠璃,目前不具備進(jìn)一步測試的條件站楚。

衰竭測試

衰竭測試,英文是Failure Testing搏嗡。

衰竭測試是指軟件或環(huán)境的修復(fù)或更正后的“再測試”窿春。可能很難確定需要多少遍再次測試采盒。尤其在接近開發(fā)周期結(jié)束時旧乞。自動測試工具對這類測試尤其有用。

接受測試

接受測試磅氨,英文是Accept Testing尺栖。

接受測試是基于客戶或最終用戶的規(guī)格書的最終測試,或基于用戶一段時間的使用后烦租,看軟件是否滿足客戶要求延赌。一般從功能、用戶界面左权、性能皮胡、業(yè)務(wù)關(guān)聯(lián)性進(jìn)行測試。

負(fù)載測試

負(fù)載測試赏迟,英文是Load testing。

負(fù)載測試是測試一個應(yīng)用在重負(fù)荷下的表現(xiàn)蠢棱。例如測試一個 Web 站點(diǎn)在大量的負(fù)荷下锌杀,何時系統(tǒng)的響應(yīng)會退化或失敗,以發(fā)現(xiàn)設(shè)計(jì)上的錯誤或驗(yàn)證系統(tǒng)的負(fù)載能力泻仙。在這種測試中糕再,將使測試對象承擔(dān)不同的工作量,以評測和評估測試對象在不同工作量條件下的性能行為玉转,以及持續(xù)正常運(yùn)行的能力突想。

負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外究抓,負(fù)載測試還要評估性能特征猾担,例如,響應(yīng)時間刺下、事務(wù)處理速率和其他與時間相關(guān)的方面绑嘹。

強(qiáng)迫測試

強(qiáng)迫測試,英文是Force Testing橘茉。

強(qiáng)迫測試是在交替進(jìn)行負(fù)荷和性能測試時常用的術(shù)語工腋。也用于描述象在異乎尋常的重載下的系統(tǒng)功能測試之類的測試姨丈,如某個動作或輸入大量的重復(fù),大量數(shù)據(jù)的輸入擅腰,對一個數(shù)據(jù)庫系統(tǒng)大量的復(fù)雜查詢等蟋恬。

壓力測試

壓力測試,英文是Stress Testing趁冈。和負(fù)載測試差不多筋现。

壓力測試是一種基本的質(zhì)量保證行為,它是每個重要軟件測試工作的一部分箱歧。壓力測試的基本思路很簡單:不是在常規(guī)條件下運(yùn)行手動或自動測試矾飞,而是在計(jì)算機(jī)數(shù)量較少或系統(tǒng)資源匱乏的條件下運(yùn)行測試。通常要進(jìn)行壓力測試的資源包括內(nèi)部內(nèi)存呀邢、CPU 可用性洒沦、磁盤空間和網(wǎng)絡(luò)帶寬等。一般用并發(fā)來做壓力測試价淌。

性能測試

性能測試申眼,英文是Performance Testing。

性能測試是在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時常用的術(shù)語蝉衣。理想的“性能測試”(和其他類型的測試)應(yīng)在需求文檔或質(zhì)量保證括尸、測試計(jì)劃中定義。性能測試一般包括負(fù)載測試和壓力測試病毡。

通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)濒翻。或者執(zhí)行同樣任務(wù)時新版本不比舊版本慢啦膜。一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時會不會流失(memory leak)有送。比如,驗(yàn)證程序保存一個巨大的文件新版本不比舊版本慢僧家。

可用性測試

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

可用性測試是對“用戶友好性”的測試八拱。顯然這是主觀的阵赠,且將取決于目標(biāo)最終用戶或客戶。用戶面談肌稻、調(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)的容錯能力。當(dāng)系統(tǒng)出錯時烈掠,能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)羞秤。恢復(fù)測試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗左敌,然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)瘾蛋。對于自動恢復(fù)需驗(yàn)證重新初始化(reinitialization)、檢查點(diǎn)(checkpointing mechanisms)矫限、數(shù)據(jù)恢復(fù)(data recovery)和重新啟動 (restart)等機(jī)制的正確性哺哼;對于人工干預(yù)的恢復(fù)系統(tǒng),還需估測平均修復(fù)時間奇唤,確定其是否在可接受的范圍內(nèi)幸斥。

安全測試

安全測試,英文是Security Testing咬扇。

安全測試是測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復(fù)雜的測試技術(shù)廊勃。安全測試檢查系統(tǒng)對非法侵入的防范能力懈贺。安全測試期間,測試人員假扮非法入侵者坡垫,采用各種辦法試圖突破防線梭灿。例如:

①想方設(shè)法截取或破譯口令;

②專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制冰悠;

③故意導(dǎo)致系統(tǒng)失敗堡妒,企圖趁恢復(fù)之機(jī)非法進(jìn)入;

④試圖通過瀏覽非保密數(shù)據(jù)溉卓,推導(dǎo)所需信息皮迟,等等搬泥。理論上講,只要有足夠的時間和資源伏尼,沒有不可進(jìn)入的系統(tǒng)忿檩。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是,使非法侵入的代價超過被保護(hù)信息的價值爆阶。此時非法侵入者已無利可圖燥透。

兼容性測試

兼容測試,英文是Compatibility Testing辨图。

兼容測試是測試軟件在一個特定的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)等環(huán)境下的性能如何班套。向上兼容向下兼容,軟件兼容硬件兼容故河。軟件的兼容性有很多需要考慮的地方吱韭。

比較測試

比較測試,英文是Compare Testing忧勿。

比較測試是指與競爭伙伴的產(chǎn)品的比較測試杉女,如軟件的弱點(diǎn)、優(yōu)點(diǎn)或?qū)嵙υ砣¢L補(bǔ)短熏挎,以增強(qiáng)產(chǎn)品的競爭力。

可接受性測試

可接受性測試晌砾,英文是Acceptability Testing坎拐。

可接受性測試是在把測試的版本交付測試部門大范圍測試以前進(jìn)行的對最基本功能的簡單測試。因?yàn)樵诎褱y試的版本交付測試部門大范圍測試以前應(yīng)該先驗(yàn)證該版本對于所測試的功能基本上比較穩(wěn)定养匈。必須滿足一些最低要求哼勇。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗(yàn)證呕乎,就應(yīng)該阻攔測試部門花時間在該測試版本上測試积担。同時還要找到造成該版本不穩(wěn)定的主要缺陷并督促盡快加以修正。

邊界條件測試

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

一種黑盒測試方法湿刽,適度等價類分析方法的一種補(bǔ)充,由長期的測試工作經(jīng)驗(yàn)得知的烁,大量的錯誤是發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設(shè)計(jì)測試用例诈闺,可以查出更多的錯誤渴庆。

邊界條件測試是環(huán)繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理最大值,最小值或者所設(shè)計(jì)軟件能夠處理的最長的字符串等等襟雷。

強(qiáng)力測試

強(qiáng)力測試刃滓,英文是Mightiness Testing。

強(qiáng)力測試通常驗(yàn)證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作嗤军∽⒂或者說是驗(yàn)證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如叙赚,在最低的硬盤驅(qū)動器空間或系統(tǒng)記憶容量條件下老客,驗(yàn)證程序重復(fù)執(zhí)行打開和保存一個巨大的文件1000次后也不會崩潰或死機(jī)。

裝配/安裝/配置測試

裝配/安裝/配置測試是驗(yàn)證軟件程序在不同廠家的硬件上震叮,所支持的不同語言的新舊版本平臺上胧砰,和不同方式安裝的軟件都能夠如預(yù)期的那樣正確運(yùn)行。比如苇瓣,把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上尉间,再驗(yàn)證所有功能都正常運(yùn)行。

靜態(tài)測試

靜態(tài)測試击罪,英文是Static Testing哲嘲。

靜態(tài)測試指測試不運(yùn)行的部分,例如測試產(chǎn)品說明書媳禁,對此進(jìn)行檢查和審閱眠副。靜態(tài)方法是指不運(yùn)行被測程序本身,僅通過分析或檢查源程序的文法竣稽、結(jié)構(gòu)囱怕、過程、接口等來檢查程序的正確性毫别。靜態(tài)方法通過程序靜態(tài)特性的分析娃弓,找出欠缺和可疑之處,例如不匹配的參數(shù)岛宦、不適當(dāng)?shù)难h(huán)嵌套和分支嵌套台丛、不允許的遞歸、未使用過的變量砾肺、空指針的引用和可疑的計(jì)算等齐佳。靜態(tài)測試結(jié)果可用于進(jìn)一步的查錯,并為測試用例選取提供指導(dǎo)债沮。

靜態(tài)測試常用工具有:Logiscope、PRQA本鸣。

隱藏?cái)?shù)據(jù)測試

隱藏?cái)?shù)據(jù)測試在軟件驗(yàn)收和確認(rèn)階段是十分必要和重要的一部分疫衩。程序的質(zhì)量不僅僅通過用戶界面的可視化數(shù)據(jù)來驗(yàn)證,而且必須包括遍歷系統(tǒng)的所有數(shù)據(jù)荣德。

假設(shè)一個應(yīng)用程序要求用戶兩條信息-----用戶名和密碼來創(chuàng)建帳戶闷煤。這個用戶輸入這兩條數(shù)據(jù)后保存童芹。最后,一個確認(rèn)窗口將通過數(shù)據(jù)庫中找到這條數(shù)據(jù)來顯示用戶名和密碼給用戶鲤拿。為了驗(yàn)證所有的數(shù)據(jù)保存是否正確假褪,一個QA測試人員會在這個確認(rèn)窗口簡單的查看下用戶名和密碼。如果他們成功了近顷?假設(shè)數(shù)據(jù)庫記錄了第三條信息----創(chuàng)建日期生音,它可能不會出現(xiàn)在確認(rèn)窗口,而只在存檔中才出現(xiàn)窒升。如果創(chuàng)建日期保留的不正確缀遍,而QA測試人員只驗(yàn)證屏幕上的數(shù)據(jù),那么這個問題就不可能被發(fā)現(xiàn)饱须。創(chuàng)建日期可能就是一個bug域醇,由于一個用戶帳戶保存了一個錯誤的日期到數(shù)據(jù)庫中,這個問題也不可能會被引起注意蓉媳,因?yàn)樗挥脩艚缑嫠[藏譬挚。這只是一個簡單的例子,但是它卻演化出了一點(diǎn):隱藏?cái)?shù)據(jù)測試的重要性酪呻。

等價劃分測試

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

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

判定表

判定表的英文是decision table灌旧,是指一個表格,用于顯示條件和條件導(dǎo)致動作的集合绰筛。

定義:判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況的工具枢泰。

判定表的優(yōu)點(diǎn):能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來,簡明并避免遺漏铝噩。因此衡蚂,利用判定表能夠設(shè)計(jì)出完整的測試用例集合。

在一些數(shù)據(jù)處理問題當(dāng)中,某些操作的實(shí)施依賴于多個邏輯條件的組合毛甲,即:針對不同邏輯條件的組合值年叮,分別執(zhí)行不同的操作。判定表很適合于處理這類問題玻募。

深度測試

深度測試的英文Depth test 只损,是指執(zhí)行一個產(chǎn)品的一個特性的所有細(xì)節(jié),但不測試所有特性七咧。

當(dāng)比較函數(shù)返回真的時候才顯示出效果來跃惫。必須啟用“#深度測試”,才能執(zhí)行測試坑雅。不使用的時候需要關(guān)閉辈挂。

基于設(shè)計(jì)的測試

基于設(shè)計(jì)的測試的英文是design-based testing,是根據(jù)軟件的構(gòu)架或詳細(xì)設(shè)計(jì)引出測試用例的一種方法裹粤。

一種基于設(shè)計(jì)模型的測試方法(Model Based TestIng System,MATIS).該方法利用用戶界面自動生成方法,把設(shè)計(jì)模型中的類屬性定義和實(shí)現(xiàn)中的控件屬性組織在一起,構(gòu)建描述界面的邏輯對照表,輔助測試腳本引擎執(zhí)行自動測試腳本.借助設(shè)計(jì)模型中擴(kuò)展的類定義,MATIS方法可以自動生成測試用例和測試數(shù)據(jù)终蒂。

文檔測試

文檔測試的英文是documentation testing,測試關(guān)注于文檔的正確性遥诉。文檔測試有三大類分別是開發(fā)文件拇泣、用戶文件、管理文件矮锈。

1.開發(fā)文件:可行性研究報告霉翔、軟件需求說明書、數(shù)據(jù)要求說明書苞笨、概要設(shè)計(jì)說明書债朵、詳細(xì)設(shè)計(jì)說明書、數(shù)據(jù)庫設(shè)計(jì)說明書瀑凝、模塊開發(fā)卷宗序芦。

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

3.管理文件:項(xiàng)目開發(fā)計(jì)劃谚中、測試計(jì)劃、測試分析報告寥枝、開發(fā)進(jìn)度月報宪塔、項(xiàng)目開發(fā)總結(jié)報告。

軟件測試中的文檔測試主要是對相關(guān)的設(shè)計(jì)報告和用戶使用說明進(jìn)行測試囊拜,對于設(shè)計(jì)報告主要是測試程序與設(shè)計(jì)報告中的設(shè)計(jì)思想是否一致某筐;對于用戶使用說明進(jìn)行測試時,主要是測試用戶使用說明書中對程序操作方法的描述是否正確冠跷,重點(diǎn)是用戶使用說明中提到的操作例子要進(jìn)行測試来吩,保證采用的例子能夠在程序中正確完成操作敢辩。

域測試

域測試的英文是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è)計(jì)時要同時考慮這兩種等價類锅劝,因?yàn)檐浖粌H要能接收合理的數(shù)據(jù)攒驰,也要能經(jīng)受意外的考驗(yàn)。

一有效等價類:是指對于程序的規(guī)格說明來說是合理的故爵、有意義的輸入數(shù)據(jù)構(gòu)成的集合玻粪。利用有效等價類可檢驗(yàn)程序是否實(shí)現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。

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

接口測試

接口測試的英文是interface testing劲室,接口測試測試系統(tǒng)組件間接口的一種測試。接口測試的好處:由于接口測試代碼本身就是用junit(當(dāng)然接口的類型不同结窘,不一定是Junit來實(shí)現(xiàn))來實(shí)現(xiàn)的很洋,是屬于自動化測試的范疇,因此必定也包含自動化測試所固有的優(yōu)勢隧枫。

1)提高測試質(zhì)量

軟件開發(fā)的過程是一個持續(xù)集成和改進(jìn)的過程喉磁,而每一次的改進(jìn)都可能引進(jìn)新bug,因此當(dāng)軟件的一部,或者全部修改時官脓,都需要對軟件產(chǎn)品重新進(jìn)行測試协怒。其目的是要驗(yàn)證修改后的產(chǎn)品是符合需求的,而當(dāng)沒有自動化測試代碼時确买,往往會由于各種各樣的原因斤讥,回歸不充分,導(dǎo)致bug遺漏湾趾。

2)提高測試效率

軟件系統(tǒng)的規(guī)模越來越大芭商,功能點(diǎn)越來越多,開發(fā)人員的自測或者測試人員的人工測試非常耗時和繁瑣搀缠,勢必導(dǎo)致測試效率的低下铛楣,而自動化測試正好解決這些耗時繁瑣的任務(wù),在對外接口功能不變的情況下艺普,達(dá)到了一次編寫簸州,永久使用的效果鉴竭。

3)提高測試覆蓋

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

4)更好地重現(xiàn)軟件缺陷

由于每次執(zhí)行都是相同的代碼矢洲,一旦代碼出錯璧眠,必定回歸出錯;

5)更好定位錯誤

由于接口測試是一種自下向上的測試读虏,因此一量出錯责静,非常容易定位出錯,不向系統(tǒng)測試那樣了盖桥,一旦有Bug屠升,需要幾層驗(yàn)證之后才能確定出錯位置凝化;

6)降低修改bug的成本接口測試

基本和開發(fā)人員的編碼平行工作褐鸥,因此發(fā)現(xiàn)問題會比系統(tǒng)測試早很多蝶棋,因此減少了修改bug的成本。

7)增進(jìn)測試人員和開發(fā)人員之間的合作關(guān)系

測試工程師為了更好地開展工作靴拱,需要對開發(fā)技術(shù)有深入的理解和實(shí)踐垃喊,有了與開發(fā)工程師更多的交流。

8)降低了項(xiàng)目不能按時發(fā)布的風(fēng)險

由于接口測試很早就介入袜炕,在提交給系統(tǒng)測試前對項(xiàng)目代碼的核心模塊已經(jīng)做了詳盡的測試本谜,必定加速系統(tǒng)測試的時間,由此來保證項(xiàng)目的按時發(fā)布偎窘;

9)提升測試人員的技能

做接口測試必須了解開發(fā)人員的開發(fā)流程和一些開發(fā)技能乌助,也需要了解測試工具的一些使用方法和一些測試思想,提升了測試人員的技術(shù)附加值陌知,提高了自身的竟?fàn)幜Α?/p>

10)促使項(xiàng)目開發(fā)過程的規(guī)范化

要進(jìn)行接口他托,需要完善的文檔進(jìn)行保障,沒有測試文檔仆葡,接口測試將寸步難行赏参,接口測試將增加開發(fā)過程規(guī)范化產(chǎn)出,而規(guī)范化產(chǎn)出也保證了項(xiàng)目質(zhì)量沿盅。

負(fù)面測試與正面測試的比較

負(fù)面測試(Negative testing)是相對于正面測試(Positive testing)而言的把篓。它們也是測試設(shè)計(jì)時的兩個非常重要的劃分。簡單點(diǎn)說腰涧,正面測試就是測試系統(tǒng)是否完成了它應(yīng)該完成的工作韧掩;而負(fù)面測試就是測試系統(tǒng)是否不執(zhí)行它不應(yīng)該完成的操作。形象一點(diǎn)窖铡,正面測試就象一個畢恭畢敬的小學(xué)生疗锐,老師叫我做什么坊谁,我就做什么;而負(fù)面測試就象一個調(diào)皮搗蛋的孩子滑臊,你叫我這樣做口芍,我偏不這樣做,而且和你對著干简珠。開發(fā)人員也是最討厭修改此類bug的阶界。

非功能性需求測試

非功能性需求測試的英文是non-functional requirements testing ,是與功能不相關(guān)的需求測試聋庵,如:性能測試、可用性測試等芙粱。

為什么非功能性需求很重要祭玉?在您設(shè)計(jì)解決方案的過程中滿足功能性需求當(dāng)然是很重要的。但是春畔,如果沒有考慮非功能性需求脱货,您的解決方案則很難取得實(shí)效。

非功能性需求特點(diǎn):

1.不要脫離實(shí)際環(huán)境律姨;

2.可靠性振峻;

3.可用性;

4.有效性择份;

5.可維護(hù)性扣孟;

6.可移植性。


最后:

歡迎關(guān)注公眾號:程序員一凡荣赶,領(lǐng)取一份300頁pdf文檔的Python自動化測試工程師核心知識點(diǎn)總結(jié)凤价!

這些資料的內(nèi)容都是面試時面試官必問的知識點(diǎn),篇章包括了很多知識點(diǎn)拔创,其中包括了有基礎(chǔ)知識利诺、Linux必備、Shell剩燥、互聯(lián)網(wǎng)程序原理慢逾、Mysql數(shù)據(jù)庫、抓包工具專題灭红、接口測試工具侣滩、測試進(jìn)階-Python編程、Web自動化測試比伏、APP自動化測試胜卤、接口自動化測試、測試高級持續(xù)集成赁项、測試架構(gòu)開發(fā)測試框架葛躏、性能測試澈段、安全測試等。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末舰攒,一起剝皮案震驚了整個濱河市败富,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌摩窃,老刑警劉巖兽叮,帶你破解...
    沈念sama閱讀 216,692評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異猾愿,居然都是意外死亡鹦聪,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,482評論 3 392
  • 文/潘曉璐 我一進(jìn)店門蒂秘,熙熙樓的掌柜王于貴愁眉苦臉地迎上來泽本,“玉大人,你說我怎么就攤上這事姻僧」胬觯” “怎么了?”我有些...
    開封第一講書人閱讀 162,995評論 0 353
  • 文/不壞的土叔 我叫張陵撇贺,是天一觀的道長赌莺。 經(jīng)常有香客問我,道長松嘶,這世上最難降的妖魔是什么艘狭? 我笑而不...
    開封第一講書人閱讀 58,223評論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮喘蟆,結(jié)果婚禮上缓升,老公的妹妹穿的比我還像新娘。我一直安慰自己蕴轨,他們只是感情好港谊,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,245評論 6 388
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著橙弱,像睡著了一般歧寺。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上棘脐,一...
    開封第一講書人閱讀 51,208評論 1 299
  • 那天斜筐,我揣著相機(jī)與錄音,去河邊找鬼蛀缝。 笑死顷链,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的屈梁。 我是一名探鬼主播嗤练,決...
    沈念sama閱讀 40,091評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼榛了,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了煞抬?” 一聲冷哼從身側(cè)響起霜大,我...
    開封第一講書人閱讀 38,929評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎革答,沒想到半個月后战坤,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,346評論 1 311
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡残拐,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,570評論 2 333
  • 正文 我和宋清朗相戀三年途茫,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片溪食。...
    茶點(diǎn)故事閱讀 39,739評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡慈省,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出眠菇,到底是詐尸還是另有隱情,我是刑警寧澤袱衷,帶...
    沈念sama閱讀 35,437評論 5 344
  • 正文 年R本政府宣布捎废,位于F島的核電站,受9級特大地震影響致燥,放射性物質(zhì)發(fā)生泄漏登疗。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,037評論 3 326
  • 文/蒙蒙 一嫌蚤、第九天 我趴在偏房一處隱蔽的房頂上張望辐益。 院中可真熱鬧,春花似錦脱吱、人聲如沸智政。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,677評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽续捂。三九已至,卻和暖如春宦搬,著一層夾襖步出監(jiān)牢的瞬間牙瓢,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,833評論 1 269
  • 我被黑心中介騙來泰國打工间校, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留矾克,地道東北人。 一個月前我還...
    沈念sama閱讀 47,760評論 2 369
  • 正文 我出身青樓憔足,卻偏偏與公主長得像胁附,于是被迫代替她去往敵國和親酒繁。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,647評論 2 354