敏捷測(cè)試之迭代開(kāi)始

敏捷測(cè)試之迭代開(kāi)始第1頁(yè)，共15頁(yè)，2023年，2月20日，星期一

為什么要開(kāi)始迭代迭代模型是RUP（RationalUnifiedProcess，統(tǒng)一軟件開(kāi)發(fā)過(guò)程)推薦的周期模型。迭代是循環(huán)，往復(fù)反饋的一個(gè)過(guò)程。理解：我們大家可以這樣想：我們開(kāi)發(fā)一個(gè)產(chǎn)品，如果不太復(fù)雜，會(huì)采用瀑布模型，這樣幾個(gè)月過(guò)去了，直到最后一天發(fā)布時(shí)，大家可以見(jiàn)到一個(gè)完整的產(chǎn)品。這種模型周期相對(duì)短些，成本相對(duì)低些。但這樣的方式有明顯的缺點(diǎn)，假如我們對(duì)用戶的需求判斷的不是很準(zhǔn)確時(shí)，你工作了幾個(gè)月甚至是幾年，當(dāng)你把產(chǎn)品拿給客戶看時(shí)，客戶往往會(huì)大吃一驚，這就是我要的東西嗎？如果采用迭代模型：假如這個(gè)產(chǎn)品要求6個(gè)月交貨，我在第一個(gè)月就會(huì)拿出一個(gè)產(chǎn)品來(lái)，當(dāng)然，這個(gè)產(chǎn)品會(huì)很不完善，會(huì)有很多功能還沒(méi)有添加進(jìn)去，bug很多，還不穩(wěn)定，但客戶看了以后，會(huì)提出更詳細(xì)的修改意見(jiàn)，這樣，你就知道自己距離客戶的需求有多遠(yuǎn)，我回家以后，再花一個(gè)月，在上個(gè)月所作的需求分析、框架設(shè)計(jì)、代碼、測(cè)試等等的基礎(chǔ)上，進(jìn)一步改進(jìn)，又拿出一個(gè)更完善的產(chǎn)品來(lái)，給客戶看，讓他們提意見(jiàn)。就這樣，我的產(chǎn)品在功能上、質(zhì)量上都能夠逐漸逼近客戶的要求，不會(huì)出現(xiàn)我花了大量心血后，直到最后發(fā)布之時(shí)才發(fā)現(xiàn)根本不是客戶要的東西的情況。缺陷：那就是周期長(zhǎng)、成本很高。優(yōu)勢(shì)：在應(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)勢(shì)。第2頁(yè)，共15頁(yè)，2023年，2月20日，星期一迭代的開(kāi)始1，迭代計(jì)劃了解細(xì)節(jié)考慮所有觀點(diǎn)書寫任務(wù)卡片確定工作量2，可測(cè)試的故事3，與客戶協(xié)作4，高層次測(cè)試和事例與客戶一起審查與開(kāi)發(fā)人員一起審查測(cè)試用例作為文檔敏捷測(cè)試人員在迭代開(kāi)始時(shí)的活動(dòng)？第3頁(yè)，共15頁(yè)，2023年，2月20日，星期一

17.1.1了解細(xì)節(jié)

理想情況下，產(chǎn)品負(fù)責(zé)人或者客戶團(tuán)隊(duì)的其它成員參加迭代計(jì)劃會(huì)議，回答大家的問(wèn)題，并且提供示例來(lái)描述每個(gè)故事的需求。如果業(yè)務(wù)方面的人都無(wú)法參加，那么團(tuán)隊(duì)中工作與客戶緊密相關(guān)的成員們可以充當(dāng)客戶的代理，比如分析師。他們會(huì)在迭代會(huì)議上解釋故事的細(xì)節(jié)，并從客戶的角度做決策，或者簡(jiǎn)單的記錄大家的問(wèn)題以便依次快速回答。17.1迭代計(jì)劃第4頁(yè)，共15頁(yè)，2023年，2月20日，星期一

我們?cè)诒緯惺冀K強(qiáng)調(diào)，最好通過(guò)舉例子的方式來(lái)幫助團(tuán)隊(duì)理解每個(gè)故事，并把這些示例寫成測(cè)試用例來(lái)驅(qū)動(dòng)開(kāi)發(fā)。按照故事的優(yōu)先級(jí)為他們排序。

