敏捷測試之-迭代開始

1、2021/3/10授課：授課：XXX1 1 第十七章第十七章 迭代開始迭代開始 Owen 2021/3/10授課：授課：XXX2 為什么要開始迭代 迭代模型迭代模型是RUP（Rational Unified Process，統(tǒng)一軟件開發(fā)過程)推薦的周期模型。 迭代是循環(huán)，往復 反饋的一個過程。 理解：我們大家可以這樣想：我們開發(fā)一個產(chǎn)品，如果不太復雜，會采用瀑布模型瀑布模型，這樣幾個月過去 了，直到最后一天發(fā)布時，大家可以見到一個完整的產(chǎn)品。這種模型周期相對短些，成本相對低 些。但這樣的方式有明顯的缺點，假如我們對用戶的需求判斷的不是很準確時，你工作了幾個月 甚至是幾年，當你把產(chǎn)品拿給客戶看時

2、，客戶往往會大吃一驚，這就是我要的東西嗎？ 如果采用迭代模型迭代模型：假如這個產(chǎn)品要求6個月交貨，我在第一個月就會拿出一個產(chǎn)品來，當 然，這個產(chǎn)品會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩(wěn)定，但客戶看了以 后，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以后，再花 一個月，在上個月所作的需求分析、框架設計、代碼、測試等等的基礎上，進一步改進，又拿出 一個更完善的產(chǎn)品來，給客戶看，讓他們提意見。就這樣，我的產(chǎn)品在功能上、質(zhì)量上都能夠逐 漸逼近客戶的要求，不會出現(xiàn)我花了大量心血后，直到最后發(fā)布之時才發(fā)現(xiàn)根本不是客戶要的東 西的情況。 缺陷：那就是周期長、成

3、本很高。 優(yōu)勢：在應付大項目、高風險項目時就比如是航天飛機的控制系統(tǒng)時，迭代的成本比項目失敗 的風險成本低得多（降低項目風險低，成功率高，特別是大型項目），用這種方式明顯有優(yōu)勢。 2021/3/10授課：授課：XXX3 迭代的迭代的 開始開始 1，迭代計劃，迭代計劃 了解細節(jié)了解細節(jié) 考慮所有觀點考慮所有觀點 書寫任務卡片書寫任務卡片 確定工作量確定工作量 2，可測試的故事，可測試的故事 3，與客戶協(xié)作，與客戶協(xié)作 4，高層次測試和事例，高層次測試和事例 與客戶一起審查與客戶一起審查 與開發(fā)人員一起審查與開發(fā)人員一起審查 測試用例作為文檔測試用例作為文檔 敏捷測試人員在迭代開始時的活動？敏捷測

4、試人員在迭代開始時的活動？ 2021/3/10授課：授課：XXX4 17.1.1 17.1.1 了解細節(jié)了解細節(jié) 理想情況下，產(chǎn)品負責人或者客戶團隊的其它成員 參加迭代計劃會議，回答大家的問題，并且提供示例來 描述每個故事的需求。如果業(yè)務方面的人都無法參加， 那么團隊中工作與客戶緊密相關(guān)的成員們可以充當客戶 的代理，比如分析師。 他們會在迭代會議上解釋故事的 細節(jié)，并從客戶的角度做決策，或者簡單的記錄大家的 問題以便依次快速回答。 17.1 迭代計劃迭代計劃 2021/3/10授課：授課：XXX5 我們在本書中始終強調(diào)，最好通過舉例子的方式來幫 助團隊理解每個故事，并把這些示例寫成測試用例來驅(qū)

5、 動開發(fā)。按照故事的優(yōu)先級為他們排序。 故事應該事先經(jīng)過評估，以保證每個故事能在幾天 之內(nèi)完成。如果我們每隔幾天就能拿到可測試的小故事 ，我們肯定不會把它們壓到迭代末期才去完成。 敏捷測試人員以及其他團隊成員們都應該警惕“范 圍擴展”的趨勢。如果發(fā)現(xiàn)一個故事好像越做越復雜了 ，無需猶豫，趕緊兩處紅牌警告。Uesr story中的Lisa 的團隊總是特意找出那些華而不實的或者“最好有”的 組件，因為他們并非故事的核心功能。這類功能可以最 后再做，如果該故事的實際開發(fā)時間比計劃時間長，他 們也可以暫時不做。 2021/3/10授課：授課：XXX6 17.1.2 考慮所有的觀點考慮所有的觀點 作為測

