敏捷測試之-迭代開始

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

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

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

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

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

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

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

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

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

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

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

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

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

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