測試基礎(chǔ)習(xí)題答案

測試根底習(xí)題答案一、填空題1、 軟件測試的定義：軟件測試是貫穿整個軟件開發(fā)生命周期、對軟件產(chǎn)品〔包括階段性產(chǎn)品〕進行驗證和 活動過程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題。2、軟件測試的狹義論和廣義論 ——靜態(tài)和動態(tài)的測試。軟件測試的辨證論 ——正向思維和反向思維。軟件測試的風(fēng)險論一一測試是評估，軟件測試的經(jīng)濟學(xué)觀點 ――為盈利而測試，軟件測試的標(biāo)準(zhǔn)論 ――驗證和確認(rèn)。3、Spec中英問意思是： SystemPeformaneeEvaluationCorporation ，系統(tǒng)性能評估測試4、 驗證過程提供證據(jù)說明軟件相關(guān)產(chǎn)品與所有生命周期活動的要求〔如正確性、完整性、一致性、準(zhǔn)確性等〕相一致5、從標(biāo)準(zhǔn)論來看軟件測試，可以定義為軟件測試就是 驗證〔Verification〕"和有效性確認(rèn)〔Validation〕"活動構(gòu)成的整體，即軟件測試 =V&V。6、 V模型指岀，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、 質(zhì)量特性是否到達系統(tǒng)要求的指標(biāo)；驗收測試確定 7、螺旋模型的每一次迭代都包含了以下六個步驟迭代的步驟和方案8、測試工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具9、什么是軟件缺陷：1.軟件未到達產(chǎn)品說明書標(biāo)明的功能。 2.軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤。 3.軟件功能超出產(chǎn)品說明書指明范圍。 4.軟件未到達產(chǎn)品說明書雖未指出但應(yīng)到達的目標(biāo)。 5.軟件測試員認(rèn)為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認(rèn)為不好10、 缺陷的分類：文檔缺陷、代碼缺陷、測試缺陷、三過程缺陷11、 對于缺陷的嚴(yán)重性，可以分為：非常 12、 缺陷的分類：代碼類缺陷、文檔類缺陷13、 缺陷產(chǎn)生的原因：需求存在問題、設(shè)計問題、代碼問題、測試人員的錯誤14、 軟件測試的目標(biāo)：盡量多的發(fā)現(xiàn)缺陷、盡早發(fā)現(xiàn)缺陷、預(yù)防15、 軟件測試的作用是：找 16、常見的軟件生命周期模型有：瀑布模型、 RUP模型、W模型等17、 測試工具的優(yōu)點有：高效、可重復(fù)18、 測試工具的缺點有：技 19、 軟件測試的目標(biāo)：發(fā)現(xiàn)缺陷、盡早發(fā)現(xiàn)缺陷、預(yù)防缺陷的產(chǎn)生20、 瀑布模型的生命周期為：需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼和測試21、 RUP模型的全稱為：rationalunifiedprocess. 22、 RUP模型的階段分為：初始化階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段二、判斷題〔X〕1、好的測試員不懈追求完美?！瞂〕2、測試程序僅僅按預(yù)期方式運行就行了?！瞂〕3、不存在質(zhì)量很咼但可靠性很差的產(chǎn)品。〔X〕4、軟件測試員可以對產(chǎn)品說明書進行測試。〔X〕5、可以發(fā)布具有配置缺陷的軟件產(chǎn)品?！瞂〕6、所有軟件必須進行某種程度的兼容性測試。〔X〕7、所有軟件都有一個用戶界面，因此必須測試易用性?！瞂〕8、測試組負(fù)責(zé)軟件質(zhì)量。〔X〕9、測試人員可以提高軟件質(zhì)量。〔X〕10、開發(fā)人員可以進行自測就可以了，不需要測試參與?！瞂〕11、測試人員只需要發(fā)現(xiàn)缺陷就可以了〔X〕12、測試人員不能只發(fā)現(xiàn)缺陷，還要負(fù)責(zé)修復(fù)缺陷。〔X〕13、開發(fā)人員不需要對產(chǎn)品進行測試，只負(fù)責(zé)修改缺陷既可。〔V〕14、測試人員要協(xié)助開發(fā)人員確認(rèn)缺陷的產(chǎn)生原因?！睼〕15、測試人員提出缺陷后，要對缺陷進行定位。X〕16、缺陷的分為三類：文檔缺陷、代碼缺陷、三過程缺陷。V〕17、代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷；V〕18、缺陷嚴(yán)重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。V〕19、靜態(tài)測試工具：直接對代碼進行分析，不需要運行代碼，也不需要對代碼編譯鏈接，生成可執(zhí)行文件。V〕20、軟件測試就是“驗證〔Verification〕〞和“有效性確認(rèn)〔Validation〕〞活動構(gòu)成的整體X〕21、有效實施配置管理，不需要組織架構(gòu)上的支持活動V〕22、程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程X〕23、發(fā)現(xiàn)缺陷數(shù)最多的測試人員就是最優(yōu)秀的測試人員X〕24、測試人員必須具有開發(fā)技術(shù)X〕25、測試人員和開發(fā)人員的矛盾是不可調(diào)和的V〕26、測試人員應(yīng)該與開發(fā)人員定期溝通和學(xué)習(xí)V〕27、測試人員應(yīng)該協(xié)助開發(fā)人員盡快定位問題X〕28、在開發(fā)的早期沒有必要介入測試X〕29、測試越到后期發(fā)現(xiàn)缺陷越困難X〕30、測試越到后期缺陷修復(fù)本錢越低X〕31、測試人員技術(shù)水平的上下決定了軟件質(zhì)量的優(yōu)劣X〕32、如果公司中有了測試部門，開發(fā)人員就不需要進行自測了，因為沒有必要X〕33、自動化測試能夠比手工測試發(fā)現(xiàn)更多的缺陷V〕34、自動化測試比手工測試的效率更高，所以要大量開展自動化測試V〕35、自動化測試必須借助測試工作才能完成X〕36、自動化測試能夠發(fā)現(xiàn)手工測試發(fā)現(xiàn)不了的問題X〕37、瀑布模型適合于大規(guī)模的公司〔X〕38、RUP模型適合于小規(guī)模的工程V〕39、瀑布模型適合于小規(guī)模的公司，對于較成熟的產(chǎn)品比較適用〔V〕40、RUP模型適合于大規(guī)模關(guān)聯(lián)關(guān)系較松散的工程。X〕41、越嚴(yán)重的缺陷應(yīng)該越早修復(fù)X〕42、越嚴(yán)重的缺陷應(yīng)該越晚修復(fù)X〕43、缺陷程度越高的缺陷，修復(fù)優(yōu)先級也應(yīng)該越高V〕44、一般而言缺陷程度較高的缺陷，修復(fù)優(yōu)先級越高，但也有特例X〕45、測試工程師不會犯錯誤，只有開發(fā)工程師會犯錯X〕46、軟件開發(fā)完成后進行軟件測試X〕47、使用測試工具，就是進行了有效的測試V〕48、測試工程師的開展方向有兩種，一個是技術(shù)方向，另一個是管理方向V〕49、軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯X〕50、軟件測試要求不高，隨便找個人多都行X〕51、軟件自動測試效率高，將取代軟件手工測試X〕52、軟件測試是測試人員的事情，與程序員無關(guān)X〕53、工程進度吃緊時少做些測試，時間富裕時多做測試X〕54、軟件測試是沒有前途的工作，只有程序員才是軟件高手X〕55、需求-實現(xiàn)-測試，軟件測試是開發(fā)后期的一個階段；X〕56、軟件測試對技術(shù)要求不高，至少比編程容易得多。X〕57、測試代碼可以隨意寫X〕58、測試只要證明軟件正確就可以了。X〕59、測試是枯燥無味的，是缺乏創(chuàng)造力的。X〕60、存在太多的無法測試的東西〔X〕61、自動化測試是萬能的?！瞂〕62、如果軟件最后出了問題，肯定都是測試的問題三、簡答題1、缺陷的嚴(yán)重程度和優(yōu)先級如何劃分？缺陷的嚴(yán)重程度和優(yōu)先級通常可按級別劃分，各個公司對不同工程的具體表示方式有所不同，具體的級別劃分需要軟件測試前達成一致。常用的缺陷嚴(yán)重程度可分為：致命、嚴(yán)重、一般、較小。致命是指系統(tǒng)任何一個主要功能完全喪失，或用戶數(shù)據(jù)受到破壞，造成系統(tǒng)崩潰、懸掛、死機或者危機人身平安；嚴(yán)重是指系統(tǒng)的主要功能局部喪失，或數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失，系統(tǒng)所提供的功能或效勞受到明顯的影響；一般是指系統(tǒng)的次要功能沒有完全實現(xiàn)，但不影響用戶的正常使用；較小是指使操作者不方便或遇到麻煩，但它不影響功能的操作和執(zhí)行的一些小問題。常用的缺陷的優(yōu)先級表示方法可分為：立即解決、高優(yōu)先級、正常排隊、低優(yōu)先級。立即解決是指缺陷導(dǎo)致系統(tǒng)幾乎不能使用或者測試不能繼續(xù)，需立即修復(fù)；高優(yōu)先級是指缺陷嚴(yán)重影響測試，需要優(yōu)先考慮；正常排隊是指缺陷需要正常排隊等待修復(fù)；而低優(yōu)先級是指缺陷可以在開發(fā)人員有時間的時候再被糾正。2、缺陷的分類有哪些？新工程可以從基線提供的定點之中建立。作為一個單獨分支，新工程將與隨后對原始工程〔在主要分支上〕所進行的變更進行隔離。各開發(fā)人員可以將建有基線的構(gòu)件作為他在隔離的私有工作區(qū)中進行更新的根底。當(dāng)認(rèn)為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法?？梢岳没€重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)已報告的錯誤。3、在一個團隊中為什么要提出軟件測試崗位？1、 軟件的缺陷等級應(yīng)如何劃分？〔3分〕2、 如果能夠執(zhí)行完美的黑盒測試，還需要進行白盒測試嗎？為什么？〔 5分〕3、 你認(rèn)為一個優(yōu)秀的測試工程師應(yīng)該具備哪些素質(zhì)？〔3分〕4、 產(chǎn)品測試到什么時候就算是足夠了？〔2分〕5、 測試方案的目的是什么？〔2分〕6、為什么要進行軟件測試?軟件測試的目的是什么?〔5分〕7、 軟件測試應(yīng)該劃分幾個階段?簡述各個階段應(yīng)重點測試的點?各個階段的含義？〔5分〕8、 如何做一名合格的測試人員？〔3分〕9、 針對缺陷采取怎樣的管理措施？〔5分〕4、測試工程師的工作內(nèi)容有哪些？規(guī)格說明的狀態(tài)；修改建議的狀態(tài)；修改批準(zhǔn)的報告；產(chǎn)品版本或其修改版的狀態(tài)；安裝、更新或交付的實現(xiàn)報告；用戶提供的產(chǎn)品〔如操作系統(tǒng)〕的狀態(tài)；有關(guān)開發(fā)工程歷史的報告。5、測試工程師應(yīng)該具備哪些技能？熟練掌握軟件測試?yán)碚摵土鞒獭⒅贫y試方案、編寫測試策略、測試用例、執(zhí)行測試，能從多角度發(fā)現(xiàn) BUG,以及熟悉BUG的處理流程和對結(jié)果進行分析；能夠運用多種方法來編寫測試用例，如：等價類劃分、邊界值、因果圖、判定表、業(yè)務(wù)邏輯流程圖、狀態(tài)遷移圖、結(jié)果輸出域、正交矩陣等；能夠熟練掌握一種或幾種編程語言，如： C/C++、JAVA腳本語言：VBscript/Javascript、Shell編程；能夠熟練掌握一種或幾種測試工具，如： QTP、LoadRunner等，測試管理工具：QuailtyCenter，還有一些BUG管理工具：Bugzilla、BugFree、JIRA等；最好是能夠掌握性能測試：如非常熟悉LoadRunner的性能測試流程，比方制定性能測試方案、錄制和編輯腳本、場景設(shè)計、運行并監(jiān)控場景、對結(jié)果的分析并發(fā)現(xiàn)系統(tǒng)的瓶頸；懂開發(fā)，并且要對一些主流的開發(fā)框架比較熟悉，如： J2EE；熟悉常用的應(yīng)用效勞器，如：Weblogic、Tomcat等；熟悉常用的操作系統(tǒng)，如： Windows系列、Linux，并熟悉Linux下的主要查詢命令；熟悉一種或幾種數(shù)據(jù)庫，如： Oracle、SqlServer、MySql等，能夠熟練編寫常用的SQI語句，掌握存儲過程和觸發(fā)器等，最好是能夠?qū)?shù)據(jù)庫進行調(diào)優(yōu)；要有缺陷預(yù)防的意識，因為缺陷越發(fā)現(xiàn)的早越好，這個主要是看個人的天賦，有些人天生下來大腦的敏感性比較強，他能夠一開始覺察到未來會出現(xiàn)什么風(fēng)險，如果沒有這種天賦，那就只有依靠自己的經(jīng)驗來判斷；英語要好，要有比較好的聽、說、讀、寫能力。6、測試工程師應(yīng)該具備哪些職業(yè)素質(zhì)人是測試工作中最有價值也是最重要的資源，沒有一個合格的、積極的測試小組，測試就不可能實現(xiàn)。然而，在軟件開發(fā)產(chǎn)業(yè)中有一種非常普遍習(xí)慣，那就是讓那些經(jīng)驗最少的新手、沒有效率的開發(fā)者或不適合干其他工作的人去做測試工作。這絕對是一種目光短淺的行為，對一個系統(tǒng)進行有效的測試所需要的技能絕對不比進行軟件開發(fā)需要的少，事實上，測試者將獲得極其廣泛的經(jīng)驗，他們將遇到許多開發(fā)者不可能遇到的問題。1、 溝通能力一名理想的測試者必須能夠同測試涉及到的所有人進行溝通，具有與技術(shù)〔開發(fā)者〕和非技術(shù)人員〔客戶，管理人員〕的交流能力。既要可以和用戶談得來，又能同開發(fā)人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統(tǒng)可以正確地處理什么和不可以處理什么上。而和開發(fā)者談相同的信息時，就必須將這些活重新組織以另一種方式表達出來，測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。2、 移情能力和系統(tǒng)開發(fā)有關(guān)的所有人員都處在一種既關(guān)心又擔(dān)憂的狀態(tài)之中。 用戶擔(dān)憂將來使用一個不符合自己要求的系統(tǒng)，開發(fā)者那么擔(dān)憂由于系統(tǒng)要求不正確而使他不得不重新開發(fā)整個系統(tǒng)，管理部門那么擔(dān)憂這個系統(tǒng)突然崩潰而使它的聲譽受損。測試者必須和每一類人打交道，因此需要測試小組的成員對他們每個人都具有足夠的理解和同情，具備了這種能力可以將測試人員與相關(guān)人員之間的沖突和對抗減少到最低程度。3、 技術(shù)能力就總體言，開發(fā)人員對那些不懂技術(shù)的人持一種輕視的態(tài)度。一旦測試小組的某個成員作出了一個錯誤的斷定，那么他們的可信度就會立刻被傳揚了出去。一個測試者必須既明白被測軟件系統(tǒng)的概念又要會使用工程中的那些工具。要做到這一點需要有幾年以上的編程經(jīng)驗，前期的開發(fā)經(jīng)驗可以幫助對軟件開發(fā)過程有較深入的理解，從開發(fā)人員的角度正確的評價測試者，簡化自動測試工具編程的學(xué)習(xí)曲線。4、 自信心開發(fā)者指責(zé)測試者出了錯是常有的事，測試者必須對自己的觀點有足夠的自信心。如果容許別人對自己指東指西，就不能完成什么更多的事情了。5、 外交能力當(dāng)你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助于維護與開發(fā)人員的協(xié)作關(guān)系，測試者在告訴開發(fā)者他的軟件有錯誤時，也同樣需要一定的外交手腕。如果采取的方法過于強硬，對測試者來說，在以后和開發(fā)部門的合作方面就相當(dāng)于“贏了戰(zhàn)爭卻輸了戰(zhàn)役〞。6、 幽默感在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。7、 很強的記憶力一個理想的測試者應(yīng)該有能力將以前曾經(jīng)遇到過的類似的錯誤從記憶深處挖掘出來， 這一能力在測試過程中的價值是無法衡量的。因為許多新出現(xiàn)的問題和我們已經(jīng)發(fā)現(xiàn)的問題相差無幾。8、 耐心一些質(zhì)量保證工作需要難以置信的耐心。有時你需要花費驚人的時間去別離、識別和分派一個錯誤。這個工作是那些坐不住的人無法完成的。9、 疑心精神可以預(yù)料，開發(fā)者會盡他們最大的努力將所有的錯誤解釋過去。測式者必須聽每個人的說明，但他必須保持疑心直到他自己看過以后。10、 自我催促干測試工作很容易使你變得懶散。只有那些具有自我催促能力的人才能夠使自己每天正常地工作。11、洞察力一個好的測試工程師具有“測試是為了破壞〞的觀點，捕獲用戶觀點的能力，強烈的質(zhì)量追求，對細(xì)節(jié)的關(guān)注能力。應(yīng)用的高風(fēng)險區(qū)的判斷能力以便將有限的測試針對重點環(huán)節(jié)。7、測試工程師能創(chuàng)造什么價值？近兩年國內(nèi)IT業(yè)對軟件測試的重視程度較幾年有了很大的提升， 但由于歷史和現(xiàn)實的原因，軟件測試人員在公司內(nèi)部的受重視程度遠(yuǎn)不如軟件開發(fā)人員；軟件測試的價值表達很隱蔽，它屬于產(chǎn)品質(zhì)量把關(guān)的工作，本身不直接產(chǎn)生經(jīng)濟效益，由于軟件測試的價值表達沒有軟件開發(fā)人員明顯，很多企業(yè)的領(lǐng)導(dǎo)對軟件測試的認(rèn)識還停留在很淺薄的階段上；所以在國內(nèi)的一些軟件公司直接就省略掉了軟件測試這個環(huán)節(jié)，或者在軟件產(chǎn)品測試方面投入的人力物力比較薄弱，造成產(chǎn)品交付客戶使用后，產(chǎn)品本身所帶的缺陷和不穩(wěn)定性為后期的產(chǎn)品質(zhì)量維護造成了很大的壓力和挑戰(zhàn)。如何根據(jù)軟件企業(yè)的特點和規(guī)劃組建一支有效的測試團隊，實現(xiàn)軟件測試投入產(chǎn)出比的最大化，在一定的程度上表達軟件測試的開展和價值；軟件測試是檢驗軟件產(chǎn)品是否滿足軟件用戶需求規(guī)格，是發(fā)現(xiàn)軟件缺陷的有效手段。軟件產(chǎn)品質(zhì)量是企業(yè)的生命，如何保障產(chǎn)品質(zhì)量是軟件測試人員的主要責(zé)任，軟件測試工作不能保證產(chǎn)品沒有缺陷，但可以通過自己的努力確保將產(chǎn)品缺陷率降到最低化。軟件測試是軟件工程中必不可少的一個環(huán)節(jié)，存在就是價值，就有它存在的必要性，雖然在現(xiàn)階段軟件測試在公司內(nèi)的地位和受重視程度不如開發(fā)人員，相信在軟件技術(shù)日益開展的今天，質(zhì)量的重要性會越來越受到公司領(lǐng)導(dǎo)的重視，因為產(chǎn)品是效勞于客戶，客戶對產(chǎn)品質(zhì)量的穩(wěn)定性要求越來越嚴(yán)格，軟件測試的價值也會越來越得到認(rèn)可。8、測試工程師如何和開發(fā)人員做好溝通？測試工程師和開發(fā)工程師承當(dāng)?shù)氖情_發(fā)工作的兩個不同方面，說得極端一點，一個是創(chuàng)立，一個是破壞，雖然兩者的最終目的都是一樣的，但在達成目標(biāo)的方式上卻有很大的差異。因此，在為同一個目標(biāo)奮斗的過程中，發(fā)生沖突也是難免的，但通過下面的一些建議，換個視角看看開發(fā)人員的生活和工作，可能很多的沖突就能化解于無形了。最好的測試人員不是發(fā)現(xiàn)最多 BUG或是使得最多開發(fā)人員不自在的人， 而是能夠［說服開發(fā)人員］修正最多BUG的人〕，建議大家好好理解這句話。和開發(fā)人員交流的經(jīng)驗歸結(jié)為1、要耐心和細(xì)心細(xì)心是測試工程師的一個根本素質(zhì)，測試工程師是對質(zhì)量負(fù)責(zé)的人，涉及到質(zhì)量問題，就不能模糊，因此一定要細(xì)心，細(xì)心對待每一個可能的 BUG細(xì)心對待每一段被你檢查的代碼，細(xì)心對待每一個你撰寫的 BUG報告，細(xì)心對待你發(fā)出的每一封郵件。細(xì)心是一種態(tài)度，你的態(tài)度遲早會感染和你合作的開發(fā)人員，而這往往是合作愉快的根底。2、 要懂得尊重對方開發(fā)是一件需要全面和綜合考慮的工作，開發(fā)工作中，由于各種原因?qū)е鲁绦蛑谐霈F(xiàn)問題是很正常的現(xiàn)象，作為測試工程師，發(fā)現(xiàn)了這些問題并不值得你夸耀，也不能 說明你比開發(fā)工程師聰明。一個好的測試工程師一定是懂得尊重開發(fā)工程師的人，尊重對方的技術(shù)水平，尊重對方的代碼。我接觸過的開發(fā)人員都是挺和藹的，一般來說，對他們最大的尊重就是成認(rèn)他的專業(yè)水平，成認(rèn)他的代碼。對他們來說，代碼就像是自己的孩子一樣，因此，記得在適宜的時候表達你對他的尊重，贊揚一下他代碼的精妙之處。3、 要能設(shè)身處地為對方著想開發(fā)工程師一般都處在較大的工作壓力下，他的上司直接考核他們的指標(biāo)很大程度上是已完成的代碼，所以在工作任務(wù)緊張的時候，對于測試工程師報上來的BUG會拖延解決甚至是推脫，給測試工程師的感覺就是很不合作。那么在這個時候，就需要設(shè)身處地的為對方著想了，每個人都會為自己的工作在內(nèi)心排定優(yōu)先級，如果他 認(rèn)為解決你發(fā)現(xiàn)的BUG不是重要的事情，那么最大的可能就是你并沒有向他解釋清楚這個 BUG的嚴(yán)重程度。發(fā)現(xiàn)BUG是我們的責(zé)任，敦促BUG得到解決是我們更重要的責(zé)任，因此，我們可以心平氣和地和開發(fā)人員坐下來討論一下BUG的嚴(yán)重程度，和他一起排定BUG的優(yōu)先級別并確定解決的時間。4、 要有原那么不要忘記，測試工程師需要對產(chǎn)品的質(zhì)量負(fù)責(zé)，在這一點上一定要有原那么。測試工程師可以和開發(fā)工程師建立良好的個人關(guān)系，但在具體的事情上，一定要按照公司的 相關(guān)流程來處理。當(dāng)然，在堅持原那么的同時，可以采用一些委婉的表達方式，可以在允許的情況下盡量體諒開發(fā)工程師，但請記住，一個有原那么的測試工程師才能真 正幫助開發(fā)工程師，才能贏得開發(fā)工程師的尊重。5、要主動承當(dāng)如果開發(fā)工程師要求你承當(dāng)局部不屬于你的責(zé)任， 比方，定位你發(fā)現(xiàn)的BUG到代碼一級，或者是幫助他編寫部分文檔和代碼，在可能的情況下盡量多承當(dāng)。其實都是工作上的事情，有能力的話，多做一點也無妨。9、軟件測試工作的意義是什么？隨著軟件應(yīng)用領(lǐng)域越來越廣泛，其質(zhì)量的優(yōu)劣也日益受到人們的重視。軟件測試是一個成熟軟件企業(yè)的重要組成局部，它是軟件生命周期中一項非常重要且非常復(fù)雜的工作，對軟件可靠性保證具有極其重要的意義。在軟件測試過程中，應(yīng)該應(yīng)用各種軟件測試方法，以保證產(chǎn)品有一個較高較穩(wěn)定的質(zhì)量。根據(jù)不同的生產(chǎn)過程進行不同的測試，包括黑盒測試、白盒測試、功能測試、系統(tǒng)測試、壓力測試、安裝 /卸載測試、兼容性測試、a測試、B測試、如何減少缺陷的產(chǎn)生？在工程發(fā)布后發(fā)現(xiàn)和修復(fù)Bug的本錢是需求和設(shè)計階段所需的一百倍！在時下的軟件工程中大約有40-50%的人力都是花在可以防止的重復(fù)勞動中，防止重復(fù)勞動可以顯著提高勞動生產(chǎn)率。80%可防止的重復(fù)勞動源自于 20%的缺陷，其中兩大主要來源包括草率的需求定制和象征性的案例設(shè)計和開發(fā)。大約80%的缺陷來自20%的模塊，而約半數(shù)的模塊是幾乎沒有缺陷。90%的軟件的停工期最多來自于 10%的缺陷。同行評審能發(fā)現(xiàn)60%的缺陷！有針對性的評審能比無導(dǎo)向性的評審多發(fā)現(xiàn) 35%的缺陷！個人行為的標(biāo)準(zhǔn)化可以減少缺陷注入率高達 75%。在其他因素相同的情況下，開發(fā)高可靠性軟件每源代碼指令的本錢投入比開發(fā)低可靠性軟件要多出近50%。然而，如果工程需要很高的運行和維護本錢，這樣的投資是值得的。大約40-50%的用戶程序都存在著很大的缺陷。、缺陷是如何產(chǎn)生的？缺陷產(chǎn)生的根本原因可能是由以下方面引起的：編程：原始編程出錯，沒有客觀原因。修改：由于修改缺陷而引發(fā)的新變更，并且引發(fā)的變更與原變更的錯誤是相關(guān)的。培訓(xùn)：工程組新成員培訓(xùn)不充分，或使用新工具不熟練引起的變更。需求文檔：需求分析文檔不明確、不詳盡等原因所引起的變更。信息交流：信息交流不暢，開發(fā)成員間溝通不及時引起的變更。外部問題：所涉及軟件模塊外部問題引起的變更。其他：指以上各種原因之外所產(chǎn)生的變更。軟件發(fā)布后缺陷分析所用缺陷根本原因的的關(guān)鍵字，可以有下幾種實例：需求分析：需求分析缺乏等原因所引起的變更。系統(tǒng)設(shè)計：軟件系統(tǒng)設(shè)計種種原因所引起的變更。程序編碼：軟件開發(fā)階段中編程錯誤所引起的變更。維護：軟件發(fā)布后程序維護時引起的變更。實施：實施人員做軟件初始化設(shè)置或系統(tǒng)參數(shù)設(shè)置不當(dāng)?shù)龋瑢嵤r所引發(fā)的變更。用戶：泛指用戶不了解業(yè)務(wù)和軟件、不熟悉操作等原因產(chǎn)生的異常問題。數(shù)據(jù)異常：運行中不明原因引起的用戶數(shù)據(jù)混亂和異常。升級：軟件版本升級過程發(fā)生的問題，包括用戶在升級時未按規(guī)程操作產(chǎn)生的問題。外部問題：所涉及軟件外部問題引起的變更，包括屬操作系統(tǒng)、數(shù)據(jù)庫軟件、第三方軟件所引起的問題。錯誤變更：錯誤地提交的變更。包括無法重現(xiàn)出錯、所列現(xiàn)象不是錯誤的變更。其他：指以上各種原因之外的變更，包括變更原因不明。測試情況信息項是應(yīng)用于分析缺陷是如何通過測試關(guān)的?？梢杂幸韵聨追N實例：漏測試：軟件發(fā)布前測試時沒有被發(fā)現(xiàn)的缺陷，也沒有對應(yīng)測試用例。條件冷僻：缺陷形成條件很冷僻，設(shè)計測試用例時很難考慮到。回歸測試：專指那些原先測試時是通過的、不存在錯誤，后來由于修改其他程序時產(chǎn)生的缺陷。關(guān)鍵是軟件版本或補丁發(fā)布前未進行回歸測試，因而被漏過。判斷標(biāo)準(zhǔn)：測試時已發(fā)現(xiàn)該現(xiàn)象但當(dāng)時不認(rèn)為是問題，沒提交變更。已測試：測試時已發(fā)現(xiàn)缺陷并提交變更，但缺陷沒解決。12、 軟件缺陷的危害有哪些？軟件缺陷是軟件開發(fā)過程中的副產(chǎn)品，通常缺陷會導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足客戶需求。因此，妥善處理軟件中的缺陷是關(guān)系到軟件產(chǎn)品質(zhì)量的根本?？蛇z憾的是，并非所有的軟件團隊都知道如何有效地管理在測試中發(fā)現(xiàn)的缺陷。對于軟件測試人員而言，在測試中不能正確表示缺陷的嚴(yán)重程度和優(yōu)先級， 這將會影響到軟件缺陷管理的質(zhì)量，不僅不利于有效的處理軟件缺陷，還可能影響到軟件缺陷的處理時機。特別在軟件測試的后期，將影響軟件是否能夠按期發(fā)布與否。近期我在一個測試工程中，由于對缺陷嚴(yán)重程度和優(yōu)先級缺乏有效處理，最終導(dǎo)致軟件驗收發(fā)布被迫延后。軟件缺陷不只是通常所說程序中存在的錯誤或疏忽， 即俗稱的Bug。其范圍更大，除程序外還包括其相關(guān)產(chǎn)品：工程方案、需求規(guī)格說明、設(shè)計文檔、測試用例、用戶手冊等等中存在的錯誤和問題。需要強調(diào)，在軟件工程整個生命周期中任何背離需求、無法正確完成用戶所要求的功能的問題，包括存在于組件、設(shè)備或系統(tǒng)軟件中因異常條件不支持而導(dǎo)致系統(tǒng)的失敗等都屬于缺陷的范疇。軟件測試的任務(wù)就是發(fā)現(xiàn)軟件系統(tǒng)的缺陷，保證軟件的優(yōu)良品質(zhì)。但在軟件中是不可能沒有缺陷的。即便軟件開發(fā)人員，包括測試人員盡了努力，也是無法完全發(fā)現(xiàn)和消除缺陷。如何做到最大限度地發(fā)現(xiàn)軟件系統(tǒng)的缺陷，人們首先想到提高開發(fā)人員的素質(zhì)和責(zé)任心，科學(xué)地應(yīng)用測試方法和制定優(yōu)秀的測試方案。但這是不夠的，我們還需要實施缺陷分析。缺陷分析是將軟件開發(fā)、運行過程中產(chǎn)生的缺陷進行必要的收集，對缺陷的信息進行分類和匯總統(tǒng)計，計算分析指標(biāo)，編寫分析報告的活動。通過缺陷分析，發(fā)現(xiàn)各種類型缺陷發(fā)生的概率，掌握缺陷集中的區(qū)域、明晰缺陷開展趨勢、了解缺陷產(chǎn)生主要原因。以便有針對性地提出遏制缺陷發(fā)生的措施、降低缺陷數(shù)量。對于改進軟件開發(fā)，提高軟件質(zhì)量有著十分重要的作用。缺陷分析報告中的統(tǒng)計數(shù)據(jù)及分析指標(biāo)既是對軟件質(zhì)量的權(quán)威評估， 也是判定軟件是否能發(fā)布或交付使用的重要依據(jù)。13、 簡述下軟件為什么要測試。測試就是為了讓產(chǎn)品在交付給最終用戶以后，在產(chǎn)品生存周期〔或提供有效效勞的期限以內(nèi)〕 ，不讓最終用戶發(fā)現(xiàn)其所不能接受的現(xiàn)象。 良好的測試，可以有效的降低維護的本錢。用戶如果滿意你的產(chǎn)品，就不會一而再、再而三的要求改進，維護的本錢自然會下降。 當(dāng)然，測試本身的本錢也是不低的，所以為了讓我們?yōu)闇y試付出的代價物有所值〔大概還沒有人會說自己的產(chǎn)品從未經(jīng)過測試吧〕 ，我們很有必要去認(rèn)真的了解一下關(guān)于測試的一些東西。14、 簡述TMM測試成熟度分解TMM測試成熟度分解為5級別，關(guān)注于5個成熟度級別遞增：Phase0:測試和調(diào)試沒有區(qū)別，初了支持調(diào)試外，測試沒有其他目的Phase1 :測試的目的是為了說明軟件能夠工作Phase2 :測試的目的是為了說明軟件不能夠能夠正常工作Phase3 :測試的目的不是要證明什么，而是為了把軟件不能正常工作的預(yù)知風(fēng)險降低到能夠接受的程度Phase4 :測試不是行為，而是一種自覺的約束(mentaldiscipline) ，不用太多的測試投入產(chǎn)生低風(fēng)險的軟件上的。

