01、測試基礎-學習目標、課程內容、引入
掌握什么是軟件測試;
掌握測試的目的;
掌握軟件生命周期的各個階段以及相互關系;
初步了解軟件生命周期各階段的具體工作內容;
大致了解軟件研發團隊的組織形式和研發流程。
軟件測試的定義和目的
軟件生命周期
軟件研發組織和流程
軟件中產生缺陷的原因
問題討論
網上購物/瀏覽網頁是不是軟件測試?? 不是? ? 軟件使用
用手機/電腦打游戲是不是軟件測試？? 不是? ? 軟件使用
使用Office辦公軟件是不是軟件測試?? 不是? ? 軟件使用
什么是軟件測試？
1.特定的目的 (購物的增刪改查 軟件運行時的性能) 2.測試是有一定的方法
3.提交缺陷 跟蹤缺陷
軟件測試演示
軟件測試并不神秘,快速入門并不難
功能測試演示
性能測試演示
02、測試基礎-軟件測試的定義
梅爾斯? 《軟件測試的藝術》
G.J.Myers認為(1979)：
1 程序測試是為了 發現錯誤 而執行程序的過程;
2 好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案;
3 成功的測試是發現了至今為止尚未發現的錯誤的測試。
25年之后, G.J.Myers在《軟件測試的藝術第二版》中;
所謂軟件測試,就是一個過程或一系列過程,用來確認 計算機代碼
完成了其應該完成的 功能 ,不執行其不該有的操作。
什么是軟件測試
目前沒有公認非常完整的定義形式。
1983,IEEE提出的軟件工程標準術語,軟件測試定義如下:
"使用人工和自動手段來運行或測試某個系統的 過程 ",在其目的在于檢驗它是
否滿足規定的需要或是弄清? 預期結果 與 實際結果 之間的差別"。
沒有必要一定要背一個概念出來,搞清軟件測試的含義即可:
軟件測試是一個過程,包含若干活動,運行軟件進行測試只是活動之一;
進行軟件測試可以人工方式也可以借助于工具;
進行軟件測試可以 運行軟件 也可以 不運行軟件;
動態 靜態
軟件測試的目的不僅僅是為了發現錯誤。
03、測試基礎-軟件測試的目的
人們對軟件測試目的的認識也經歷了一個過程。
證明 ? 檢測 預防
表明軟件能夠工作 發現錯誤? ? ? ? ? 管理質量
20世紀60年代 20世紀70年代中期? ? ? 20世紀90年代
軟件測試目的之證明
20世紀60年代
測試是證明軟件沒有問題。
現在
獲取系統在可接受風險范圍內可用的信心;
嘗試在非正常情況和條件下的功能和特性;
保證一個工作產品是完整的并且可用或者被集成。
軟件測試目的之檢測
20世紀70年代中期
測試是為了發現錯誤。
現在
發現缺陷、錯誤和系統不足;
定義系統的能力和局限性;
提供組件、工作產品和系統發質量信息。
軟件工程: 1.開發技術
2.開發管理
軟件測試目的之預防
預防下一版本可能出現的問題
預防用戶使用軟件時可能出現的問題
提前發現開發過程中的問題和風險
大大較低開發的風險
提供可以用以分析的測試結果數據
了解哪些缺陷的原因和以前的數據進行分析
針對薄弱的環境進行加強(未雨綢繆)
軟件測試觀念的轉變
傳統測試 現在測試
在開發的后期介入 已經擴展到了整個軟件生命周期
基于代碼運行的測試 已經擴展到了靜態的范疇
已發現錯誤為目的 已經擴展到了錯誤預防的范疇
希望通過測試收集和分析一些數據起到預防缺陷的作用
04、測試基礎-軟件測試常見的誤區
調試和測試是一樣的;
調試是定位錯誤修改程序? ? 測試是找錯誤
調試是隨機性的(程序員)? ? 測試是目的性的
測試組應當為保證質量負責;
質量是做出來的,不是測出來的
過分依賴Beta測試;
(Beta測試是一種驗收測試。所謂驗收測試是軟件產品完成了功能測試和系統測試之后，在產品發布之前所進行的軟件測試活動，它是技術測試的最后一個階段，通過了驗收測試，產品就會進入發布階段。驗收測試一般根據產品規格說明書嚴格檢查產品，逐行逐字地對照說明書上對軟件產品所做出的各方面要求， 確保所開發的軟件產品符合用戶的各項要求。 通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——驗收測試即可開始。驗收測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。)
把測試作為新員工的一個過渡工作;
把不合格的開發人員安排做測試;
關注于測試的執行而忽略測試的設計;
測試自動化是萬能的;
測試是可以窮盡的;
測試是為了證明軟件的正確性;
測試是枯燥乏味,缺乏創造力的工作;
非常要求創造力的工作
軟件測試發主要工作
軟件測試工程師一般會承擔以下一些具體工作;
檢視代碼、評審開發文檔
進行測試設計、寫作測試文檔(測試計劃、測試方案、測試用例等)
目的性,條理性
執行測試,發現軟件缺陷,提交缺陷報告,并確認缺陷最終得到了修正
出現bug會造成什么后果
通過測試度量軟件的質量
05、軟件生命周期-計劃
軟件測試的定義和目的
軟件生命周期
軟件生命周期的各個階段
計劃----需求分析----設計----編碼-----測試-----運行----評價--計劃
軟件研發組織和流程
軟件中產生缺陷的原因
計劃
工作內容 計算器例子
確定軟件開發總目標 ? 研發一個計算器
給出軟件的功能、性能、可靠性以及接口等方面的設想; 支持加、減、乘、除,所有運算都需在一定時間之內完成;
研究完成該項目的可行性,探討問題 該項目目前不存在任何技術障礙;
解決方案; 需要在3個月之內完成所有開發和測試工作,并推向市場;
對可供開發使用的資源、成本、可取得
的效益和開發進度作出估計; 具體計劃參見項目一級計劃(比如測試計劃 質量保證計劃 配置管理計劃)。
制定完成開發任務的實施計劃
06、軟件生命周期-需求分析
需求分析(重要 復雜)
客戶(沒有IT背景) 說服客戶
工作內容：
對開發的軟件進行詳細的定義,由 需求分析人員 和 用戶共同 討論決定,哪些需求 可以滿足 的,并且給予 計算器例子
確切的描述 ,寫出軟件需求說明書SRS(Software Requirement Specification) 功能需求:
十進制加、減、乘、除
八進制加、減、乘、除
軟件研發的類型不同,需求的來源也不同,需求分析中的"用戶"針對的具體對象也不同 二進制加、減、乘、除
十六進制加、減、乘、除
針對 產品 的軟件研發
需求來源:市場調研(來源市場 女性 男性 兒童 ...) 性能需求:
用戶:市場調研人員 32位十進制加法需在2秒內完成
特點:自己想研發什么,自己就來研發 16位十六進制乘法需在10秒內完成
針對 項目 的軟件研發
需求來源:客戶要求
用戶:實際的客戶
特點:別人想研發什么,我們幫著研發
-----------------------------------------------------------------------------------------
設計
工作內容
設計是軟件工程的技術核心,這個階段需要完成設計說明書
概要設計(HLD),在設計階段吧各項需求轉換成相應的體系結構,每一部分是功能明確的模塊;
詳細設計(LLD),對每個模塊要完成的工作進行具體的描述。
計算器例子
概要設計
整個軟件分成六個模塊:界面模塊、主控模塊、加法模塊
減法模塊、乘法模塊、除法模塊,主控模塊調用后四個模塊。
加法模塊包含五個函數:加法主函數、十進制加法函數、八進制加法函數、二進制加法函數、
十六進制加法函數、主函數調用后四個函數。
詳細設計
加法主函數的流程圖(或者偽代碼)
08、軟件生命周期-編碼、測試、運行和維護
編碼
工作內容 計算器例子
把軟件設計轉換成計算機可以 用C語言實現詳細設計說明書中描述的所以函數。
接受的程序,即寫成以某個程序
設計語言表示的源程序清單,使用RDBMS工具建立數據庫。
測試
工作內容 計算機例子
測試是檢驗軟件是否符合客戶需求,達到質量要求,一般由獨立的小組執行,測試工作分為: 單元測試
單元測試 參照LLD(詳設)
對每一個函數進行測試
集成測試 集成測試
參照HLD(概設)
對函數與函數的集成、模塊與模塊的集成進行測試
系統測試 系統測試
參照SRS
對每一個功能需求、性能需求等進行測試
運行和維護
工作內容
這個階段將軟件交付用戶投入正式使用,可能有多種原因需要對它進行修改,如軟件錯誤 計算機例子
、系統軟件升級、增強軟件功能、提高性能等。 計算器提供給用戶使用,用戶在使用過程中如發現問題可通過技術支持人員反映,
問題解決后為用戶進行軟件升級....
09、軟件研發組織和流程-軟件研發組織
軟件測試的定義和目的
軟件生命周期
軟件研發組織和流程
軟件中產生缺陷的原因
軟件研發相關要素
人員 只有合適的人員借助合適的
過程 ? ? ? ? 工具經過合適的過程才能研發出高質量的軟件
工具
軟件項目組人員組成
項目組一般由 項目經理 領導并負責制定 項目計劃 ,分配任務。
項目組一般有下列人員參與:
分析人員
設計人員
開發人員
測試人員
配置管理人員
SQA:(軟件質量保證 軟件質量保證（SQA-Software Quality Assurance）是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。)
常見項目組架構
項目經理 -----? SQA(監控整個軟件研發的過程)
開發經理 測試經理 配置經理
軟件開發組 軟件測試組 配置管理組
分析人員 測試人員 配置管理員 CMO
設計人員
開發人員
10、軟件研發組織和流程-瀑布模型
基本軟件研發流程
常見的軟件研發流程:
瀑布模型(00:40)增加了開發的風險 用戶只能到最后才能看到 開發后期的測試階段才能發現 帶來了嚴重的后果
應用的最為廣泛的一種模型,也是最容易理解和掌握的模型,
然而它的缺陷也是顯而易見的。
螺旋模型
綜合了基本的瀑布式模型和演化/漸增原型方法。
RUP流程
所有工作流在各個階段都有體現。
IPD流程
從整個產品角度出發,不僅僅針對研發。
11、軟件研發組織和流程-螺旋模型
螺旋模型(00:05) 非常看重風險分析的
確定目標、替代方案和限制
評價替代方案和標識與解決風險
優點:設計比較靈活? 使客戶每個階段都可以客戶去參與
缺點:周期長
12、軟件研發組織和流程-RUP
RUP流程是IBM公司提出來的
工作流
過程
業務建模
需求
分析和設計
實現
測試
分布
支持
配置與變更管理
項目管理
環境
階段
初始化 細化 構造 發布
初始 細化*1 細化*2 構造*1........
13、軟件研發組織和流程-IPD
IPD流程? 思想來源一家公司PRTM? ? IBM公司使用
階段 概念 計劃 開發 驗證 發布 生命周期
IPMT
PDT
財務
系統工程
研發
硬件開發
軟件開發
結構開發
工業設計
測試
資料開發
技術支持
制造
采購
市場
銷售
14、軟件中產生缺陷的原因
軟件缺陷和Bug
軟件缺陷:既指 靜態 存在于軟件工作產品(文檔、代碼)中的錯誤,
也指軟件運行時由于這些錯誤被激發引起的和軟件產品預期屬性的偏離現象。
Bug:代碼中的缺陷。有時也被泛指因軟件產品顳部的缺陷引起的軟件產品最終運行時和
預期屬性的偏離。
軟件錯誤、軟件缺陷、Bug在實工作中可以認為一樣。
常見的其他引入缺陷的原因
軟件復雜度越來越高
編程中產生錯誤
需求不斷變更
項目進度的壓力
不重視開發文檔
...
缺陷類型
所有缺陷可以歸結為三類:
遺漏；規定的或預期的需求未體現在產品中(可能未將規格說明全面實現,也可能需求分析階段就遺漏了需求)
錯誤: 未將規格說明正確實現(可能設計錯誤、也可能編碼錯誤)
額外的實現:規格說明并未規定的需求被納入產品,得到實現
缺陷的放大模型
需求階段缺陷----概要設計階段缺陷----詳細設計階段缺陷----編碼設計階段缺陷
常見的其他引入缺陷的原因
軟件復雜度越來越高
編程中產生錯誤
需求不斷變更
項目進度的壓力
不重視開發文檔
...