故事應(yīng)該事先經(jīng)過(guò)評(píng)估，以保證每個(gè)故事能在幾天之內(nèi)完成。如果我們每隔幾天就能拿到可測(cè)試的小故事，我們肯定不會(huì)把它們壓到迭代末期才去完成。

敏捷測(cè)試人員以及其他團(tuán)隊(duì)成員們都應(yīng)該警惕“范圍擴(kuò)展”的趨勢(shì)。如果發(fā)現(xiàn)一個(gè)故事好像越做越復(fù)雜了，無(wú)需猶豫，趕緊兩處紅牌警告。Uesrstory中的Lisa的團(tuán)隊(duì)總是特意找出那些華而不實(shí)的或者“最好有”的組件，因?yàn)樗麄儾⒎枪适碌暮诵墓δ?。這類功能可以最后再做，如果該故事的實(shí)際開(kāi)發(fā)時(shí)間比計(jì)劃時(shí)間長(zhǎng)，他們也可以暫時(shí)不做。第5頁(yè)，共15頁(yè)，2023年，2月20日，星期一

17.1.2考慮所有的觀點(diǎn)

作為測(cè)試人員，需要從整體的角度考慮每個(gè)故事對(duì)系統(tǒng)其它部分可能的潛在影響。就像在產(chǎn)品發(fā)布計(jì)劃會(huì)議中那樣，站在不同角色立場(chǎng)考慮問(wèn)題——用戶，利益相關(guān)者，程序員，技術(shù)文檔編寫者以及每個(gè)參與開(kāi)發(fā)功能的人員。

Userstory：在迭代計(jì)劃會(huì)議中討論為某個(gè)Web添加新圖片，這是大家的討論記錄：PM：“我們來(lái)談?wù)勀莻€(gè)添加圖片的故事吧”RD1:“大家覺(jué)得完成它需要多長(zhǎng)時(shí)間？”（時(shí)間）RD2：“很快，可能半天就差不多了”RD3：“那么數(shù)據(jù)庫(kù)的變動(dòng)呢”（數(shù)據(jù)庫(kù)）RD2：“我已經(jīng)計(jì)算在里邊了”RD1：“那好半天”RD4：“等等，上個(gè)迭代里我們發(fā)現(xiàn)了幾個(gè)性能方面的問(wèn)題，如果我們?cè)偬砑诱掌?，性能就更差了”（性能，?lián)動(dòng)因素）RD1：“好吧，看來(lái)我們得慎重考慮這個(gè)問(wèn)題了，還有其它方法嗎？”RD2：“我建議我們可以做個(gè)快速的嘗試，添加些圖片再做一遍性能測(cè)試如何？”（好的建議）會(huì)議總結(jié)：在故事開(kāi)始之前，我們做這樣一次討論，讓我們搞清楚了我們可能會(huì)遇到的問(wèn)題，這種情形很不錯(cuò)。如果不太確定某個(gè)故事會(huì)對(duì)系統(tǒng)其它部分產(chǎn)生什么影響，或者不了解開(kāi)發(fā)某個(gè)功能的難度，都可以并且應(yīng)該在迭代計(jì)劃階段提出來(lái)，盡早暴漏不確定因素，為之做更多的研究或嘗試以獲得更多的信息?；诓煌囊暯莵?lái)提問(wèn)有助于明了故事地方主旨，并且能讓團(tuán)隊(duì)的工作更有成效。

第6頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.1.3書寫任務(wù)卡片

