hw軟件測試（周）1.ppt

軟件測試技術基礎 軟件測試 教材 軟件測試教程 機械工業(yè)出版社 參考書1 軟件測試技術基礎 陳汶濱主編清華大學出版社2 軟件測試 曹薇編著清華大學出版社 考試成績 平時成績期末考試 在我國 隨著軟件產(chǎn)業(yè)的高速發(fā)展 軟件測試的重要性也已逐漸被軟件企業(yè)關注 近91 的國內(nèi)軟件企業(yè)已有組建測試隊伍的意識 但現(xiàn)階段我國軟件測試的發(fā)展存在嚴重問題 人才緊缺 在大多數(shù)軟件企業(yè)中 測試人員的數(shù)量不足開發(fā)人員數(shù)量的五分之一 平均比在1 8左右 遠遠落后于國外先進水平 智聯(lián)招聘提供的具體調(diào)查數(shù)據(jù)顯示 國內(nèi)軟件測試人才缺口挺進30萬大關 僅北京 上海兩地缺口量就達到20萬 造成這種稀缺局面的主要原因是我國相關人才的培養(yǎng)尚未形成規(guī)模 高等教育體系尚沒有開設軟件測試相關專業(yè) 測試人才數(shù)量無法滿足企業(yè)的實際需求 像美國這樣軟件產(chǎn)業(yè)發(fā)達的國家 軟件企業(yè)將40 的工作量花在軟件測試上 測試費用占項目總費用的30 50 內(nèi)容安排 第一章軟件工程與軟件測試第二章軟件測試概論第三章軟件測試基礎知識第四章軟件的測試過程第五章黑盒測試第六章白盒測試第七章自動化測試及其工具第八章性能測試第九章面向?qū)ο蟮臏y試第十章軟件測試管理 Unit1軟件工程與軟件測試 學習要求了解當前流行的軟件過程模型掌握軟件缺陷 軟件故障 軟件質(zhì)量的概念掌握軟件測試與軟件開發(fā)過程的關系 1 1軟件 軟件 程序 數(shù)據(jù) 庫 文檔 1 1 1軟件的發(fā)展史 軟件自問世以來 其發(fā)展經(jīng)歷了以下四個階段 第一階段 50年代初期至60年代中期 稱為程序設計階段 軟件產(chǎn)品為專用軟件 開發(fā)者即使用者 規(guī)模較小 軟件只有程序 沒有文檔 第二階段 60年代中期至70年代末期 稱為程序系統(tǒng)階段 軟件技術和管理水平相對落后 導致 軟件危機 出現(xiàn) 1 1 1軟件的發(fā)展史 第三階段 70年代中期至80年代末期 稱為軟件工程階段 軟件開發(fā)有了可以遵循的軟件工程化的設計準則 方法和標準 通過提供規(guī)范化的分析設計方法和工具軟件 來避免或者減少軟件錯誤的發(fā)生 第四階段 從20世紀80年代中期至今 軟件體系結(jié)構(gòu)向更加靈活的多層分布式結(jié)構(gòu)演變 1 1 2軟件的生命周期 軟件生命周期指軟件從概念形成開始 經(jīng)過開發(fā) 使用和維護 直到最終被廢棄的整個過程 1 2軟件過程 軟件過程作為軟件工程的核心問題 是指為了獲得高質(zhì)量軟件所需要完成的一系列任務的框架 它規(guī)定了完成各項任務的工作步驟 RUP RationalUnifiedProcess 譯為Rational統(tǒng)一過程 是IBM公司的一套軟件開發(fā)過程產(chǎn)品 學習之前 讓我們來看一下福特的故事 1 2 1RUP 1908年前技術熟練的工人850 1908年后T型流水線360 開發(fā)一個具有一定規(guī)模和復雜性的軟件系統(tǒng) 開發(fā)一個簡單的程序 蓋大廈 蓋狗窩 RUP定義了進行軟件開發(fā)的步驟 即定義了軟件開發(fā)過程中什么時候做 做什么 怎么做 誰來做的問題 以保證軟件項目有序的 可控的 高質(zhì)量的完成 RUP六大經(jīng)驗 兩種常見的軟件開發(fā)模型 經(jīng)驗一 迭代開發(fā) 瀑布模型 迭代模型 需求分析 設計 編碼 集成 系統(tǒng)測試 瀑布模型 推遲關鍵風險決定的確認 不利于時間進度和工作完成情況的預估 推遲和集中的集成與測試 排斥早期的部署 經(jīng)常導致非計劃的項目延伸 瀑布模型 瀑布模型的不足 迭代模型 迭代模型不是在項目結(jié)束時一次性提交軟件 而是分塊逐次開發(fā)的提交 分析人員只要找出滿足項目需求的某一子集 比如說某個功能 或者是UML中所稱的UsesCase 就立即進行迭代開發(fā) 而不是將該項目的所有需求都搞清楚后才開始開發(fā) 所謂迭代 就是指每一個迭代過程都包含了軟件生命周期的所有階段 即 分析 設計 實現(xiàn)和測試階段 所有的迭代 子集 加起來就是項目的所有需求 全集 迭代模型 允許變更需求 及早降低風險 有助于組織學習和提高 提高復用性 鼓舞團隊士氣 迭代模型的優(yōu)點 迭代模型 RUP把需求定義為 系統(tǒng)必須符合的條件或具備的功能 軟件開發(fā)的任務 保證開發(fā)出來的軟件符合用戶的需要 經(jīng)驗二 管理需求 事實 需求分析很難 結(jié)論 要對需求進行管理 功能性需求 性能需求 課程注冊管理系統(tǒng)的用例圖 從傳統(tǒng)制造業(yè)得到什么啟發(fā) 經(jīng)驗三 基于組件的架構(gòu) 何為組件 組件是包含一定的功能 具有外界交互接口的軟件包 基于組件的開發(fā)的優(yōu)點 促進軟件的重用允許高效的并行開發(fā)人員分配更加靈活 經(jīng)驗四 可視化建模 為什么要可視化建模 幫助管理復雜性捕獲結(jié)構(gòu)和行為顯示系統(tǒng)元素如何組合在一起適當?shù)碾[藏或者展示細節(jié)保持設計和實現(xiàn)的一致性促進溝通為所有軟件從業(yè)者提供一種語言 經(jīng)驗五 持續(xù)的質(zhì)量驗證 在RUP中軟件質(zhì)量評估不再是事后進行或單獨小組進行的分離活動 而是內(nèi)建于過程中的所有活動 這樣可以及早發(fā)現(xiàn)軟件中的缺陷 經(jīng)驗六 管理變更 迭代式開發(fā)中如果沒有嚴格的控制和協(xié)調(diào) 整個軟件開發(fā)過程很快就陷入混亂之中 1 2 2敏捷過程 極限編程作為敏捷方法中最重要最著名的方法之一 1998年由Smalltalk社群大師級人物KentBeck首先倡導 敏捷過程定義了一系列核心原則和輔助原則 為軟件開發(fā)項目建模實踐奠定基石 它的基礎和價值觀是交流 樸素 反饋和勇氣 即 任何一個軟件項目都可以從四個方面入手進行改善 加強交流 從簡單做起 尋求反饋 勇于實事求是 XP是一種近螺旋式的開發(fā)方法 它將復雜的開發(fā)過程分解為一個個相對比較簡單的小周期 通過積極的交流 反饋以及其它一系列的方法 開發(fā)人員和客戶可以非常清楚開發(fā)進度 變化 待解決的問題和潛在的困難等 并根據(jù)實際情況及時地調(diào)整開發(fā)過程 1 3軟件缺陷 1 3 1軟件缺陷的典型例子 1998年開始 全世界花費上百億美元 4195835 3145727 3145727 4195835 01994年 花費4 5億美元 軟件未達到產(chǎn)品說明書中已經(jīng)標明的功能 軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤 軟件未達到產(chǎn)品說明書中雖未指出但應當達到的目標 軟件功能超出了產(chǎn)品說明書中指出的范圍 軟件測試人員認為軟件難以理解 不易使用 或者最終用戶認為該軟件使用效果不良 軟件缺陷的主要類型 1 3 2軟件缺陷產(chǎn)生的原因 缺乏或者沒有進行溝通軟件復雜度編程錯誤不斷變更的需求 時間的壓力開發(fā)人員的自大技術文檔本身的缺陷 導致軟件缺陷的最大原因是軟件產(chǎn)品說明書 軟件缺陷的第二大來源是設計方案 這是實施軟件計劃的關鍵環(huán)節(jié) 編程排在第三位 軟件缺陷的修復費用 結(jié)論 用戶一般是非計算機專業(yè)人員 軟件開發(fā)人員和用戶的溝通存在較大困難 對要開發(fā)的產(chǎn)品功能理解不一致 由于軟件產(chǎn)品還沒有設計 開發(fā) 完全靠想象去描述系統(tǒng)的實現(xiàn)結(jié)果 所以有些特性還不夠清晰 需求變化的不一致性 用戶的需求總是在不斷變化的 這些變化如果沒有在產(chǎn)品規(guī)格說明書中得到正確的描述 容易引起前后文 上下文的矛盾 對規(guī)格說明書不夠重視 在規(guī)格說明書的設計和寫作上投入的人力 時間不足 沒有在整個開發(fā)隊伍中進行充分溝通 有時只有設計師或項目經(jīng)理得到比較多的信息 為什么產(chǎn)品規(guī)格說明書是軟件缺陷存在最多的地方 1 3 3軟件缺陷的級別 致命的 造成系統(tǒng)或應用程序崩潰 或數(shù)據(jù)丟失 主要功能完全喪失嚴重的 嚴重錯誤 指功能或特性沒有實現(xiàn) 主要功能喪失 一般的 不太嚴重的錯誤 次要功能喪失微小的 一些小問題 對功能幾乎沒有影響 1 4軟件質(zhì)量 1 從用戶角度出發(fā) 質(zhì)量是對需求的滿足 軟件需求是度量軟件質(zhì)量的基礎 2 從軟件產(chǎn)品角度出發(fā) 質(zhì)量是軟件的內(nèi)在特征 3 從軟件開發(fā)過程出發(fā) 質(zhì)量是對過程規(guī)范的符合 1 4 1軟件質(zhì)量的概念 1 4 2質(zhì)量模型 軟件質(zhì)量框架是 質(zhì)量特征 質(zhì)量子特征 度量因子 的3層結(jié)構(gòu)模型 其中第1層稱為質(zhì)量特性 第2層稱為質(zhì)量子特性 第3層稱為度量 1 4 3質(zhì)量與測試 軟件質(zhì)量保證 SoftwareQualityAssurance SQA介入于整個軟件開發(fā)過程 監(jiān)督和改進流程 確認達成的標準和過程被正確的遵循 保證問