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

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