在整個(gè)團(tuán)隊(duì)都對(duì)故事有了清晰的了解之后，可以開(kāi)始評(píng)估并寫到任務(wù)卡片上了。因?yàn)槊艚蓍_(kāi)發(fā)方式通過(guò)測(cè)試來(lái)驅(qū)動(dòng)編碼，我們同時(shí)編寫測(cè)試和開(kāi)發(fā)任務(wù)卡片。有的團(tuán)隊(duì)喜歡把測(cè)試任務(wù)直接寫在其開(kāi)發(fā)任務(wù)的卡片上。這是種簡(jiǎn)單的解決方法，因?yàn)楹茱@然一個(gè)開(kāi)發(fā)任務(wù)只有當(dāng)它通過(guò)了測(cè)試之后才能算是“已完成”。這種做法可以避免形成“小瀑布”的趨勢(shì)，也就是把測(cè)試留在最后來(lái)做，這通常會(huì)讓RD覺(jué)得既然這個(gè)故事已經(jīng)提交給了QA，它就已經(jīng)完成了?？傊?，選擇一種適合你們團(tuán)隊(duì)的任務(wù)卡片編寫的方式即可。在寫開(kāi)發(fā)任務(wù)卡片時(shí)，要保證編碼任務(wù)的評(píng)估值包括了寫單元測(cè)試和程序員要做的其它測(cè)試時(shí)間。測(cè)試人員有責(zé)任確保每張卡片的估計(jì)值都是合理的。如果估計(jì)值的誤差達(dá)到2倍以上，那么有必要進(jìn)行再次討論并重新估值。測(cè)試數(shù)據(jù)是評(píng)估測(cè)試任務(wù)時(shí)需要考慮的另一個(gè)事項(xiàng)。所以獲取測(cè)試數(shù)據(jù)所花費(fèi)的時(shí)間也應(yīng)該考慮到評(píng)估時(shí)間里。第7頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.1.4確定工作量

身為一名測(cè)試人員，我們的職責(zé)是保證有足夠的測(cè)試時(shí)間，而且還要不斷提醒團(tuán)隊(duì)測(cè)試和質(zhì)量是整個(gè)團(tuán)隊(duì)共同的責(zé)任。當(dāng)團(tuán)隊(duì)要決定在迭代中可以交付多少故事時(shí)要明確其標(biāo)準(zhǔn)是：“我們能夠完成多少編碼和測(cè)試工作？”。有時(shí)候有些故事的代碼編寫十分簡(jiǎn)單，但是測(cè)試卻是很復(fù)雜需要花費(fèi)很多的時(shí)間。作為測(cè)試人員，要記住重要的是你只能同意將能夠完成測(cè)試的故事加入到迭代中。如果必須要對(duì)迭代中交付的故事作出承諾，就應(yīng)該作出保守的承諾。第8頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.2可測(cè)試故事當(dāng)你研究故事而開(kāi)發(fā)人員開(kāi)始思考如何實(shí)現(xiàn)它們時(shí)，請(qǐng)始終考慮如何測(cè)試它們。即故事具有可測(cè)試性。

Userstory：當(dāng)團(tuán)隊(duì)正在重寫多步過(guò)程的第一步時(shí)，令人意外的是，當(dāng)開(kāi)始編寫新步驟時(shí)，過(guò)程的其它步驟都失敗了，除非第一步完整的實(shí)現(xiàn)了，否則迭代中的任何改變都無(wú)法測(cè)試（說(shuō)明此故事不具有可測(cè)試性）。在計(jì)劃故事時(shí)沒(méi)有考慮可測(cè)試性。導(dǎo)致了這樣的問(wèn)題。在下一次發(fā)布時(shí)，他們吸取了之前的教訓(xùn)，RD在頁(yè)面上創(chuàng)建了一個(gè)額外的按鈕，允許測(cè)試人員選擇要么調(diào)用新頁(yè)面或者舊頁(yè)面以測(cè)試其它故事。如果不知道怎么測(cè)試某個(gè)故事的可測(cè)試性，請(qǐng)?jiān)诘?jì)劃會(huì)中提出來(lái)。

第9頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.3與客戶協(xié)作

與客戶或者客戶代表（如功能測(cè)試人員）緊密合作是敏捷測(cè)試人員最重要的工作之一。當(dāng)啟動(dòng)迭代時(shí)，客戶協(xié)作也進(jìn)入了更高階段。此時(shí)，請(qǐng)求客戶提供更高的示例，在白板上討論，然后將這些示例轉(zhuǎn)化為驅(qū)動(dòng)編碼的測(cè)試。即使產(chǎn)品負(fù)責(zé)人和其他客戶在迭代規(guī)劃期間和之前解釋說(shuō)明了故事，有時(shí)在迭代開(kāi)始時(shí)簡(jiǎn)要溫習(xí)一下也是有幫助的。不是所有人之前都聽(tīng)到過(guò)，再之客戶可能還有更多的信息。第10頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.4高層次測(cè)試和事例