6、試人員，需要從整體的角度考慮每個故事對系統(tǒng)其它部分可能的潛在影響。 就像 在產(chǎn)品發(fā)布計劃會議中那樣，站在不同角色立場考慮問題用戶，利益相關(guān)者，程 序員，技術(shù)文檔編寫者以及每個參與開發(fā)功能的人員。 User story： 在迭代計劃會議中討論為某個Web添加新圖片，這是大家的討論記錄： PM：“我們來談談那個添加圖片的故事吧” RD1: “大家覺得完成它需要多長時間？”（時間） RD2：“很快，可能半天就差不多了” RD3：“那么數(shù)據(jù)庫的變動呢” （數(shù)據(jù)庫） RD2：“我已經(jīng)計算在 里邊了” RD1：“那好半天” RD4：“等等，上個迭代里我們發(fā)現(xiàn)了幾個性能方面的問題，如果我們 再添加照片，性能

7、就更差了” （性能，聯(lián)動因素）RD1：“好吧，看來我們得慎重考慮這個問題了，還 有其它方法嗎？”RD2：“我建議我們可以做個快速的嘗試，添加些圖片再做一遍性能測試如何？”（ 好的建議） 會議總結(jié)：在故事開始之前，我們做這樣一次討論，讓我們搞清楚了我們可能會遇到的問題，這種情形很 不錯。如果不太確定某個故事會對系統(tǒng)其它部分產(chǎn)生什么影響，或者不了解開發(fā)某個功能的難度，都可 以并且應該在迭代計劃階段提出來，盡早暴漏不確定因素，為之做更多的研究或嘗試以獲得更多的信息 ?；诓煌囊暯莵硖釂栍兄诿髁斯适碌胤街髦?，并且能讓團隊的工作更有成效?；诓煌囊暯莵硖釂栍兄诿髁斯适碌胤街髦?，并且能讓團隊的工作

8、更有成效。 2021/3/10授課：授課：XXX7 17.1.3 書寫任務卡片書寫任務卡片 在整個團隊都對故事有了清晰的了解之后，可以開始評估并寫到任務卡 片上了。因為敏捷開發(fā)方式通過測試來驅(qū)動編碼，我們同時編寫測試和開發(fā) 任務卡片。 有的團隊喜歡把測試任務直接寫在其開發(fā)任務的卡片上。這是種簡單的 解決方法，因為很顯然一個開發(fā)任務只有當它通過了測試之后才能算是“已 完成”。這種做法可以避免形成“小瀑布”的趨勢，也就是把測試留在最后 來做，這通常會讓RD覺得既然這個故事已經(jīng)提交給了QA，它就已經(jīng)完成了。 總之，選擇一種適合你們團隊的任務卡片編寫的方式即可。 在寫開發(fā)任務卡片時，要保證編碼任務的評

9、估值包括了寫單元測試和程序 員要做的其它測試時間。測試人員有責任確保每張卡片的估計值都是合理的 。如果估計值的誤差達到2倍以上，那么有必要進行再次討論并重新估值。 測試數(shù)據(jù)是評估測試任務時需要考慮的另一個事項。所以獲取測試數(shù)據(jù)所 花費的時間也應該考慮到評估時間里。 2021/3/10授課：授課：XXX8 17.1.4 確定工作量確定工作量 身為一名測試人員，我們的職責是保證有足夠的測試 時間，而且還要不斷提醒團隊測試和質(zhì)量是整個團隊共 同的責任。當團隊要決定在迭代中可以交付多少故事時 要明確其標準是：“我們能夠完成多少編碼和測試工 作？”。有時候有些故事的代碼編寫十分簡單，但是測 試卻是很復雜

10、需要花費很多的時間。作為測試人員，要 記住重要的是你只能同意將能夠完成測試的故事加入到 迭代中。如果必須要對迭代中交付的故事作出承諾，就 應該作出保守的承諾。 2021/3/10授課：授課：XXX9 17.2 17.2 可測試故事可測試故事 當你研究故事而開發(fā)人員開始思考如何實現(xiàn)它們時 ，請始終考慮如何測試它們。即故事具有可測試性。 User storyUser story： 當團隊正在重寫多步過程的第一步時，令人意外的 是，當開始編寫新步驟時，過程的其它步驟都失敗了， 除非第一步完整的實現(xiàn)了，否則迭代中的任何改變都無 法測試（說明此故事不具有可測試性）。在計劃故事時 沒有考慮可測試性。導致了