15、簡述W模型的概念和示意圖:W模型強調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計等同樣要測試，也就是說，測試與開發(fā)是同步進行的。 W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗證和確認(rèn)活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解工程難度和測試風(fēng)險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快工程進度。16、簡述瀑布模型的概念和示意圖：瀑布模型要求軟件開發(fā)嚴(yán)格按照需求-＞分析-＞設(shè)計-＞編碼-＞測試的階段進行，每一個階段都可以定義明確的產(chǎn)出物和驗證準(zhǔn)那么?瀑布模型在每一個階段完成后都可以組織相關(guān)的評審和驗證 ，只有在評審?fù)ㄟ^后才能夠進入到下一個階段?由于需要對每一個階段進行驗證，瀑布模型要求每一個階段都有明確的文檔產(chǎn)出 ，對于嚴(yán)格的瀑布模型每一個階段都不應(yīng)該重疊，而應(yīng)該是在評審?fù)ㄟ^，相關(guān)的產(chǎn)出物都已經(jīng)基線后才能夠進入到下一個階段17、簡述螺旋模型的概念和示意圖：首先螺旋模型是遵從瀑布模型的 ?即需求-＞架構(gòu)-＞設(shè)計-＞開發(fā)-＞測試的路線?螺旋模型最大的價值在于整個開發(fā)過程是迭代和風(fēng)險驅(qū)動的?通過將瀑布模型的多個階段轉(zhuǎn)化到多個迭代過程中 ，以減少工程的風(fēng)險?