我們需要“全局性”的測(cè)試來(lái)幫助開(kāi)發(fā)人員確保故事的正確方向。通常，我們建議從示例開(kāi)始，然后將其轉(zhuǎn)化為測(cè)試。高層次測(cè)試應(yīng)該表現(xiàn)故事背后的主要意圖。它們可能包括預(yù)期和非預(yù)期行為的示例。分布式團(tuán)隊(duì)（不在同一區(qū)域）需要通過(guò)電子網(wǎng)絡(luò)方式獲得高層次的測(cè)試，而在同一區(qū)域工作的團(tuán)隊(duì)可以通過(guò)在白板上畫畫來(lái)合作，甚至與客戶坐在一起，在編碼時(shí)告訴他們的需求在迭代啟動(dòng)時(shí)，要注意快速了解每一個(gè)故事的基本需求，并在適合團(tuán)隊(duì)的情境中表述出來(lái)。大多數(shù)敏捷團(tuán)隊(duì)的最大問(wèn)題是如何充分理解每個(gè)故事一準(zhǔn)確發(fā)布客戶所需的東西。他們的代碼可能沒(méi)有缺陷，但是也許不完全符合客戶的預(yù)期功能，或者在客戶不斷澄清自己的需求時(shí)，他們?cè)诘鷷r(shí)不得不重復(fù)大量工作，并最終導(dǎo)致消耗了時(shí)間而無(wú)法按時(shí)完成故事。第11頁(yè)，共15頁(yè)，2023年，2月20日，星期一

17.4.1與客戶一起審查持續(xù)與客戶保持協(xié)作關(guān)系是非常重要的。與客戶審查高層次測(cè)試是加強(qiáng)協(xié)作與溝通的好機(jī)會(huì)，特別是對(duì)新的敏捷團(tuán)隊(duì)來(lái)說(shuō)，在團(tuán)隊(duì)中習(xí)慣了不斷討論故事，需求和測(cè)試用例之后，可能不需要坐下來(lái)回顧每一個(gè)測(cè)試用例。如果團(tuán)隊(duì)通過(guò)合同開(kāi)發(fā)軟件，需求和測(cè)試用例可能是必須提供的東西。即使不是，最好通過(guò)客戶易于自己理解的形式提供測(cè)試用例。

第12頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.4.2與開(kāi)發(fā)人員一起審查

與開(kāi)發(fā)人員坐下來(lái)審查高層次測(cè)試和需求，如果與你工作的同仁在外地，想辦法安排電話會(huì)議溝通。如果團(tuán)隊(duì)成員難以理解高層次測(cè)試和需求，下次就嘗試別的辦法。具備良好領(lǐng)域知識(shí)的RD能夠理解故事并在高層次測(cè)試編寫前開(kāi)始編碼。即便是這樣，最好還是與開(kāi)發(fā)人員從客戶和測(cè)試人員的角度審查故事。他們對(duì)故事的理解可能與你不同，請(qǐng)關(guān)注這種區(qū)別。測(cè)試用例有助于把故事置于應(yīng)用其余部分的環(huán)境中。開(kāi)發(fā)人員可以利用測(cè)試幫助他們正確編碼。所以才要盡可能在迭代一開(kāi)始就編寫測(cè)試——RD開(kāi)始編碼之前。我們通常會(huì)詢問(wèn)RD:我們遺漏了什么（Editcase）？代碼的高風(fēng)險(xiǎn)區(qū)域是什么？他們認(rèn)為測(cè)試應(yīng)該關(guān)注哪些地方？獲得更多技術(shù)觀點(diǎn)有助于設(shè)計(jì)詳細(xì)的測(cè)試用例。第13頁(yè)，共15頁(yè)，2023年，2月20日，星期一17.4.3測(cè)試用例作為文檔

高層次測(cè)試用例，加上