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