軟件測(cè)試技術(shù)經(jīng)典教程筆記(修)

《軟件測(cè)試技術(shù)經(jīng)典教程筆記(修)》由會(huì)員分享，可在線閱讀，更多相關(guān)《軟件測(cè)試技術(shù)經(jīng)典教程筆記(修)（10頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

第一章 基礎(chǔ)知識(shí) 1.1、軟件 1)、軟件=程序+文檔 2)、分類 功能：系統(tǒng)+應(yīng)用 架構(gòu)：?jiǎn)螜C(jī)+C/S+B/S 用戶：產(chǎn)品+項(xiàng)目 規(guī)模：小型+中型+大型 1.2、Bug 1)、類型一(廣義上，軟件生命周期，與用戶需求不符的問(wèn)題)： 完全沒(méi)有實(shí)現(xiàn)的功能 基本實(shí)現(xiàn)功能，但有功能上或性能上的問(wèn)題 實(shí)現(xiàn)了用戶不需要的功能 2)、類型二(測(cè)試執(zhí)行階段的問(wèn)題) Defect---------Requirements&Design Error-----------Development Bug------------Testing Failure---------Post production 1.3、測(cè)試 1)、概念： 測(cè)試是為了檢驗(yàn)實(shí)際的軟件是否符合用戶需求，所以不能為了發(fā)現(xiàn)錯(cuò)誤而發(fā)現(xiàn)錯(cuò)誤。使用人工或自動(dòng)手段，來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過(guò)程。 2)、測(cè)試環(huán)境：硬件+軟件+網(wǎng)絡(luò) 要求：真實(shí)(項(xiàng)目、產(chǎn)品)+干凈+無(wú)毒+獨(dú)立(測(cè)試與開(kāi)發(fā)) 1.4、測(cè)試用例 測(cè)試用例=輸入+輸出+測(cè)試環(huán)境 便于團(tuán)隊(duì)交流，便于重復(fù)測(cè)試，便于跟蹤統(tǒng)計(jì)，比納與用戶自測(cè) 開(kāi)發(fā)生命周期 需求分析 → 概要設(shè)計(jì) → 詳細(xì)設(shè)計(jì) → 編碼 → 維護(hù) 測(cè)試生命周期 測(cè)試計(jì)劃 → 測(cè)試設(shè)計(jì) → 測(cè)試執(zhí)行 → 測(cè)試評(píng)估 需求分析和測(cè)試計(jì)劃完成后，根據(jù)《系統(tǒng)需求規(guī)格說(shuō)明書(shū)》和軟件原型(DEMO)寫(xiě)測(cè)試用例 1.5 其他 1)、測(cè)試人員素質(zhì)要求：細(xì)心、耐心、信心、服務(wù)意識(shí)、團(tuán)隊(duì)合作意識(shí)、溝通能力 2)、如何成為優(yōu)秀的測(cè)試工程師：1、不斷學(xué)習(xí)充電 2、閱讀原版書(shū)籍 3、閱讀缺陷管理系統(tǒng)中的缺陷報(bào)告 4、閱讀高手寫(xiě)的測(cè)試用例 5、學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識(shí) 1.6 軟件測(cè)試的基本規(guī)則 1) Zero Bug 與 Good Enough Good Enough原則：不充分測(cè)試是不負(fù)責(zé)任，過(guò)分的測(cè)試是一種資源浪費(fèi)。 參考：*遺留bug不超過(guò)10個(gè)，嚴(yán)重的不超過(guò)5個(gè) *測(cè)試用例執(zhí)行率為100%，通過(guò)率為95% *單元測(cè)試，關(guān)鍵模塊語(yǔ)句覆蓋率達(dá)到100%，分支覆蓋率達(dá)到85% 2) 不要視圖窮舉法 3) 開(kāi)發(fā)人員不能既是運(yùn)動(dòng)員又是裁判員 4) 軟件測(cè)試要盡早執(zhí)行 5) 軟件測(cè)試應(yīng)該追溯需求 原始需求 需求分析 正確的規(guī)格說(shuō)明 錯(cuò)誤的規(guī)格說(shuō)明 設(shè)計(jì) 正確的設(shè)計(jì) 錯(cuò)誤的設(shè)計(jì) 對(duì)錯(cuò)誤說(shuō)明的設(shè)計(jì) 編碼 正確編碼 錯(cuò)誤的編碼 對(duì)錯(cuò)誤設(shè)計(jì)編碼 對(duì)錯(cuò)誤說(shuō)明設(shè)計(jì)的編碼 測(cè)試 正確功能 可改正的錯(cuò)誤 不可改正的錯(cuò)誤 潛伏的錯(cuò)誤 不完善的軟件產(chǎn)品 6) 缺陷的二八定理 一般情況下，軟件80%的缺陷集中在20%的模塊中。 7) 缺陷具有免疫性 缺陷具有免疫性，需要根據(jù)新版本修改維護(hù)測(cè)試用例，另外，有一個(gè)值得注意的經(jīng)驗(yàn)：沒(méi)修復(fù)3-4個(gè)bug，可能會(huì)產(chǎn)生一個(gè)新bug。 第二章 測(cè)試分類 2.1、是否運(yùn)行程序 Static Testing------------代碼規(guī)范、界面、文檔 Dynamic Testing--------運(yùn)行程序 2.2、根據(jù)階段分類 Unit Testing(單元測(cè)試)----------10% 最小模塊，依據(jù)源程序和《詳細(xì)設(shè)計(jì)》 白盒測(cè)試人員||開(kāi)發(fā)人員 編譯代碼→靜態(tài)測(cè)試→動(dòng)態(tài)測(cè)試 樁模塊(Stub)、驅(qū)動(dòng)模塊(Driver) Integration Testing(集成測(cè)試)----------20% 模塊間的接口，依據(jù)單元測(cè)試的模塊和《概要設(shè)計(jì)》 白盒測(cè)試人員||開(kāi)發(fā)人員 一般單元和集成同步進(jìn)行 System Testing(系統(tǒng)測(cè)試)----------40% 整個(gè)系統(tǒng)(功能、性能、軟硬件環(huán)境)，依據(jù)《需求規(guī)格說(shuō)明書(shū)》 黑盒測(cè)試工程師 Acceptance Testing(驗(yàn)收測(cè)試)----------20% 整個(gè)系統(tǒng)(功能、性能、軟硬件環(huán)境)，依據(jù)《需求規(guī)格說(shuō)明書(shū)》和驗(yàn)收標(biāo)準(zhǔn) 用戶，可配合黑盒測(cè)試工程師 α測(cè)試：內(nèi)側(cè) β測(cè)試：公測(cè) 2.3、是否查看代碼 1)、White-Box Testing-----源代碼的測(cè)試 2)、Black-Box Testing-----功能測(cè)試、性能測(cè)試 Function Testing(功能測(cè)試) Logic Function Testing(邏輯功能測(cè)試) UI Testing(界面測(cè)試)：窗口、下拉式菜單和鼠標(biāo)操作 Usability Tseting(易用性測(cè)試) Installation Testing(安裝測(cè)試) Compatibility Testing(兼容性測(cè)試) 其他：恢復(fù)測(cè)試、裸機(jī)測(cè)試、確認(rèn)測(cè)試、接口測(cè)試、數(shù)據(jù)庫(kù)測(cè)試、安全測(cè)試、配置測(cè)試 Performance Testing(性能測(cè)試) 時(shí)間性能：主要指一個(gè)事務(wù)的具體響應(yīng)時(shí)間(Respind Time)。 空間性能：主要指軟件運(yùn)行時(shí)所消耗的系統(tǒng)資源(CPU、內(nèi)存、硬盤(pán))。 分類：一般性能測(cè)試、穩(wěn)定性測(cè)試、負(fù)載測(cè)試、壓力測(cè)試 a、一般性能測(cè)試：讓被測(cè)系統(tǒng)在正常的軟硬件環(huán)境下運(yùn)行，不向其施加任何壓力 b、穩(wěn)定性測(cè)試(也叫Reliability Testing 可靠性測(cè)試)：指連續(xù)運(yùn)行被測(cè)系統(tǒng)，檢查系統(tǒng)運(yùn)行時(shí)的穩(wěn)定程度。通常用MTBF(Mean Time Between Failure) c、負(fù)載測(cè)試(Load Testing)：讓被測(cè)系統(tǒng)在其能忍受的壓力極限范圍內(nèi)連續(xù)運(yùn)行，檢測(cè)系統(tǒng)的穩(wěn)定性。 d、壓力測(cè)試(Stress Testing)：持續(xù)不斷的給被測(cè)系統(tǒng)增加壓力，知道被測(cè)系統(tǒng)壓垮為止，用來(lái)測(cè)試系統(tǒng)能承受最大壓力。 2.4、回歸測(cè)試、冒煙測(cè)試、隨機(jī)測(cè)試 Regression Testing(回歸測(cè)試)：軟件新版本測(cè)試時(shí)，重新執(zhí)行上一個(gè)版本測(cè)試用例?？梢栽谌魏坞A段進(jìn)行（單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試等），既有黑盒測(cè)試的回歸，也有白盒測(cè)試的回歸。 Smoke Testing(冒煙測(cè)試)：對(duì)一個(gè)新版本進(jìn)行系統(tǒng)大規(guī)模的測(cè)試之前，先驗(yàn)證一下軟件的基本功能是否實(shí)現(xiàn)，是否具備可測(cè)性。 Random Testing(隨機(jī)測(cè)試)：指測(cè)試中所有的輸入數(shù)據(jù)都是隨機(jī)生成的，其目的是模擬用戶的真實(shí)操作，并發(fā)現(xiàn)一些邊緣性的錯(cuò)誤。 第三章 測(cè)試技術(shù) 黑盒測(cè)試技術(shù) 3.1、等價(jià)類技術(shù)(Equivalence Class Testing) 等價(jià)類：某個(gè)輸入域的子集合。在該子集合中，各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的。 有效等價(jià)類：符合《需求規(guī)則說(shuō)明書(shū)》，合理地輸入數(shù)據(jù)集合 無(wú)效等價(jià)類：不符合《需求規(guī)則說(shuō)明書(shū)》，無(wú)意義的輸入數(shù)據(jù)集合 等價(jià)類劃分步驟： 1)先考慮輸入數(shù)據(jù)的類型(合法和非法) 2)再考慮數(shù)據(jù)范圍 3)畫(huà)出示意圖，區(qū)分等價(jià)類 4)為每個(gè)等價(jià)類編號(hào) 5)從等價(jià)類中選擇測(cè)試數(shù)據(jù)構(gòu)造用例 3.2、邊界值技術(shù)(Boundary Value Testing) 3.3、因果圖法(Cause-Effect Graphs) 因果圖法步驟 1)找出所有的輸入條件和輸出，并編號(hào) 2)分析輸入條件之間的關(guān)系，是互斥還是可以同時(shí)滿足 3)畫(huà)出輸入條件的排列組合情況 4)編寫(xiě)測(cè)試用例 因果圖試用于輸入條件過(guò)多 3.4、流程圖法(Workflow Method) 流程圖法步驟 1)詳細(xì)了解需求 2)根據(jù)需求說(shuō)明或界面原型，找出業(yè)務(wù)流程的各個(gè)頁(yè)面及各頁(yè)面之間的流轉(zhuǎn)關(guān)系 3)畫(huà)出業(yè)務(wù)流圖 4)寫(xiě)用例，覆蓋所有路徑分支 流程圖法是針對(duì)整個(gè)系統(tǒng)，而非某個(gè)頁(yè)面或模塊 還有其他如：判定表、錯(cuò)誤推測(cè)、場(chǎng)景法等，例：ATM機(jī)取錢(qián)-場(chǎng)景法(不全) 場(chǎng)景 密碼 帳號(hào) 輸入金額 賬面金額 ATM現(xiàn)金 預(yù)想結(jié)果 場(chǎng)景1：成功提款 1 1 1 1 1 提款 場(chǎng)景2：ATM內(nèi)無(wú)現(xiàn)金 1 1 1 1 0 不可提款 場(chǎng)景3：ATM內(nèi)現(xiàn)金不足 1 1 1 1 0 提示，返回開(kāi)始 場(chǎng)景4：密碼錯(cuò)誤，可再次輸入 0 1 null 1 1 警告，返回開(kāi)始 場(chǎng)景5：密碼錯(cuò)誤，不可再次輸入 0 1 null 1 1 警告，卡預(yù)保留 白盒測(cè)試技術(shù) 3.5 白盒測(cè)試檢查點(diǎn) *對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測(cè)試一次 *對(duì)所有的邏輯判定，取’真’與’假’都至少測(cè)試一次 *在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體 *測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等 步驟：1)根據(jù)分析畫(huà)出流程圖 2)計(jì)算圈復(fù)雜度 = 判定節(jié)點(diǎn)數(shù) + 1 3)寫(xiě)出獨(dú)立路徑 4)根據(jù)獨(dú)立路徑設(shè)計(jì)測(cè)試用例 第四章 缺陷管理 4.1、Bug的分類 1)嚴(yán)重程度(Severity)：系統(tǒng)崩潰、嚴(yán)重、一般、次要、建議 2)優(yōu)先級(jí)(Priority)：高(High)、中(Middle)、低(Low) 嚴(yán)重程度高，優(yōu)先級(jí)不一定高，嚴(yán)重程度低，優(yōu)先級(jí)不一定低 3)按測(cè)試種類：邏輯功能類(Fcuntion)、性能類(Performance)、界面類(UI)、易用性類(Usability)、兼容性類(Compatibility) 4)按功能模塊 5)按生命周期：新建(New)、確認(rèn)(Confirmed)、解決(Fixed)、關(guān)閉(Closed)、重新打開(kāi)(Reopen) 4.2 缺陷報(bào)告 注意點(diǎn)： 1)確保重現(xiàn)Bug 2)用最少且必要步驟描述Bug 3)簡(jiǎn)潔、準(zhǔn)確、完整 4)一個(gè)Bug一個(gè)報(bào)告 4.3 缺陷管理工具 TrackRecord、Clearquest、Bugzilla(免費(fèi))、Mantis(免費(fèi))、JIRA(免費(fèi)) Bugzilla：Terry Weissman研制，perl編寫(xiě)，后臺(tái)數(shù)據(jù)庫(kù)是MySQL，最初是用來(lái)在Netscape內(nèi)部跟蹤Bug的，可以在多種平臺(tái)運(yùn)行 第五章 常用測(cè)試工具 分類：黑盒測(cè)試工具、白盒測(cè)試工具、測(cè)試管理工具 MI公司產(chǎn)品： 1、LoadRunner：性能測(cè)試工具 2、WinRunner：功能測(cè)試工具(QTP：MI的QTP代替占有市場(chǎng)) 3、TestDirector：測(cè)試管理工具(QC：HP收購(gòu)MI公司后退出的一款TD升級(jí)產(chǎn)品) 性能學(xué)習(xí)LoadRunner，功能學(xué)些QTP，管理學(xué)習(xí)TD IBM Rational公司的產(chǎn)品： Rational Testmanager(測(cè)試管理工具) Rational ClearQuest(缺陷管理工具) Rational Robot(功能/性能工具) Rational Purify(白盒測(cè)試工具) Compuware公司產(chǎn)品 QACenter(測(cè)試管理) TrackRecord(缺陷管理) QARun(功能) QAload(性能) DevPartner(白盒測(cè)試) Telelogic公司產(chǎn)品 Telelogic Doors(需求管理)、Logiscope(白盒測(cè)試工具) 其他公司產(chǎn)品 微軟-WAS(性能測(cè)試) Radview公司-WebLoad(性能測(cè)試)，TestView Manager(測(cè)試管理) Parasoft公司-JTest(白盒測(cè)試)，C++ Test(白盒測(cè)試) 另外，很多缺陷管理工具是開(kāi)源的，如：Bugzilla、Mantis、Jira 第六章 測(cè)試管理 6.1、測(cè)試與質(zhì)量 軟件質(zhì)量：軟件符合明確敘述的功能和性能需求、文檔中明確描述的開(kāi)發(fā)標(biāo)準(zhǔn)，以及所 有專業(yè)開(kāi)發(fā)的軟件都應(yīng)具有的隱含特征的程度(需求一致、符合準(zhǔn)則、隱含特征) SQA(Software Quality Assurance)：軟件質(zhì)量保證，為確保軟件開(kāi)發(fā)過(guò)程和結(jié)果符合預(yù)期 要求而建立的一系列規(guī)程，以及一照規(guī)程和計(jì)劃采取的一系列活動(dòng)及其結(jié)果評(píng)價(jià)。 SQA需要做的工作： *建立軟件質(zhì)量保證活動(dòng)的實(shí)體 *制定軟件質(zhì)量保證計(jì)劃 *堅(jiān)持各階段的評(píng)審、審計(jì)、跟蹤 *監(jiān)控軟件產(chǎn)品的質(zhì)量 *采集軟件質(zhì)量保證活動(dòng)的數(shù)據(jù) *度量軟件質(zhì)量保證活動(dòng) SQA需要達(dá)到目標(biāo)： *通過(guò)監(jiān)控軟件開(kāi)發(fā)過(guò)程來(lái)保證產(chǎn)品質(zhì)量 *保證開(kāi)發(fā)出來(lái)的軟件和軟件開(kāi)發(fā)過(guò)程符合相應(yīng)標(biāo)準(zhǔn)與規(guī)程(ISO90000 或 CMM) *保證軟件產(chǎn)品、軟件過(guò)程中存在的不符合問(wèn)題得到處理，必要時(shí)將問(wèn)題反映給高級(jí) 管理者 *確保項(xiàng)目組指定的計(jì)劃、標(biāo)準(zhǔn)和規(guī)程適合項(xiàng)目組需要，同時(shí)滿足評(píng)審和審計(jì)需要。 SQA工作人員：QA，QC工作人員：主要是TESTER QA與QC：QA-預(yù)防問(wèn)題(Prevention)，貫穿于整個(gè)軟件生命周期中，預(yù)防錯(cuò)誤的成因，重點(diǎn)是對(duì)軟件開(kāi)發(fā)過(guò)程進(jìn)行監(jiān)督、管 理、控制 QC-發(fā)現(xiàn)問(wèn)題(Detection)，主要是測(cè)試人員，關(guān)注于最后的產(chǎn)品的質(zhì)量活動(dòng)，重點(diǎn)是對(duì)開(kāi)發(fā)出的產(chǎn)品進(jìn)行檢查 6.2、常用模型 CMM：能力成熟度模型 1)初始級(jí)(Initial)：軟件過(guò)程的特征是無(wú)序的，有時(shí)甚至是混亂的。 幾乎沒(méi)有過(guò)程定義，成功完全取決于個(gè)人的能力。 2)可重復(fù)級(jí)(Repeatable)：建立了基本的項(xiàng)目管理過(guò)程，能夠追蹤費(fèi)用、進(jìn)度和功能。有適當(dāng)?shù)谋匾倪^(guò)程規(guī)范，使得可以重現(xiàn)以前類似項(xiàng)目的成功。 3)已定義級(jí)(Defined)：用于管理和工程活動(dòng)的軟件過(guò)程己經(jīng)文檔化、標(biāo)準(zhǔn)化，并與整個(gè)組織的軟件過(guò)程相集成。所有項(xiàng)目都使用文檔化的、 組織認(rèn)可的過(guò)程來(lái)開(kāi)發(fā)和維護(hù)軟件。 4)已管理級(jí)(Managed)：軟件過(guò)程和產(chǎn)品質(zhì)量的詳細(xì)度量數(shù)據(jù)被收集，通過(guò)這些度量數(shù)據(jù)，軟件過(guò)程和產(chǎn)品能夠被定暈地理解和控制。 5)優(yōu)化級(jí)(Optimizing)：通過(guò)定量的反饋，進(jìn)行不斷的過(guò)程改進(jìn)，這些反饋來(lái)自于過(guò)程或通過(guò)測(cè)試新的想法和技術(shù)而得到。 CMM ISO ?質(zhì)量模型 質(zhì)量標(biāo)準(zhǔn) ?評(píng)估 審查 ?給你改進(jìn)建議 結(jié)果有通過(guò)和不通過(guò) KPA(Key Process Area)：除第一級(jí)外，CMM的每一級(jí)是按完全相同的結(jié)構(gòu)組成的。每一級(jí)包含了實(shí)現(xiàn)這一級(jí)目標(biāo)的若干關(guān)鍵過(guò)程域，指出了企業(yè)需要集中力量改進(jìn)的軟件過(guò)程。 CMM2:可重復(fù)階段 　　需求管理：requrement management 　　軟件項(xiàng)目計(jì)劃：software project planning 　　軟件項(xiàng)目跟蹤和監(jiān)督：software project tracking oversight 　　軟件子合同管理：software subcontract management 　　軟件質(zhì)量保證：software quality assurance 　　軟件配置管理：software configuratione management CMM3:已定義階段 　　組織過(guò)程焦點(diǎn)：organization process focus 　　組織過(guò)程定義：organization process definition 　　培訓(xùn)大綱：training program 　　集成軟件管理：intergrated software management 　　軟件產(chǎn)品工程：software product engineering 　　組間協(xié)調(diào)：intergroup coordination 　　同行評(píng)審：peer review CMM4:已管理階段 　　定量管理過(guò)程：quantitative process management 　　軟件質(zhì)量管理：software quality management CMM5:優(yōu)化階段 　　缺陷預(yù)防：defect prevention 　　技術(shù)改革管理：technology change management 過(guò)程更改管理：process change management 成熟度 初始級(jí) 可重復(fù)級(jí) 已定義級(jí) 已管理級(jí) 優(yōu)化級(jí) 風(fēng)險(xiǎn) 常見(jiàn)的質(zhì)量模型： *ISO90000族標(biāo)準(zhǔn)：國(guó)際標(biāo)準(zhǔn)(ISO/TC176)，適合所有行業(yè)，其中9000-3針對(duì)軟件開(kāi)發(fā) *CMM標(biāo)準(zhǔn)：行業(yè)標(biāo)準(zhǔn)(卡耐基-梅隆大學(xué))，針對(duì)軟件開(kāi)發(fā)行業(yè)，分5等級(jí)，推出CMMI *TICKIT標(biāo)準(zhǔn)：行業(yè)標(biāo)準(zhǔn)(英國(guó)軟件行業(yè)協(xié)會(huì))，針對(duì)軟件開(kāi)發(fā)行業(yè)，不太流行 *ISO15504標(biāo)準(zhǔn)：國(guó)際標(biāo)準(zhǔn)(試圖結(jié)合1、2與軟件工程概念)，適用所有行業(yè)，有待實(shí)踐 其他模型： TMM：軟件測(cè)試成熟度模型 *初始級(jí) *階段定義級(jí) *集成級(jí) *管理和度量級(jí) *優(yōu)化、預(yù)防缺陷和質(zhì)量控制級(jí) McCall模型：【產(chǎn)品運(yùn)行】正確性、健壯性、效率、完整性、可用性、風(fēng)險(xiǎn) 【產(chǎn)品修改】可理解性、可維護(hù)性、靈活性、可測(cè)試性 【產(chǎn)品轉(zhuǎn)移】可移植性、可再用性、互運(yùn)行性 6.3、軟件的生命周期 軟件：可行性研究、需求分析→設(shè)計(jì)、編碼、測(cè)試→軟件發(fā)布維護(hù)→淘汰 軟件開(kāi)發(fā)：需求分析→概要設(shè)計(jì)→詳細(xì)設(shè)計(jì)→編碼→維護(hù) 軟件測(cè)試：測(cè)試計(jì)劃→測(cè)試設(shè)計(jì) 測(cè)試執(zhí)行→測(cè)試評(píng)估 軟件生命周期模型： 1、Waterfall Model(瀑布模型)：計(jì)劃-需求-設(shè)計(jì)-編碼-測(cè)試-維護(hù) 開(kāi)發(fā)的各個(gè)階段比較清晰 依賴早起需求調(diào)查，不適應(yīng)需求變化 強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查 單一流程，不可逆 適合需求穩(wěn)定的產(chǎn)品開(kāi)發(fā) 風(fēng)險(xiǎn)往往遲至后期才發(fā)現(xiàn)，失去及早糾正機(jī)會(huì) 2、Spiral Model(螺旋模型)：重復(fù)執(zhí)行多個(gè)’瀑布模型’ 適合需求經(jīng)常變化的軟件項(xiàng)目，但開(kāi)發(fā)過(guò)程復(fù)雜，控制不好，容易混亂 3、V模型 用戶需求 驗(yàn)收測(cè)試 規(guī)格定義 系統(tǒng)測(cè)試 概要設(shè)計(jì) 集成測(cè)試 詳細(xì)設(shè)計(jì) 單元測(cè)試 編碼 詳細(xì)表示了測(cè)試的各個(gè)階段及參考依據(jù)，但沒(méi)有說(shuō)明在項(xiàng)目前期測(cè)試需要做哪些工作，且流程也是單項(xiàng)，不可逆 4、W模型 需求分析 需求測(cè)試 系統(tǒng)安裝 驗(yàn)收測(cè)試 概要設(shè)計(jì) 概要設(shè)計(jì) 系統(tǒng)構(gòu)建 系統(tǒng)測(cè)試 測(cè)試 詳細(xì)設(shè)計(jì) 詳細(xì)設(shè)計(jì) 模塊集成 集成測(cè)試 測(cè)試 編碼實(shí)現(xiàn) 單元測(cè)試 強(qiáng)調(diào)測(cè)試伴隨整個(gè)軟件開(kāi)發(fā)生命周期，對(duì)象也不僅是程序，有利于盡早發(fā)現(xiàn)問(wèn)題，但是需求設(shè)計(jì)編碼等活動(dòng)也被視為串行，測(cè)試和開(kāi)發(fā)也保持一種線性的前后關(guān)系。 W模型、H模型、X模型 通?？梢栽赪模型的框架下，運(yùn)用H模型的思想進(jìn)行獨(dú)立的測(cè)試，當(dāng)有變更發(fā)生時(shí)，按X模型和前置模型的思想進(jìn)行處理。(百度另幾種模型) 6.4 軟件測(cè)試計(jì)劃 撰寫(xiě)測(cè)試計(jì)劃時(shí)，應(yīng)注意一下四點(diǎn)： *增強(qiáng)測(cè)試計(jì)劃實(shí)用性注意體現(xiàn)項(xiàng)目的測(cè)試特點(diǎn) *堅(jiān)持”5W1H”規(guī)則，明確內(nèi)容與過(guò)程 5W1H：”WHAT”,”WHY”,”WHEN”,”WHERE”,”WHO”,”HOW” what：明確測(cè)試范圍和內(nèi)容 why：測(cè)試目的 when：確定測(cè)試開(kāi)始和結(jié)束日期 where：給出測(cè)試文檔和軟件的存放位置 who：測(cè)試人員的分配 how：指出測(cè)試的方法和工具 *采用評(píng)審和更新機(jī)制，保證測(cè)試計(jì)劃滿足實(shí)際需求 *分別創(chuàng)建測(cè)試計(jì)劃與測(cè)試策略 其他 RUP： rational unified process 統(tǒng)一軟件開(kāi)發(fā)過(guò)程 它定義了在整個(gè)軟件開(kāi)發(fā)過(guò)程中：在什么時(shí)候，應(yīng)該有誰(shuí)，進(jìn)行什么樣的開(kāi)發(fā)活動(dòng)，產(chǎn)生什么樣的結(jié)果，來(lái)確保按時(shí)提交筒質(zhì)量的產(chǎn)品。 RUP總體結(jié)構(gòu) 每個(gè)角色完成指定的活動(dòng) 每個(gè)活動(dòng)產(chǎn)出合格的產(chǎn)品 每個(gè)產(chǎn)品擁有相關(guān)的指南，模板等 RUP主要特點(diǎn) 迭代化軟件開(kāi)發(fā) 以架構(gòu)為核心的軟件開(kāi)發(fā) 用例驅(qū)動(dòng)的軟件開(kāi)發(fā) 風(fēng)險(xiǎn)驅(qū)動(dòng)的軟件開(kāi)發(fā) 最佳經(jīng)驗(yàn) 迭代化開(kāi)發(fā) 需求管理 基于構(gòu)件的軟件架構(gòu) 可視化建模 持續(xù)的質(zhì)量驗(yàn)證 配置管理 RUP適合任何項(xiàng)目 RUP在實(shí)施之前必須進(jìn)行裁剪 RUP是個(gè)豐富的知識(shí)庫(kù)，需要你不斷的去查閱，選擇 實(shí)踐RUP是個(gè)持續(xù)的過(guò)程 國(guó)際化與本地化 Globalization testing 注意的是它與翻譯是沒(méi)什么太大關(guān)系的。 國(guó)際化測(cè)試關(guān)注產(chǎn)品是否達(dá)到了不同的時(shí)區(qū)、時(shí)間日期、貨幣格式和不同的文化習(xí) 慣等，當(dāng)然還有政治規(guī)定方面的要求。 Localization testing 對(duì)一個(gè)軟件進(jìn)行本地化測(cè)試就需要關(guān)注文本顯示的空間，因?yàn)椴煌Z(yǔ)言的 長(zhǎng)度不一樣，所以在設(shè)計(jì)界面的時(shí)候就要小心了！ 驗(yàn)證軟件被翻譯完畢后，是否有什么錯(cuò)誤，是否能夠正常工作。