【正文】 設(shè)計(jì)將測(cè)試計(jì)劃階段制訂的測(cè)試需求分解、細(xì)化為若干個(gè)可執(zhí)行的測(cè)試過(guò)程，并為每個(gè)測(cè)試過(guò)程選擇適當(dāng)?shù)臏y(cè)試用例（測(cè)試用例選擇的好壞將直接影響測(cè)試結(jié)果的有效性）。這樣做的具體目的有如下幾點(diǎn)：(1)可以在準(zhǔn)生產(chǎn)環(huán)境中運(yùn)行新系統(tǒng)而又不冒風(fēng)險(xiǎn)；(2)用戶能有一段熟悉新系統(tǒng)的時(shí)間；(3)可以驗(yàn)證用戶指南和使用手冊(cè)之類的文檔；(4)能夠以準(zhǔn)生產(chǎn)模式對(duì)新系統(tǒng)進(jìn)行全負(fù)荷測(cè)試，可以用測(cè)試結(jié)果驗(yàn)證性能指標(biāo)。驗(yàn)收測(cè)試的目的是驗(yàn)證系統(tǒng)確實(shí)能夠滿足用戶的需要，在這個(gè)測(cè)試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說(shuō)明書中的錯(cuò)誤。在這個(gè)過(guò)程中不僅應(yīng)該發(fā)現(xiàn)設(shè)計(jì)和編碼的錯(cuò)誤，還應(yīng)該驗(yàn)證系統(tǒng)確實(shí)能提供需求說(shuō)明書中指定的功能，而且系統(tǒng)的動(dòng)態(tài)特性也符合預(yù)定要求。在這個(gè)測(cè)試步驟中所發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計(jì)的錯(cuò)誤。1． 測(cè)試過(guò)程中會(huì)產(chǎn)生哪些基本文檔？（1）測(cè)試計(jì)劃（通常包括單元測(cè)試和集成測(cè)試）：確定測(cè)試范圍、方法和需要的資源（2）測(cè)試過(guò)程：詳細(xì)描述和每個(gè)測(cè)試方案有關(guān)的測(cè)試步驟和數(shù)據(jù)（包括測(cè)試數(shù)據(jù)及預(yù)期的結(jié)果）；（3）測(cè)試結(jié)果：把每次測(cè)試運(yùn)行的結(jié)果歸入文檔，如果運(yùn)行出錯(cuò)，則應(yīng)產(chǎn)生 問(wèn)題報(bào)告，并且必須通過(guò)調(diào)試解決所發(fā)現(xiàn)的問(wèn)題。通常在編碼階段進(jìn)行，必要的時(shí)候要制作驅(qū)動(dòng)模塊和樁模塊。5． 黑盒測(cè)試又稱為功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，把系統(tǒng)看成一個(gè)黑盒子，不考慮程序的內(nèi)在邏輯，只根據(jù)需求規(guī)格說(shuō)明書的要求來(lái)檢查程序的功能是否符合它的功能說(shuō)明。軟件缺陷報(bào)告Software Bug Report（SBR）或軟件問(wèn)題報(bào)告Software Problem Report（SPR）2． 回歸測(cè)試是指重新執(zhí)行已經(jīng)做過(guò)的測(cè)試的某個(gè)子集，以保證修改變化沒(méi)有帶來(lái)非預(yù)期的副作用。10． 軟件測(cè)試按照開(kāi)發(fā)階段劃分單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、確認(rèn)測(cè)試、驗(yàn)收測(cè)試。6． 系統(tǒng)測(cè)試時(shí)在集成測(cè)試完成后，確認(rèn)測(cè)試之前進(jìn)行的測(cè)試。2． 功能測(cè)試時(shí)系統(tǒng)測(cè)試的主要內(nèi)容，檢查系統(tǒng)的功能、性能是否與需求規(guī)格說(shuō)明相同。19． 測(cè)試通?？煞譃榘缀袦y(cè)試和黑盒測(cè)試。4． 單元測(cè)試一般以白盒測(cè)試法為主，測(cè)試的依據(jù)是模塊功能規(guī)格說(shuō)明。第一篇：軟件測(cè)試復(fù)習(xí)資料1． 黑盒測(cè)試法是通過(guò)分析程序的功能來(lái)設(shè)計(jì)測(cè)試用例的方法。5． 軟件測(cè)試中常用的靜態(tài)分析方法是引用分析和接口分析。白盒測(cè)試是根據(jù)程序的內(nèi)部邏輯來(lái)設(shè)計(jì)測(cè)試用例,黑盒測(cè)試是根據(jù)軟件的規(guī)格說(shuō)明來(lái)設(shè)計(jì)測(cè)試用例。3． 軟件測(cè)試主要分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試四類測(cè)試。7． 設(shè)計(jì)系統(tǒng)測(cè)試計(jì)劃需要參考的項(xiàng)目文檔有軟件測(cè)試計(jì)劃、軟件需求工件、和迭代計(jì)劃。11． 軟件測(cè)試按照測(cè)試技術(shù)劃分性能測(cè)試、負(fù)載測(cè)試、壓力測(cè)試、恢復(fù)測(cè)試、安全測(cè)試、兼容測(cè)試12． 靜態(tài)測(cè)試基本特征是在對(duì)軟件進(jìn)行分析、檢查和審閱，不實(shí)際運(yùn)行被測(cè)試的軟件 13． 軟件測(cè)試項(xiàng)目周期是指需求階段、測(cè)試計(jì)劃、階段測(cè)試、設(shè)計(jì)階段測(cè)試、執(zhí)行階段 14． 軟件測(cè)試的角色分析人員、設(shè)計(jì)人員、開(kāi)發(fā)人員、執(zhí)行人員 15． 軟件測(cè)試原則有制定嚴(yán)格的測(cè)試計(jì)劃、保留所有的測(cè)試文檔、功能測(cè)試中的缺陷確認(rèn)16． 測(cè)試工作的文檔主要有：測(cè)試計(jì)劃、測(cè)試模型和用例設(shè)計(jì)或規(guī)格說(shuō)明、測(cè)試分析報(bào)告等17． 測(cè)試計(jì)劃的制定必須要注重測(cè)試策略、測(cè)試范圍、測(cè)試方法、測(cè)試安排、測(cè)試風(fēng)險(xiǎn)、測(cè)試治理18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設(shè)計(jì)的缺陷、靜態(tài)文檔的缺陷、軟件開(kāi)發(fā)引起的缺陷、短視將來(lái)的缺陷 19． 測(cè)試用例工作主要是如何添加測(cè)試用例、如何編寫測(cè)試用例、將測(cè)試用例和需求關(guān)聯(lián)20． 自動(dòng)化測(cè)試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測(cè)試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設(shè)計(jì)階段的BUG、實(shí)現(xiàn)階段的BUG、配置階段的BUG、靜態(tài)文檔的BUG。3． 動(dòng)態(tài)測(cè)試 通過(guò)運(yùn)行軟件來(lái)檢驗(yàn)軟件的動(dòng)態(tài)行為和運(yùn)行結(jié)果的正確性。6． 路徑覆蓋的含義是，選取足夠多的測(cè)試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個(gè)環(huán)至少經(jīng)過(guò)一次)。9． 集成測(cè)試：在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)，應(yīng)提交集成測(cè)試計(jì)劃、集成測(cè)試規(guī)格說(shuō)明和集成測(cè)試分析報(bào)告。（4）? 1）.模塊測(cè)試在設(shè)計(jì)得好的軟件系統(tǒng)中，每個(gè)模塊完成一個(gè)清晰定義的子功能，而且這個(gè)子功能和同級(jí)其他模塊的功能之間沒(méi)有相互依賴關(guān)系。2）.子系統(tǒng)測(cè)試子系統(tǒng)測(cè)試是把經(jīng)過(guò)單元測(cè)試的模塊放在一起形成一個(gè)子系統(tǒng)來(lái)測(cè)試。在這個(gè)測(cè)試步驟中發(fā)現(xiàn)的往往是軟件設(shè)計(jì)中的錯(cuò)誤，也可能發(fā)現(xiàn)需求說(shuō)明中的錯(cuò)誤。驗(yàn)收測(cè)試也稱為確認(rèn)測(cè)試。？分別闡述一下各個(gè)階段。3）測(cè)試開(kāi)發(fā)建立可重復(fù)使用的自動(dòng)測(cè)試過(guò)程。？其中哪些是最重要的？1)測(cè)試計(jì)劃的內(nèi)容：測(cè)試目的和測(cè)試項(xiàng)目簡(jiǎn)介、測(cè)試參考文檔和測(cè)試提交文檔、術(shù)語(yǔ)和定義、測(cè)試策略、確定測(cè)試內(nèi)容、資源、測(cè)試進(jìn)度、測(cè)試員的職責(zé)與任務(wù)分配、項(xiàng)目通過(guò)或失敗的標(biāo)準(zhǔn)、暫停和重新啟動(dòng)測(cè)試的標(biāo)準(zhǔn)、風(fēng)險(xiǎn)和問(wèn)題等。對(duì)需求規(guī)格說(shuō)明書、軟件設(shè)計(jì)說(shuō)明書、源程序做檢查和審閱。動(dòng)態(tài)測(cè)試方法：(1)選取定義域有效值,或定義域外無(wú)效值；(2)對(duì)已選取值決定預(yù)期的結(jié)果；(3)用選取值執(zhí)行程序；(4)執(zhí)行結(jié)果與預(yù)期的結(jié)果相比,不吻和程序有錯(cuò)。驗(yàn)證SRS中的性能需求，是否實(shí)現(xiàn)。？：a)等價(jià)類劃分：劃分等價(jià)類確立測(cè)試用例設(shè)計(jì)用例。這適合于檢查程序輸入條件的各種組合情況。如果某個(gè)等價(jià)類的一個(gè)輸入數(shù)據(jù)（代表值）測(cè)試中查出了錯(cuò)誤，說(shuō)明該類中其他測(cè)試用例也會(huì)有錯(cuò)誤。(3)pareto原則：測(cè)試發(fā)現(xiàn)的錯(cuò)誤中的80%很可能是由程序中20%的模塊造成的。（8）程序修改后要回歸測(cè)試?！耙粋€(gè)程序讀入三個(gè)整數(shù)。系統(tǒng)日期規(guī)定由年、月的6位數(shù)字字符組成，前四位代表年，后兩位代表月。若投入1元5角硬幣，按下“可樂(lè)”、“雪碧”或“紅茶”按鈕，相應(yīng)的飲料就送出來(lái)。測(cè)試和測(cè)試的人有很大關(guān)系。測(cè)試人員要做的是能夠正確判斷什么時(shí)候不能追求軟件的完美。有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級(jí)中進(jìn)行修復(fù)。 建議我們從以下兩個(gè)方面做起：加強(qiáng)部門內(nèi)員工之間的互相學(xué)習(xí)，互相學(xué)習(xí)是建立學(xué)習(xí)型組織的基本要求，是知識(shí)互相轉(zhuǎn)移的過(guò)程。這需要提前做好準(zhǔn)備，這些核心功能一定要預(yù)先經(jīng)過(guò)測(cè)試，證明沒(méi)有問(wèn)題才可以和用戶共同進(jìn)行測(cè)試。爭(zhēng)得時(shí)間后，及時(shí)修改缺陷來(lái)彌補(bǔ)。類的繼承導(dǎo)致所有的子類會(huì)包含基類的錯(cuò)誤，反復(fù)拷貝同一代碼意味可能也復(fù)制了缺陷。測(cè)試人員只要嚴(yán)肅認(rèn)真的測(cè)試程序就可以了。軟件測(cè)試和質(zhì)量是相輔相成的關(guān)系，都是為了提高軟件質(zhì)量而工作。而做項(xiàng)目通常面向某一用戶，雖然質(zhì)量越高越好，但是一般只要滿足用戶要求就可以了。項(xiàng)目最后要和用戶共同驗(yàn)收測(cè)試，這是產(chǎn)品測(cè)試不具有的特點(diǎn)。二、論述2*12’，并列舉歷史上2~3個(gè)著名軟件測(cè)試（缺陷）案例，說(shuō)明測(cè)試重要性軟件測(cè)試的目的,第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望做的事情（，另一方面是確認(rèn)軟件以正確的方式來(lái)做了這個(gè)事情。因此，軟件測(cè)試的第三個(gè)目的是保證整個(gè)軟件開(kāi)發(fā)過(guò)程是高質(zhì)量的。1983–1987－評(píng)估為主 人們提出了在軟件生命周期中使用分析，評(píng)審，測(cè)試來(lái)評(píng)估產(chǎn)品的理論。軟件本身：①需求不清晰，導(dǎo)致設(shè)計(jì)目標(biāo)偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。⑤沒(méi)有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問(wèn)題，從而存在系統(tǒng)安全性、可靠性的隱患。⑧新技術(shù)的采用，可能涉及技術(shù)或系統(tǒng)兼容的問(wèn)題，事