- 相關(guān)推薦
軟件測試的目的
軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序或系統(tǒng)的過程。以下是小編為大家整理的軟件測試的目的相關(guān)內(nèi)容，僅供參考，希望能夠幫助大家。
問題：
軟件測試的目的
答案：
軟件測試的目的是盡可能發(fā)現(xiàn)并改正被測試軟件中的錯誤，提高軟件的可靠性。
基于不一樣的立場，存在著兩種完全不一樣的測試目的。從用戶的角度出發(fā)，普遍期望通過軟件測試暴露出軟件中陷藏的錯誤和缺陷，以思考是否能夠理解該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則期望測試成為證明軟件產(chǎn)品中不存在錯誤的過程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立用戶對軟件質(zhì)量的信心。
因?yàn)樵诔绦蛑型嬖谥S多預(yù)料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來。如果不把著眼點(diǎn)放在盡可能查找錯誤這樣一個(gè)基礎(chǔ)上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運(yùn)行階段中去。如果站在用戶的角度替他們設(shè)想，就應(yīng)當(dāng)把測試活動的目標(biāo)對準(zhǔn)揭露程序中存在的錯誤。在選取測試用例時(shí)，思考那些易于發(fā)現(xiàn)程序錯誤的數(shù)據(jù)。
下面這些規(guī)則也能夠看作是測試的目的或定義：
1、測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；
2、好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；
3、成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。
從上述規(guī)則能夠看出，測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程”。這和某些人通常想象的“測試是為了證明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”等等是完全相反的。正確認(rèn)識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試方案的設(shè)計(jì)。如果為了證明程序是正確的而進(jìn)行測試，就會設(shè)計(jì)一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計(jì)出最能暴露錯誤的測試方案。
由于測試的目標(biāo)是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進(jìn)行測試是不恰當(dāng)?shù)�。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，就應(yīng)認(rèn)識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴(yán)格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。
一、什么是軟件測試？
1979年，myer：軟件測試就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序或系統(tǒng)的過程。
1983年，IEEE：軟件測試即使用人工或自動手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。
二、現(xiàn)代軟件測試活動的內(nèi)容？
制定測試計(jì)劃、設(shè)計(jì)測試用例、實(shí)施測試、提交缺陷報(bào)告、測試總結(jié)
三、軟件測試的目的？
GrenfordJ.Myers在《The Artof Software Testing》一書中的觀點(diǎn)：
1、測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤
2、一個(gè)成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤
3、一個(gè)成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試
簡單的說，測試的根本目的就是確保最終交給用戶的產(chǎn)品符合用戶的需求，在產(chǎn)品交給用戶之前盡可能多的發(fā)現(xiàn)并改正問題。
四、測試一般要達(dá)到的目標(biāo)？
確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明；
確保產(chǎn)品滿足性能和效率的要求；確保產(chǎn)品是健壯的和適應(yīng)用戶環(huán)境的。
五、軟件測試分類？
1、按測試策略分類：a靜態(tài)測試與動態(tài)測試
靜態(tài)測試
定義：不運(yùn)行被測程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。Ps：通過分析或檢查源程序的文法、結(jié)構(gòu)、過程、接口等來檢驗(yàn)程序的正確性，找出缺陷和可疑之處，例如不匹配的參數(shù)、不適當(dāng)?shù)姆种短缀脱h(huán)嵌套、未使用過的變量、空指針的引用等；可采用人工和軟件工具進(jìn)行；靜態(tài)測試工具的代表：telelogic公司的logiscope軟件、PR公司的PRQA軟件等。
靜態(tài)測試特點(diǎn)：
不必動態(tài)地運(yùn)行程序，也不必進(jìn)行測試用例設(shè)計(jì)和結(jié)果判斷等工作；可由人工進(jìn)行，充分發(fā)揮人得邏輯思維優(yōu)勢；不需要特別的條件，容易展開。
靜態(tài)測試要點(diǎn)：
代碼審查（code in spection或code review）、代碼走查（walk through）、桌面檢查、技術(shù)評審（軟件需求分析和設(shè)計(jì)評審）、靜態(tài)分析（使用軟件工具，包括控制流分析、數(shù)據(jù)流分析、接口分析和表達(dá)式分析）
動態(tài)測試
定義：實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試實(shí)例，檢查運(yùn)行結(jié)果和預(yù)期結(jié)果的差異，判斷執(zhí)行結(jié)果是否符合要求，從而檢驗(yàn)程序的正確性、可靠性和有效性，并分析系統(tǒng)運(yùn)行效率和健壯性等性能。
組成：構(gòu)造測試實(shí)例、根據(jù)測試實(shí)例運(yùn)行程序、分析程序的輸出結(jié)果。主要方法：黑盒測試和白盒測試。
動態(tài)測試特點(diǎn)：
實(shí)際運(yùn)行被測試程序，取得程序運(yùn)行的真實(shí)情況、動態(tài)情況，并進(jìn)行分析；必須生成測試數(shù)據(jù)來運(yùn)行程序，測試質(zhì)量依賴于測試數(shù)據(jù)；生成測試數(shù)據(jù)、分析測試結(jié)果工作量大，使開展測試工作費(fèi)時(shí)、費(fèi)力、費(fèi)人；
動態(tài)測試中涉及多方面工作，人員多、設(shè)備多、數(shù)據(jù)多，要求有較好的管理和工作規(guī)程。
b黑盒測試和白盒測試
黑盒測試（black-box testing）又稱功能測試、數(shù)據(jù)驅(qū)動測試、基于規(guī)格說明書的測試。定義：測試者把被測程序看成一個(gè)黑盒，不考慮程序的內(nèi)部結(jié)構(gòu)和特性，只需知道該程序輸入和輸出之間的關(guān)系和程序功能，依靠能夠反映這一關(guān)系和程序功能的需求規(guī)格說明書，來確定測試用例和推斷測試結(jié)果的正確性。
白盒測試（white-box testing）又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試、基于程序本身的測試。定義：從程序的內(nèi)部邏輯結(jié)構(gòu)入手，按照一定的原則設(shè)計(jì)測試用例，對軟件的邏輯路徑進(jìn)行測試，在程序的不同點(diǎn)檢查程序的狀態(tài)，來判定其實(shí)際情況是否和預(yù)期的狀態(tài)一致。規(guī)劃方面適用范圍優(yōu)勢缺陷黑盒測試針對功能的測試進(jìn)行確認(rèn)測試和系統(tǒng)測試時(shí)使用能確保從用戶使用的角度出發(fā)進(jìn)行測試無法測試程序內(nèi)部特定部位；如果需求說明有誤，則無法發(fā)現(xiàn)問題等價(jià)類劃分（將所有可能的輸入數(shù)據(jù)劃分為若干等價(jià)類，選擇有代表性的當(dāng)做測試用例進(jìn)行測試）；邊界值分析法（對輸入或輸出的邊界值進(jìn)行測試）；因果圖法（利用圖解法分析輸入的各種組合的情況，從而設(shè)計(jì)測試用例的方法。“因”即輸入條件，“果”即輸出或程序狀態(tài)的改變）；比較測試法白盒測試針對結(jié)構(gòu)的測試進(jìn)行單元測試時(shí)使用能夠?qū)Τ绦騼?nèi)部的特定部位進(jìn)行覆蓋測試無法檢驗(yàn)程序的外部特性；無法對未實(shí)現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進(jìn)行測試語句覆蓋（程序中每條語句至少被執(zhí)行一次）；判斷覆蓋（或分支覆蓋，程序中每個(gè)分支至少走查過一次）；條件覆蓋（判定式中若含多個(gè)條件，則每個(gè)條件的取值均要得到檢驗(yàn)）；判斷/條件覆蓋（同時(shí)考慮條件的組合值及判定結(jié)果的檢驗(yàn)）；基本路徑的覆蓋（使程序沿所有可能的路徑執(zhí)行）；循環(huán)覆蓋；模塊接口測試應(yīng)用舉例
C手工測試與自動測試
手工測試定義：由測試人員來執(zhí)行測試用例，然后根據(jù)實(shí)際的結(jié)果去和預(yù)期的結(jié)果相比較并記錄測試結(jié)果。手工測試時(shí)現(xiàn)在多數(shù)公司使用的測試形式。
自動測試
定義：引入自動測試工具。
通常以手工測試為主，自動測試為輔。d冒煙測試（smoketest）：在版本投入正式測試前，對其重要的步伐先進(jìn)行大概的測試，看系統(tǒng)重要的功能是否正確，再進(jìn)行徹底的測試。e回歸測試（regressiontest）：一段時(shí)間以后對以前修復(fù)過的缺陷重新進(jìn)行測試，看該缺陷是否會重新出現(xiàn)。
2、按測試階段分類
單元測試又稱模塊測試定義：針對每一個(gè)程序模塊進(jìn)行正確性檢驗(yàn)，檢查各個(gè)程序模塊是否正確的實(shí)現(xiàn)了規(guī)定的功能。如一個(gè)窗口、函數(shù)、菜單、報(bào)表或一個(gè)存儲過程。
依據(jù)是詳細(xì)設(shè)計(jì)，應(yīng)對所有重要的控制路徑設(shè)計(jì)測試用例。集成測試又稱綜合測試。定義：在單元測試的基礎(chǔ)上，將已經(jīng)通過測試的單元模塊按照設(shè)計(jì)要求組裝成系統(tǒng)或子系統(tǒng)，再進(jìn)行的測試。
系統(tǒng)測試定義：是將通過確認(rèn)測試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行全面的功能覆蓋。
單元測試集成測試確認(rèn)測試（有效性測試、軟件配置審查）系統(tǒng)測試驗(yàn)收測試（以用戶為主）測試類型單元測試對象模塊內(nèi)部的程序錯誤模塊間的集成和調(diào)用關(guān)系目的清除局部模塊的邏輯和功能上的錯誤和缺陷找出與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)，模塊調(diào)用關(guān)系，模塊間接口方面的問題測試依據(jù)測試方法模塊邏輯設(shè)計(jì)，大量采用白盒測模塊外部說明試方法程序結(jié)構(gòu)設(shè)計(jì)白盒與黑盒相結(jié)合的測試方法，較多用黑盒方法構(gòu)造測試用例集成測試系統(tǒng)測試整個(gè)系統(tǒng)，包括系統(tǒng)中的軟、硬件對整個(gè)系統(tǒng)進(jìn)行一系系統(tǒng)結(jié)構(gòu)設(shè)計(jì)，黑盒測試列的整體、有效性測試目標(biāo)說明書，需求說明書3、其他常見測試方法
功能測試（functiong testing）又稱正確性測試，軟件的功能是否符合規(guī)格說明；
性能測試(performance testing)，系統(tǒng)是否滿足需求說明書中規(guī)定的性能，通常使用自動化測試工具；
壓力測試（stress testing）：檢查系統(tǒng)在瞬間峰值負(fù)荷下正確執(zhí)行的能力，通常用測試工具測試；
負(fù)載測試（volume testing）：用于檢查系統(tǒng)在使用大量數(shù)據(jù)時(shí)正確工作的能力；
易用性測試（usability testing）：合理性、方便性；
安裝測試（installation testing）：對軟件的全部、部分或升級安裝/卸載處理過程的測試；界面測試：包括窗口測試、下拉式菜單和鼠標(biāo)操作、數(shù)據(jù)項(xiàng)測試；
配置測試（configuration testing）：主要檢查計(jì)算機(jī)系統(tǒng)內(nèi)各個(gè)設(shè)備或各種資源之間的相互連接和功能分配中的錯誤。包括驗(yàn)證全部配置命令的可操作性，軟件配置，硬件配置，利用手動或自動方式驚喜配置狀態(tài)間的轉(zhuǎn)換；
文檔測試（documentation testing）：文檔的正確性、完備性、可理解性；
兼容性測試（compatibility testing）：產(chǎn)品在不同產(chǎn)品之間的兼容性；
安全性測試（security testing）：非法侵入的防范能力，已存在的安全性、保密性，有無漏洞；
恢復(fù)測試（recovery testing）：容錯能力，在指定的時(shí)間內(nèi)修正錯誤并恢復(fù)正常，又不傷害系統(tǒng)。
六：軟件的開發(fā)周期（軟件生命周期）和模型？瀑布模型：
計(jì)劃需求分析設(shè)計(jì)編碼測試運(yùn)行、維護(hù)
嚴(yán)格按照固定順序，每個(gè)階段結(jié)束，經(jīng)過項(xiàng)目小組審查，決定是否進(jìn)入下一步。
螺旋模型：確定目標(biāo)、可選方案和現(xiàn)在條件指出并解決風(fēng)險(xiǎn)評估方案本階段開發(fā)和測試計(jì)劃下一階段確定進(jìn)入下一階段的方法（該過程重復(fù)進(jìn)行）螺旋模型是瀑布模型的發(fā)展，較常用。
七、軟件測試生命周期？
制定測試計(jì)劃測試設(shè)計(jì)和開發(fā)實(shí)施軟件測試評審版本發(fā)布
八、什么是軟件的缺陷（bug）？
定義：在軟件使用過程中所出現(xiàn)的任何問題，或者導(dǎo)致軟件不能符合設(shè)計(jì)要求或滿足消費(fèi)者需求的問題。包括程序錯誤等等。
九、書寫缺陷報(bào)告的準(zhǔn)則？
保證重現(xiàn)缺陷；分析故障，使用最少步驟重現(xiàn)缺陷；包含所有重現(xiàn)缺陷的必要步驟；方便閱讀（編號，分步驟）；盡量簡單（一個(gè)缺陷一個(gè)報(bào)告）；注意語氣。
識別和判斷缺陷的輔助工具：軟件需求說明書、用戶手冊、聯(lián)機(jī)幫助。
十、bug的生命周期？有效地記錄BUG；
使用BUG模板；
評價(jià)BUG優(yōu)先級和嚴(yán)重性；BUG的生命；
維護(hù)BUG數(shù)據(jù)庫。
十一、bug的類型？
軟件沒有實(shí)現(xiàn)產(chǎn)品規(guī)格說明所要求的功能模塊；
軟件中出現(xiàn)了產(chǎn)品規(guī)格說明指明不應(yīng)該出現(xiàn)的錯誤；軟件實(shí)現(xiàn)了產(chǎn)品規(guī)格說明沒有提到的功能模塊；
軟件沒有實(shí)現(xiàn)雖然產(chǎn)品規(guī)格說明沒有明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)；
軟件難以理解，不容易使用，運(yùn)行緩慢，或從測試員的角度看，最終用戶會認(rèn)為不好。功能缺陷：規(guī)格說明書、能功、測試
系統(tǒng)缺陷：內(nèi)部接口、硬件、操作系統(tǒng)、軟件結(jié)構(gòu)、控制與順序、資源加工缺陷：算術(shù)、初始化、控制與次序、靜態(tài)邏輯、其他數(shù)據(jù)缺陷：類型、結(jié)構(gòu)、初始值、其他代碼缺陷：程序編寫、文檔、其他
十二、bug中通常包含的內(nèi)容
硬件平臺和操作系統(tǒng)版本
Bug報(bào)告優(yōu)先級Bug狀態(tài)
報(bào)告人reporter
指定處理人assignedto概述summary
郵件抄送列表CClist從屬關(guān)系（bug“ID”dependson,bug“ID”block）附加描述additionalcomments
十三、bug中的優(yōu)先級的定義？
優(yōu)先級表示修復(fù)缺陷的重要程度和應(yīng)該何時(shí)修復(fù)：1應(yīng)立即修復(fù)的問題
2在產(chǎn)品發(fā)布之前必須修復(fù)的問題3如果時(shí)間允許應(yīng)該修復(fù)的問題4可以在發(fā)布版本中存在的問題
缺陷的二八定理：一般情況下，在分析、設(shè)計(jì)、實(shí)現(xiàn)階段的復(fù)查和測試工作能夠發(fā)現(xiàn)和避免80%的缺陷，而系統(tǒng)測試又能找到剩余缺陷的80%，最后的4%的缺陷可能只有在用戶大范圍、長時(shí)間使用后才會暴露出來。
十四、什么是測試用例？
定義：指為實(shí)施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個(gè)特定的集合。換句話說，測試用例就是記下要進(jìn)行什么測試，進(jìn)行測試的具體步驟，以及測試執(zhí)行是否正確的標(biāo)準(zhǔn)。
測試用例控制軟件測試的執(zhí)行過程。
十五、測試用例包含的內(nèi)容？
項(xiàng)目名稱：指明本測試用例是用例測試什么軟件項(xiàng)目的功能模塊名：指明要測試的內(nèi)容
測試目的：描述被測試功能的詳細(xì)的特性及要測試的目標(biāo)預(yù)置條件：執(zhí)行測試用例之前所做的操作，如啟動程序等用例編號：唯一編號
相關(guān)用例：列出必須先于本測試用例執(zhí)行的測試用例用例說明：描述實(shí)現(xiàn)用例的步驟
輸入數(shù)據(jù)：描述測試用例所需的輸入數(shù)據(jù)或條件預(yù)期結(jié)果：輸入后應(yīng)該輸出的結(jié)果
測試結(jié)果：此項(xiàng)在測試執(zhí)行時(shí)填寫，說明測試用例是否通過，如果不通過，就要生成缺陷報(bào)告，并注明缺陷的編號，這里的缺陷編號要與缺陷跟蹤系統(tǒng)中的編號一致。
十六、設(shè)計(jì)測試用例的方法？
1等價(jià)類劃分法
定義：測試人員要對需求規(guī)格說明書中的各項(xiàng)需求，尤其是功能需求進(jìn)行細(xì)致分析，然后把程序的輸入域劃分為若干個(gè)部分，從每個(gè)部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。經(jīng)過這種劃分后，每一類的代表性數(shù)據(jù)在測試中的作用都等價(jià)于這一類中的其他值。
等價(jià)類劃分法是一種最典型的黑盒測試法。
步驟：在進(jìn)行等價(jià)類劃分之前，首先從程序的功能說明中找出各個(gè)輸入條件，然后為每個(gè)輸入條件劃分兩個(gè)或更多個(gè)等價(jià)類。確定了等價(jià)類劃分后，給出相應(yīng)的等價(jià)類表，再根據(jù)等價(jià)類表給出測試用例。
要同時(shí)考慮有效等價(jià)類和無效等價(jià)類。
2邊界值方法
定義：對輸入和輸出的邊界值進(jìn)行測試的黑盒測試方法。
確定邊界值：選取正好等于、剛剛大于、剛剛小于邊界的值作為測試數(shù)據(jù)，即中的測試最后一個(gè)肯定合法的數(shù)據(jù)和剛剛超過邊界的非法數(shù)據(jù)。
邊界值法是等價(jià)類劃分方法的補(bǔ)充。3因果圖定義：考慮輸入條件之間的聯(lián)系、相互組合。
步驟：
分析軟件需求說明的描述中的原因（即輸入條件或輸入條件的等價(jià)類）、結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果附一個(gè)標(biāo)識符；
分析因果關(guān)系，畫因果圖
對于不可能出現(xiàn)的組合情況，做出記號表明約束或限制條件；因果圖轉(zhuǎn)化成判定表；
把判定表的每一列作為依據(jù)，設(shè)計(jì)測試用例。4其他方法
通過測試和失敗測試錯誤猜測隨機(jī)測試
十七、測試用例中優(yōu)先級的定義？
1小版本確認(rèn)測試（buildverificationtests,BVTs）：也叫“冒煙測試”，開發(fā)人員在個(gè)人版本的軟件上執(zhí)行目前的冒煙測試項(xiàng)目，確定新的程序代碼不出故障。
2高（highs）：最常執(zhí)行以保障功能性是穩(wěn)定的，目標(biāo)的行為和能力可以正常的工作，和重要的錯誤和邊界被測試的測試用例的集合。
3中（mediums）是使給出的功能區(qū)域或功能變得更詳細(xì)，檢查功能的多數(shù)方面包括邊界，錯誤和配置測試的測試用例。
4低（lows）：通常最少被執(zhí)行的測試用例。在項(xiàng)目的生命期間里不是常常被運(yùn)行，如GUI，錯誤信息，可用性，壓力和性能測試。
十八、什么是測試計(jì)劃，測試計(jì)劃中通常包含什么內(nèi)容？
定義：軟件測試計(jì)劃指在軟件測試工作正式實(shí)施之前明確測試的對象，并且通過對資源、時(shí)間、風(fēng)險(xiǎn)、測試范圍和預(yù)算等方面的綜合分析和規(guī)劃，保障有效地實(shí)施軟件測試。
內(nèi)容：
測試計(jì)劃的簡介測試項(xiàng)目說明
需要測試的項(xiàng)目清單測試手段和策略
項(xiàng)目通過或失敗的標(biāo)準(zhǔn)暫停和重新啟動測試的標(biāo)準(zhǔn)測試的可交付性測試任務(wù)環(huán)境的需求職責(zé)
【軟件測試的目的】相關(guān)文章：
軟件測試總結(jié)03-22
軟件測試個(gè)人總結(jié)01-16
軟件測試實(shí)習(xí)心得04-20
軟件測試總結(jié)(15篇)05-20
軟件測試總結(jié)15篇03-22
軟件測試述職報(bào)告01-30