敏捷軟件測試-課件PPT

1、敏捷測試（Agile Testing） 2021/8/262敏捷宣言 個體和交互勝過流程和工具 可用的軟件勝過完備的文檔 客戶協(xié)作勝過合同談判 響應變化勝過遵循計劃敏捷方法 Scrum Crystal 極限編程（XP） 動態(tài)系統(tǒng)開發(fā)方法（DSDM） 特征驅動開發(fā)（FDD） 測試驅動開發(fā)（TDD）2021/8/263XP(極限編程)2021/8/2642021/8/265FDD (特征驅動開發(fā))2021/8/266Scrum特點 敏捷的流程，可用于管控研發(fā)工作 現有設計流程的總結 以團隊為基礎，是一種在需求迅速變化情況下迭代的、增量的開發(fā)系統(tǒng)和產品的方法 控制由利益和需求沖突導致混亂的流程 改善

2、交流、協(xié)調合作的最優(yōu)方式 檢測產品開發(fā)和生產過程中障礙并將其去除的方式 最大化生產率的一種方法 適用于單一的項目到整個組織。Scrum可以控制并組織多件具有相關性的產品開發(fā)以及擁有超過千名開發(fā)者和執(zhí)行者的項目實施過程。 讓每個參與者都對自己所做的工作以及自己做出的貢獻感到驕傲，并讓他們發(fā)揮到最佳水平。 2021/8/267Sprint（迭代）Scrum的項目過程由一系列的Sprint組成Sprint的長度一般控制在24周通過固定的周期保持良好的節(jié)奏產品的設計、開發(fā)、測試都在Sprint期間完成Sprint結束時交付可以工作的軟件在Sprint過程中不允許發(fā)生變更2021/8/268DSDM(動

3、態(tài)系統(tǒng)開發(fā)方法) 九大原則 用戶必須持續(xù)參與 必須授予DSDM團隊制定決策的權利 注重產品的經常交付 滿足業(yè)務用戶用途是接受交付品的主要依據 迭代和增量式開發(fā)對得到正確的業(yè)務解決方案是必不可少的 開發(fā)過程的所有變化可逆 在高層次上制定需求的基線 測試自始至終貫穿于開發(fā)周期之中 所有項目涉眾間的通力合作是不可獲缺的2021/8/269適合DSDM的應用 交互式、功能通過用戶界面體現 有清晰的用戶群 沒有復雜計算 如果是大型應用，可以分解成小的功能部件 有時間限制 需求不清楚或不確定2021/8/2610TDD(測試驅動開發(fā)) TDD得原理是在開發(fā)功能代碼之前，先編寫單元測試用例代碼，測試代碼確定

4、需要編寫什么產品代碼。 TDD得基本思路就是通過測試來推動整個開發(fā)得進行，但測試驅動開發(fā)并不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。 優(yōu)點：在任意一個開發(fā)節(jié)點都可以拿出一個可以使用，含少量bug并具一定功能的產品。 缺點：增加代碼量。測試代碼是系統(tǒng)代碼的兩倍或更多。2021/8/2611TDD的名言名句 以動手實踐為榮，以只看不練為恥。 以打印日志為榮，以單步跟蹤為恥。 以空格縮進為榮，以制表縮進為恥。 以單元測試為榮，以人工測試為恥。 以模塊復用為榮，以復制粘貼為恥。 以多態(tài)應用為榮，以分支判斷為恥。 以pythonic為榮，以冗余拖沓為恥。 以總結分享為榮，以跪求其解

