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

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

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

制走計(jì)創(chuàng)異計(jì)

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

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