制走計創(chuàng)異計

本錢決定目標(biāo)方案和限制評價方秦識別區(qū)蹬開發(fā)、臉證制走計創(chuàng)異計

本錢決定目標(biāo)方案和限制評價方秦識別區(qū)蹬開發(fā)、臉證下一產(chǎn)品螺旋模型的每一次迭代都包含了以下六個步驟決定目標(biāo),替代方案和約束識別和解決工程的風(fēng)險評估技術(shù)方案和替代解決方案開發(fā)本次迭代的交付物和驗證迭代產(chǎn)出的正確性方案下一次迭代提交下一次迭代的步驟和方案 .18、 簡述敏捷的開發(fā)流程：AgileProcess( 敏捷的開發(fā)流程)是一種軟體開發(fā)流程的泛稱， AgileProcess 具有以下幾項共通的特性：客戶與開發(fā)人員形成密切合作的團隊，因為客戶無法于初期定義完整的規(guī)格，而開發(fā)人員于開發(fā)過程中也常常無法知悉外在環(huán)境或業(yè)務(wù)的變動，所以需要兩者密切合作方能開發(fā)適用的軟體。專案最終的目標(biāo)是可執(zhí)行的程式，因此所有的中間產(chǎn)品必須經(jīng)過審慎評估，確認(rèn)有助于最終目標(biāo)，才需要制作中間產(chǎn)品。采用Iterative與Incremental方式分階段進行，密集 review是否符合需求。流程可以簡單，但規(guī)劃與執(zhí)行必須嚴(yán)謹(jǐn)。強調(diào)團隊合作，賦予高度的責(zé)任，團隊有自主權(quán)得以因應(yīng)變化做調(diào)整。19、 簡述RUP開發(fā)流程：RUP(-RationalUnifyProcess)為IBMRational 公司經(jīng)過多年的研發(fā)與經(jīng)驗所提岀的軟體開發(fā)流程，其內(nèi)容含蓋Businessmodeling,RequirementModeling,LogicalDesign,Implementation,Testing,Deployment 等軟體開發(fā)生命周期的直接工作，與ProjectManagement,Change&ConfigurationManagement ，Environmentsupport等支援性工作。 RUP的內(nèi)容非常豐富，不同的專案需要不同調(diào)整， IBMRational提供RUPworkbench工具，方便調(diào)整RUP并公布于Web方便專案成員遵循統(tǒng)一的流程標(biāo)準(zhǔn)進行工作。RUP的主要精神為：1.專案進行采用Iterative 程序分階段漸進地完成專案功能； 2.廣泛使用VisualModeling于商業(yè)需求分析、系統(tǒng)分析與系統(tǒng)設(shè)計； 3.強調(diào)架構(gòu)設(shè)計；4.對每項工作所需要的技術(shù)、工具、做法、范本、檢查工程均有詳細(xì)的定義，架構(gòu)完備且具有可調(diào)整的彈性。因為RUP的流程標(biāo)準(zhǔn)與相關(guān)技術(shù)較復(fù)雜，所以導(dǎo)入時必須注意幾個因素： 1.主管的支持以確保足夠的資源投入； 2.分階段導(dǎo)入；3.適當(dāng)?shù)挠?xùn)練與密切的參謀咨詢；4.使用Modeling技術(shù)時需要考量Coding的實作環(huán)境；5.良好團隊的管理，以溝通、耐心與堅持解決變革的人性阻力。20、 簡述XP開發(fā)流程XP亦稱為終極流程，是最輕量級的開發(fā)流程，其最主要的精神是『在客戶有系統(tǒng)需求時，給予及時滿意的可執(zhí)行程式』，所以最適合需求快速變動的專案。XP經(jīng)過6年的實作與修改，已演化為精致的開發(fā)流程，但仍不失其精簡的特性，它強調(diào)客戶所要的是workable的執(zhí)行碼，所以把與撰寫程式無關(guān)的工作降至最低，并要求客戶與開發(fā)人員最好以side-by-side的方式一起工作。XP開發(fā)流程的根本步驟為： 1.開發(fā)人員隨時可以和客戶進行有效溝通，撰寫 userstories 以確認(rèn)需求。 2.簡易快速的系統(tǒng)設(shè)計，撰寫?yīng)毩⒌尿炞C程式以解決特殊困難的問題，找出演算法即可丟棄驗證程式。 3.規(guī)劃屢次小型階段的專案方案，以最快速度完成每一階段的程式交付客戶，客戶負(fù)責(zé) Acceptancetests；4.Coding前必須完成UnitTest與Acceptancetests程序，所有模組整合前都須經(jīng)過UnitTests；5.開發(fā)人員必須快速回應(yīng)Bug與需求變更；6.要求二人一組使用一臺電腦設(shè)計程式，當(dāng)一人coding時，另一人負(fù)責(zé)思考與設(shè)計；7.程式必須符合程式標(biāo)準(zhǔn)，并常做程式的重整(Refactoring) 。XP屬于較精簡的流程，于導(dǎo)入應(yīng)注意幾件事情： 1.最好有參謀給予協(xié)助； 2.持續(xù)的Review；3.可適當(dāng)調(diào)整流程，但不可失去其根本精神。21、 簡述SCRUM開發(fā)流程SCRUMF發(fā)流程是AgileProcess的一種，以英式橄欖球爭球隊形 (Scrum)為名，根本假設(shè)是『開發(fā)軟體就像開發(fā)新產(chǎn)品，無法一開始就能定義FinalProduct的規(guī)程，過程中需要研發(fā)、創(chuàng)意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功』。Scrum將軟體開發(fā)團隊比較成橄欖球隊，有明確的最高目標(biāo)，熟悉開發(fā)流程中所需具備的最正確典范與技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，碓保每天、每個階段都朝向目標(biāo)有明確的推進，因此SCRUM非常適用于產(chǎn)品開發(fā)專案。SCRUMFF發(fā)流程通常以30天為一個階段，由客戶提供新產(chǎn)品的需求規(guī)格開始， 開發(fā)團隊與客戶于每一個階段開始時挑選該完成的規(guī)格部份，開發(fā)團隊必須盡力于30天后交付成果，團隊每天用15分鐘開會檢視每個成員的進度與計畫，了解所遭遇的困難并設(shè)法排除。SCRUM與傳統(tǒng)開發(fā)流程及專案管理差異較大，于導(dǎo)入時最好有參謀協(xié)助。22、簡述測試工具的分類測試工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理〔測試流程管理、缺陷跟蹤管理、測試用例管理〕的工具，白盒測試工具白盒測試工具一般是針對代碼進行測試，測試中發(fā)現(xiàn)的缺陷可以定位到代碼級，根據(jù)測試工具原理的不同，又可以分為靜態(tài)測試工具和動態(tài)測試工具。靜態(tài)測試工具：直接對代碼進行分析，不需要運行代碼，也不需要對代碼編譯鏈接，生成可執(zhí)行文件。靜態(tài)測試工具一般是對代碼進行語法掃描，找出不符合編碼標(biāo)準(zhǔn)的地方，根據(jù)某種質(zhì)量模型評價代碼的質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。靜態(tài)測試工具的代表有：Telelogic公司的Logiscope軟件；PR公司的PRQA軟件。動態(tài)測試工具：動態(tài)測試工具與靜態(tài)測試工具不同，動態(tài)測試工具的一般采用 "插樁"的方式，向代碼生成的可執(zhí)行文件中插入一些監(jiān)測代碼，用來統(tǒng)計程序運行時的數(shù)據(jù)。其與靜態(tài)測試工具最大的不同就是動態(tài)測試工具要求被測系統(tǒng)實際運行。動態(tài)測試工具的代表有：Compuware公司的DevPartner軟件；Rational公司的Purify系列等。黑盒測試工具黑盒測試工具適用于黑盒測試的場合，黑盒測試工具包括功能測試工具和性能測試工具。黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作，然后將被測系統(tǒng)的輸出記錄下來同預(yù)先給定的標(biāo)準(zhǔn)結(jié)果比較。黑盒測試工具可以大大減輕黑盒測試的工作量，在迭代開發(fā)的過程中，能夠很好地進行回歸測試。黑盒測試工具的代表有：Rational公司的TeamTest、Robot；Compuware公司的QACenter。性能測試工具專用于性能測試的工具包括有：Radview公司的WebLoad;Microsoft公司的We