5、為恥2021/8/2612敏捷測試敏捷測試是指在采用敏捷技術的項目中開展的測試以任務為導向，而不以過程或是角色為導向通過溝通和反饋保證測試能夠建立合適的質量標準 盡可能減少測試周期的時間需求2021/8/2613敏捷團隊與敏捷測試人員 客戶團隊：由業(yè)務專家、產品經理、業(yè)務人員的產品負責人、測試人員等組成。 開發(fā)團隊：有程序員、測試人員、架構師、系統(tǒng)管理員、數據庫管理員、技術文檔編寫人員、安全專家等組成； 測試人員既屬于客戶團隊又屬于開發(fā)團隊，既要了解客戶的觀點又要了解技術實現的復雜性。2021/8/2614敏捷測試人員法則 提供持續(xù)反饋 為客戶創(chuàng)造價值 進行面對面的溝通 勇氣 簡單化 持續(xù)改進

6、 響應變化 自我組織 關注人 享受樂趣2021/8/2615傳統(tǒng)測試 vs. 敏捷測試2021/8/26162021/8/2617傳統(tǒng)到敏捷的挑戰(zhàn) 質量哲學 整體團隊負責質量 技能和適應能力 合適的節(jié)奏 客戶關系 組織規(guī)模 溝通挑戰(zhàn) 組織內的文化沖突 提前計劃 授權團隊2021/8/2618敏捷團隊結構 獨立的質量保證團隊 把測試人員整合到敏捷項目 敏捷項目團隊2021/8/26192021/8/2620敏捷測試的四個象限2021/8/26212021/8/2622敏捷測試的目的 管理技術債務（Ward Cunningham，1992） 象限擔任了保持技術債務在一個可管理的水平的角色 上下文環(huán)

7、境中的測試 任何實踐的價值依賴于其上下文環(huán)境 存在上下文環(huán)境中的優(yōu)秀的實踐，但是沒有最好的實踐 人們共同工作是任何項目的上下文環(huán)境的最重要部分 項目隨著時間以通常不能預測的方式發(fā)展 產品是一個解決方案，如果沒有解決問題，那么產品是不能運轉的 出色的軟件測試是一個有挑戰(zhàn)性的智力過程 只有通過判斷和技巧，在整個項目中合作實踐，才可以在正確的時間做正確的事情，有效地測試我們的產品2021/8/2623使用TDD的原因 效率更高 讓測試人員的工作更容易 設計時謹記測試 即時反饋 工具箱 源代碼控制 IDE（集成開發(fā)環(huán)境） 構建自動化工具（持續(xù)集成是敏捷團隊的核心實踐） 單元測試工具（Java的Juni

8、t）2021/8/2624自動化測試 功能測試結構（Ruby with Watir） Web服務(IRB) 嵌入式測試(FXRuby)2021/8/2625自動化測試原因 手動測試需要太長的時間 手動過程容易出錯 自動化讓人們有時間做更有價值的工作 自動化的回歸測試提供了安全網 自動化測試能較早且頻繁地提供反饋 驅動編碼的測試和實例可以做更多的事情 測試提供文檔 自動化的投資回報率高2021/8/2626妨礙自動化的因素 程序員的態(tài)度 “痛苦的積累” 初期投入 總在變化的代碼 遺留系統(tǒng) 恐懼 舊的習慣2021/8/2627哪些測試可以自動化 持續(xù)集成、構建和部署 單元與組件測試 API或WEB

9、 Services測試 GUI底層的測試 測試GUI 負載測試 比較 重復的任務 創(chuàng)建數據2021/8/2628GUI測試驗收測試（API層面）單元測試/組件測試2021/8/26292021/8/2630測試人員在發(fā)布或主題計劃階段的工作 制定發(fā)布計劃的目的 評估工作量如何評估故事測試人員在其中的角色一個示例（產品負責人與測試人員的溝通） 設定優(yōu)先級為何要設定優(yōu)先級需要考慮的測試情況2021/8/2631 測試范圍最后期限和時間表關注產品價值系統(tǒng)范圍的影響第三方的介入 制定測試計劃從何處開始為何要制定測試計劃測試的種類測試基礎設施測試環(huán)境測試數據測試結果2021/8/2632 可選的測試計劃形式輕量級測試計劃測試矩陣電子表格白板自動化測試列表 注意可見性測試任務追蹤測試結果交流