11、這樣的問題。在下一次發(fā)布 時，他們吸取了之前的教訓，RD在頁面上創(chuàng)建了一個額 外的按鈕，允許測試人員選擇要么調(diào)用新頁面或者舊頁 面以測試其它故事。如果不知道怎么測試某個故事的可 測試性，請在迭代計劃會中提出來。 2021/3/10授課：授課：XXX10 17.3 17.3 與客戶協(xié)作與客戶協(xié)作 與客戶或者客戶代表（如功能測試人與客戶或者客戶代表（如功能測試人 員）緊密合作是敏捷測試人員最重要的工作員）緊密合作是敏捷測試人員最重要的工作 之一。之一。當啟動迭代時，客戶協(xié)作也進入了更 高階段。此時，請求客戶提供更高的示例， 在白板上討論，然后將這些示例轉(zhuǎn)化為驅(qū)動 編碼的測試。 即使產(chǎn)品負責人和其他

12、客戶 在迭代規(guī)劃期間和之前解釋說明了故事，有 時在迭代開始時簡要溫習一下也是有幫助的 。不是所有人之前都聽到過，再之客戶可能 還有更多的信息。 2021/3/10授課：授課：XXX11 17.4 17.4 高層次測試和事例高層次測試和事例 我們需要“全局性”的測試來幫助開發(fā)人員確保故事的正 確方向。通常，我們建議從示例開始，然后將其轉(zhuǎn)化為測試。 高層次測試應該表現(xiàn)故事背后的主要意圖。它們可能包括 預期和非預期行為的示例。 分布式團隊（不在同一區(qū)域）需要通過電子網(wǎng)絡方式獲得 高層次的測試，而在同一區(qū)域工作的團隊可以通過在白板上畫 畫來合作，甚至與客戶坐在一起，在編碼時告訴他們的需求 在迭代啟動時

13、，要注意快速了解每一個故事的基本需求， 并在適合團隊的情境中表述出來。大多數(shù)敏捷團隊的最大問題 是如何充分理解每個故事一準確發(fā)布客戶所需的東西。他們的 代碼可能沒有缺陷，但是也許不完全符合客戶的預期功能，或 者在客戶不斷澄清自己的需求時，他們在迭代時不得不重復大 量工作，并最終導致消耗了時間而無法按時完成故事。 2021/3/10授課：授課：XXX12 17.4.1 17.4.1 與客戶一起審查與客戶一起審查 持續(xù)與客戶保持協(xié)作關(guān)系是非常重要的持續(xù)與客戶保持協(xié)作關(guān)系是非常重要的。與客 戶審查高層次測試是加強協(xié)作與溝通的好機會，特 別是對新的敏捷團隊來說，在團隊中習慣了不斷討 論故事，需求和測試

14、用例之后，可能不需要坐下來 回顧每一個測試用例。 如果團隊通過合同開發(fā)軟件，需求和測試用例 可能是必須提供的東西。即使不是，最好通過客戶 易于自己理解的形式提供測試用例。 2021/3/10授課：授課：XXX13 17.4.2 17.4.2 與開發(fā)人員一起審查與開發(fā)人員一起審查 與開發(fā)人員坐下來審查高層次測試和需求，如果與你工 作的同仁在外地，想辦法安排電話會議溝通。如果團隊成員 難以理解高層次測試和需求，下次就嘗試別的辦法。 具備良好領域知識的RD能夠理解故事并在高層次測試編 寫前開始編碼。即便是這樣，最好還是與開發(fā)人員從客戶和 測試人員的角度審查故事。他們對故事的理解可能與你不同 ，請關(guān)注這種區(qū)別。測試用例有助于把故事置于應用其余部 分的環(huán)境中。開發(fā)人員可以利用測試幫助他們正確編碼。所 以才要盡可能在迭代一開始就編寫測試RD開始編碼之前 。 我們通常會詢問RD:我們遺漏了什么（我們遺漏了什么（Edit caseEdit case）？代碼）？代碼 的高風險區(qū)域是什么？他們認為測試應該關(guān)注哪些地方？獲的高風險區(qū)域是什么？他們認為測試應該關(guān)注哪些地方？獲 得更多技術(shù)觀點有助于設計詳細的測試用例。得更多技術(shù)觀點有助于設計詳細的測試用例。 2021/3/10授課：授課：