敏捷軟件測試-課件PPT

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

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

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

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

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

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

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

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

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