軟件開發(fā)中心的敏捷測試實踐分享

1、前言        如果您已經(jīng)閱讀過敏捷測試系列文章的第一篇，敏捷的實質(zhì)，您應該已經(jīng)了解敏捷的定義，了解什么樣的團隊是敏捷的團隊了。而您也可能早已開始思考，什么是敏捷測試的實質(zhì)？敏捷的測試團隊又是如何形成自我管理、自我發(fā)展的組織呢？測試團隊又是如何安排日常工作呢？敏捷測試活動與傳統(tǒng)測試活動有很大差異嗎？為了進一步讓您了解如何將敏捷原則運用到活生生的日常測試活動中，我們?yōu)槟扑]敏捷測試系列文章的第二篇敏捷測試的實踐。        在敏捷活動如火如荼的推廣運

2、動中，我們顯然無法預知如何在您的特定的復雜環(huán)境中您能否最后達成所愿，也無法為您預測出前進道路的分岔口可能唯一的正確的線路，我們卻可以為您點起一盞明亮“街燈”，在這迷霧中驅(qū)除黑暗。我們將為您提供一個可以借鑒和可供參考的成功的敏捷測試實踐案例。我們將逐一向您介紹、分析這個案例中的敏捷團隊的組織結(jié)構(gòu)，主要的敏捷測試行為，迭代的測試模型和一套以四周為周期的敏捷測試活動時間表。        請您運用您已具備的敏捷實質(zhì)、敏捷原則的知識，并結(jié)合您的獨特項目環(huán)境、帶著您的問題，與筆者一起再度分析這個案例，希望您最終也能得到滿意的答案，并隨

3、后開始實施部署敏捷測試。敏捷測試的實質(zhì)        測試不僅僅是測試軟件本身，還包括軟件測試的過程和模式。產(chǎn)品發(fā)布后才發(fā)現(xiàn)很多問題，很可能是軟件開發(fā)過程出了問題。因此測試除了需要確保軟件的質(zhì)量，即軟件做了正確的事情，以及軟件做了應該做的事情以外，敏捷的測試團隊還要保證整個軟件開發(fā)過程是正確的。        敏捷開發(fā)的最大特點是高度迭代，有周期性，并且能夠及時、持續(xù)的響應客戶的頻繁反饋。敏捷測試即是不斷修正質(zhì)量指標，正確建立測試策略，確認客戶的有效需求得

4、以圓滿實現(xiàn)和確保整個生產(chǎn)的過程安全的、及時的發(fā)布最終產(chǎn)品。敏捷測試人員因而需要在活動中關(guān)注產(chǎn)品需求，產(chǎn)品設(shè)計，解讀源代碼；在獨立完成各項測試計劃、測試執(zhí)行工作的同時，敏捷測試人員需要參與幾乎所有的團隊討論，團隊決策。作為一名優(yōu)秀的敏捷測試人員，他（她）需要在有限的時間內(nèi)完成更多的測試的準備和執(zhí)行，并富有極強的責任心和領(lǐng)導力。更重要的是，優(yōu)秀的測試人員需要能夠擴展開來做更多的與測試或許無關(guān)，但與團隊共同目標直接相關(guān)的工作。他（她）將幫助團隊其他成員解決困難、幫助實現(xiàn)其預期目標，發(fā)揚高度協(xié)作精神以幫助團隊的最終獲取成功。需要指出的是，團隊的高度協(xié)作既需要團隊成員的勇敢，更需要團隊成員的主動配合和幫

5、助。對于測試人員如此，對于開發(fā)、設(shè)計人員，其他成員也是如此。敏捷測試的方法與實踐        是的，敏捷測試也需要高度迭代工作、頻繁得到 STAKEHOLDER、客戶的反饋，需要動態(tài)調(diào)整測試計劃、測試的執(zhí)行。并且，敏捷測試人員參與到了更多的敏捷生產(chǎn)活動中，積極的影響了團隊做出的決定和計劃。        是的，“人”才是敏捷的實體，敏捷測試也是以人為本的。不難理解，“敏捷”的一切都圍繞著人展開，如敏捷鼓勵直接，平行的溝通；敏捷需要持續(xù)的客戶反饋以及敏捷活

6、動的設(shè)計，方案和決策需要團隊協(xié)同制定等等，敏捷測試需要一支非同尋常的團隊，不同于以往傳統(tǒng)開發(fā)模式下的團隊結(jié)構(gòu)。關(guān)于敏捷團隊、敏捷測試團隊的組成和介紹，將是我們講述敏捷測試實踐的第一步。        “人”是重心，方法、策略是輔。為了適應不同的團隊結(jié)構(gòu)，不同的項目環(huán)境，敏捷項目和敏捷活動的實踐也應該因“人”而異，但是，并不是說可以天馬行空，我行我素。一旦脫離了正確的敏捷方法、和敏捷原則的指導，我們的敏捷活動就好比摸黑前行了。        這正是我們需要學

7、習前輩和敏捷主義大師們的經(jīng)驗意義所在了，筆者在過去的實踐中受益頗多的也正是前人的實踐經(jīng)驗和方法。因此，學習前人的經(jīng)驗和方法，并運用這些最佳實踐來幫助敏捷開發(fā)團隊，甚至是傳統(tǒng)團隊來解決時下重要的問題是十分有意義的事情。筆者不敢妄自尊大將自己的一般實踐納入經(jīng)典方法范疇，但經(jīng)歷了兩年的研究和改進，筆者提出的敏捷測試的原則也得到了業(yè)內(nèi)同僚和“大師”的普遍認可。經(jīng)過多次和其他項目團隊的經(jīng)驗交流，我們也不斷的改進著我們的原則、方法。因此，筆者要非常感謝參與討論的同僚們，沒有你們的熱情參與，也不會有今天的筆者信心百倍的執(zhí)筆了。正如筆者在借鑒了前人的成功案例中的經(jīng)驗和方法之后定制了符合項目需求的測試原則一樣，

8、相信，讀者們在閱讀了筆者的敏捷測試原則和方法后，同樣也會有所收獲。而對筆者經(jīng)歷的敏捷實踐活動中的方法和測試模型的講解將成為我們講述敏捷實踐的第二步，也是本文的重點。        綜上所述，筆者將運用本文的主要篇幅為大家講解這個敏捷實踐。它們是：        敏捷團隊組織構(gòu)成，敏捷測試團隊的任務和使命；         敏捷開發(fā)團隊以測試為驅(qū)動的開發(fā)方式測試驅(qū)動開發(fā)，這是種獨

9、特的測試？還是開發(fā)？         遞增型的迭代測試，它首先是對敏捷測試過程活動和生命周期模型的介紹，通過學習經(jīng)典的敏捷增量測試模型，我們將敏捷測試的各類活動有機的組合到了一起。在此之上，對定制后的獨特敏捷增量測試模型的分析和理解，幫助我們理解測試活動的規(guī)劃和管理；         以及需要特別關(guān)注的遞增型迭代測試的關(guān)鍵活動之一“靜態(tài)測試”；這也是筆者認為的最高難度、最具影響力的敏捷測試活動。它將測試團隊最早的引入產(chǎn)品開發(fā)環(huán)節(jié)，測試人

10、員以第一用戶的角度判斷設(shè)計的有效性，此活動較早的暴露了設(shè)計缺陷、避免了團隊對目標的不一致理解等，是測試活動中最有創(chuàng)造性價值的部分；         最后，筆者將談談測試活動中的測試計劃和管理，即關(guān)于測試任務估計，測試活動計劃，各個重要測試活動時間分配與安排的介紹。         然而，敏捷測試不是一蹴而就的，做到真正的敏捷，無論是從傳統(tǒng)測試模式向敏捷測試的過渡，還是組建全新的團隊都是需要循序漸進的，同時也需要團隊成員的通力合作和不斷的

11、實踐來完善敏捷測試的實踐原則和方法。敏捷團隊        考慮到敏捷團隊的組織結(jié)構(gòu)，讓我們以筆者親身經(jīng)歷的項目為例來說明。筆者曾共事的整支產(chǎn)品開發(fā)團隊被劃分成 4 個相對獨立的敏捷開發(fā)隊伍，而每支隊伍擁有相同配置的 7 名成員，他們分別具有不同的職能屬性。如圖 1 所示，每支敏捷隊伍組成成員角色包括 1 名 UCD（User Centered Designer），主要負責產(chǎn)品的主要設(shè)計，其工作主要包括界面設(shè)計、用戶的用例設(shè)計等等； 1 名 Visual Designer，主要負責產(chǎn)品界面的色彩搭配、控件的外觀設(shè)計和 UCD

12、 界面設(shè)計方案的初步實現(xiàn)和美化；1 名 Information Developer，主要負責產(chǎn)品中信息的編輯和重要文檔的撰寫工作； 3 名開發(fā)人員，主要負責產(chǎn)品的實現(xiàn)。和 1 名 QA，主要負責產(chǎn)品質(zhì)量的保障。（更多的我們將 QA 定義為具有相比于測試人員擁有更多責任的一個職能，在本文中，為了簡便起見，我們?nèi)苑Q之測試人員）。4 支敏捷的隊伍擁有相同的 SCRUM MASTER STAKEHOLDER。通常會在同一時間進入一個迭代周期，制定各自的敏捷計劃，并在同一時間退出，發(fā)布各自功能實現(xiàn)。而 4 支隊伍的勞動果實被集成到一起就形成了可發(fā)布的產(chǎn)品了。圖 1. 敏捷開發(fā)團隊的組織結(jié)構(gòu) &

13、#160;      因為敏捷團隊中只有 1 名測試人員，因此需要一臂承擔測試策略的制定，測試計劃，測試腳本，測試用例設(shè)計以及測試的執(zhí)行，幫助團隊發(fā)現(xiàn)潛在問題，并協(xié)助解決問題的工作。敏捷團隊的敏捷原則也是測試人員敏捷活動的規(guī)范，測試也需要擁有和團隊的良好溝通，高度迭代的活動和不斷的獲得 STAKEHOLDER 的反饋。那團隊的結(jié)構(gòu)與敏捷本身有什么直接關(guān)系呢？與敏捷測試又有多少關(guān)聯(lián)呢？        談到這里，想起曾經(jīng)有朋友向我咨詢有關(guān)敏捷團隊的某些職能的人力配備的問題。其實，

14、筆者也無意論證 7 個人為什么是最佳組合，為什么不是 17 個，20 個人的組合。但是，敏捷原則告訴我們敏捷團隊是高度協(xié)同、民主和平等的團隊，為了讓團隊中每個人充分高效的工作。相同職能下的組員至多不好超過 3 名，最佳配置也是不同職能下配置 1 個人頭。因此、在這樣一個小型、平行的組織結(jié)構(gòu)里，溝通更加易于建立，溝通復雜度也相對較低，相比 17、20 人的團隊組織，溝通的代價也小很多。相反，很難想象在一個敏捷團隊中會擁有諸多不同風格的執(zhí)行者，決策者將是個怎樣的混亂情況。        此外，經(jīng)歷過敏捷測試的體驗，我們發(fā)現(xiàn)一個單

15、一的敏捷團隊最好保持較小的“尺寸”。這是因為擁有很多測試人員的敏捷團隊通常不但需要更大的實際工作量來匹配龐大的機體而導致團隊任務量更巨大，更復雜，失去自我管理的信心，而每個測試人員也將要花費大量精力和時間投入到內(nèi)部溝通，和可能因為內(nèi)部缺乏一致而導致的更加頻繁的反復溝通中。        每名敏捷的測試人員需要和其他敏捷團隊成員保持頻繁而必要的溝通以保證對目標，需求、設(shè)計的充分正確的理解，對需求變化能夠迅速的做出反應。另外，還需要與職能隊伍中的其他測試成員保持一致性。如此一來，溝通代價激增了，它將占到測試人員的工作中的較大比例

16、。而這種內(nèi)部溝通、協(xié)調(diào)，卻不能定義為敏捷的 Backlog 項目來計入團隊整體的工作輸出。因此，整體的測試效率并不一定隨著人力資源的投入而遞增。非但沒有實現(xiàn)敏捷原則，而恐怕因為團隊的組織結(jié)構(gòu)變得更加龐雜。所謂的“自我管理、自我發(fā)展”的團隊只能因而依靠傳統(tǒng)的管理和規(guī)劃了。筆者認為，除了因為特殊階段，特殊時期，敏捷團隊需要“聚合”更多資源來一并解決存在的高優(yōu)先級的體力型問題外，敏捷的團隊應該盡量保持著較小的“尺寸”。        果真項目投入了很多的人力資源，無論設(shè)計還是實現(xiàn)、測試團隊擁有較大的人數(shù)，那么我們應該考慮將這樣的團

17、隊可以分得更小些，工作量也相應分得更精細些，直至接近我們建議的最佳組合。至少我們認為要做好敏捷測試，就要確保敏捷團隊中的每一個職能擁有足夠清晰的職責范圍和一定程度下自由空間和在這個空間內(nèi)的充分授權(quán)。因此，但從人數(shù)和職能構(gòu)成上，敏捷團隊的構(gòu)成一定是不可忽略的重點。        正像我們前面提到的，確認軟件開發(fā)過程的正確性也尤為重要，因此作為敏捷的測試人員，更要了解敏捷的過程，比如說，測試人員需要幫助 UCD 和開發(fā)人員確定需求的可行性，測試人員要督促開發(fā)人員及時發(fā)布 build，以保障迭代結(jié)果最終能夠在通過足夠的測試后成功發(fā)

18、布等。在 build 發(fā)布后，測試人員要首先驗證當前迭代的任務是否已經(jīng)完成，其次才是驗證產(chǎn)品功能的正確性。也為了能夠在日后重復性和體力型勞動中解放出寶貴的時間去覆蓋測試更加緊要的內(nèi)容，如可用性，全球化等，測試人員需要自動化一部分測試，創(chuàng)新的、靈活的工作。        敏捷團隊是自我管理的團隊，高度協(xié)作的團隊，質(zhì)量目標即是測試團隊也是整個開發(fā)團隊追求的目標，因此開發(fā)團隊應將做好單元測試，設(shè)計團隊將幫助測試團隊設(shè)計好測試用例作為計劃內(nèi)的一項工作。這里我們推廣、建議開發(fā)人員采用、普及測試驅(qū)動開發(fā)模式。測試驅(qū)動開發(fā) &#

19、160;      測試驅(qū)動開發(fā)表現(xiàn)出迭代開發(fā)的最核心的就是開發(fā)人員自己能夠第一時間確認其需求得到了正確實現(xiàn)，而當單元測試覆蓋了更多的內(nèi)容，代碼質(zhì)量也將得到提高。測試驅(qū)動開發(fā)的指導思想就是讓開發(fā)人員在編寫功能代碼之前，先根據(jù)需求編寫測試代碼。先思考如何對將要實現(xiàn)的功能進行驗證，并完成單元測試腳本的編寫，然后編寫足夠，僅僅足夠的功能代碼滿足這些測試用例，直至通過測試。按照這個方法，遞增的在迭代中增加新功能的單元測試和功能代碼編寫，直到完成全部功能的開發(fā)。        在單元測

20、試活動中，測試人員也被鼓勵參與到單元測試的設(shè)計中來，不但可以幫助開發(fā)人員構(gòu)思出更多的單元測試用例來擴大單元測試的覆蓋率，還可通過學習如何使用單元測試，如何復用單元測試用例到回歸測試和功能測試，以達到最大化利用有效的資源（如下圖）和節(jié)約成本的作用。同時，在回歸測試和用戶接收測試（User Acceptance Test）中如能將單元測試腳本有機的關(guān)聯(lián)起來，并自動化其執(zhí)行，更能夠進一步提高測試的成效并降低測試成本。        單元測試腳本因隨需求、設(shè)計的變化隨時更新。需要開發(fā)人員站在全局的立場，開發(fā)始終堅持先修改測試腳本，再

21、修改產(chǎn)品原代碼。此時，也建議測試人員參與單元測試腳本的改進，幫助開發(fā)人員合理的變更單元測試腳本，同時著手修改測試計劃和測試策略。圖 2. 測試驅(qū)動開發(fā)遞增的迭代測試        測試驅(qū)動開發(fā)的原則應該運用于每一迭代周期的開發(fā)中。但是，測試驅(qū)動開發(fā)的單元測試仍然是以開發(fā)為目的的活動，雖然自動化測試，回歸測試和用戶的接收測試（User Acceptance Test）可以通過復用單元測試腳本提高以后的測試工作的效率，但單元測試不是我們敏捷測試討論的重點。      &

22、#160; 敏捷測試活動的主要承載者還是敏捷測試人員。測試人員如何運用敏捷原則指導測試活動還是筆者在敏捷測試實踐一文中要講述的重點。以下，筆者將通過兩個迭代測試模型來幫助了解測試人員如何結(jié)合敏捷原則實踐敏捷的測試活動。經(jīng)典敏捷增量測試模型        測試是敏捷開發(fā)過程重要的環(huán)節(jié)，自始自終測試貫穿于每個迭代。Scott W. Ambler 認為就整個產(chǎn)品的敏捷開發(fā)生命周期可以分為 4 個階段，即初始階段，項目的建設(shè)階段，產(chǎn)品發(fā)布階段和產(chǎn)品的維護階段，在關(guān)鍵的項目建設(shè)階段中，測試被分成兩個部分，Confirmatory 測試

23、和 Investigative 測試。 1 下面，我們來講講迭代的測試的這兩個方面。圖 3. 敏捷測試生命周期        Confirmative 測試就是對 build 的有效性和關(guān)鍵的功能是否正確進行驗證，測試人員依據(jù)測試用例和測試腳本的完整測試是工作的重心。原文中的 Confirmative 測試包含了開發(fā)人員的單元測試（必不可少的重要開發(fā)活動）和被稱之為 Agile Acceptance Testing 的測試部分，這段時間的測試任務用來保障迭代的必須輸出的質(zhì)量?；镜墓δ?、非功能的任務，但凡是在迭代開始時制定的

24、計劃中承諾的高優(yōu)先級需求，哪怕是很繁瑣的細節(jié)工作都要被充分的測試和驗證。        Investigative 測試是對 Confirmative 測試的補充和是更廣泛的測試活動，測試團隊在完成 Confirmative 測試后的時間用來做這部分測試，它包含功能測試，文檔測試和系統(tǒng)測試以及和其他產(chǎn)品、環(huán)境之間產(chǎn)生的必然的 Integration 測試，還有個非常有趣的測試活動叫做 Exploratory 測試，筆者認為這部分測試是測試人員創(chuàng)造性的采用多種不同途徑去嘗試測試產(chǎn)品。就好比“猴子敲鍵盤”一樣，測試員使用各種手段

25、來考驗 build 和產(chǎn)品的穩(wěn)定和正確性等。圖 4. 敏捷測試的 Incremental Testing自定制的敏捷增量測試模型        我們在敏捷項目開發(fā)的過程中使用了定制的測試流程，我們同樣有相同的兩部分測試，即 Confirmative 和 Investigative 兩部分。不同的是，我們原則的將這兩部分測試都放在當前迭代的計劃內(nèi)完成。原因是，敏捷測試團隊針對當前迭代的任務計劃本應服務于當前的產(chǎn)品，過去的迭代產(chǎn)物，或者因為需求變更不再適用，又或者因為未解決的質(zhì)量缺陷使得實際測試效果不佳。而同時，因為 Produ

26、ct Owner 和 STAKEHOLDER 的期望是團隊能夠高效的完成當前迭代的任務，完成更高優(yōu)先級的工作，每個迭代的考核亦非常清晰。為了完成服從當前的高優(yōu)先級任務，計劃，也為了 STAKEHOLDER 更好的關(guān)注和幫助當前問題的及時解決，測試人員對以往 Build 的測試應應合理的計入先前迭代的任務而不是當前迭代計劃。倘若真要測試以往的產(chǎn)品而不是最新的，敏捷測試的管理也將變得有些困難，同時測試團隊所關(guān)注的問題也只能是過時的，只能成為團隊的低優(yōu)先級的問題。這不是與團隊整體的目標背離嗎？因此，我們建議測試團隊使用我們改進后的敏捷增量測試模型，即在當前迭代僅僅完成當前迭代的計劃，而所有測試都需要

27、圍繞最新的產(chǎn)品 Build 進行。圖 5. 定制的 Incremental Testing        在我們新的增量測試模型中 Confirmative 測試包含對需求的靜態(tài)測試，開發(fā)人員做的單元測試，以及 Build 驗證測試，功能測試（僅限于對當前迭代功能）和重要的其他類型測試。通過了 Confirmative 測試的產(chǎn)品 Build 就可以作為在迭代結(jié)束時發(fā)布了。而為了產(chǎn)品擁有更好的質(zhì)量，也為了完成對那些較低優(yōu)先級的質(zhì)量驗證的需求得以確保成功的實現(xiàn)，我們需要針對性的做系統(tǒng)測試，壓力，并發(fā)，安全甚至全球化的測試，這部

28、分我們把它叫做 Investigative 測試。還需要強調(diào)的是，為了保障產(chǎn)品的最終穩(wěn)定，為了產(chǎn)品不會出現(xiàn)在代碼重構(gòu)后的質(zhì)量回歸現(xiàn)象，我們將回歸測試（Regression Test）放在這個階段，用以涵蓋對以往關(guān)鍵功能的再度驗證。靜態(tài)測試        在筆者的測試模型里，confirmative 測試增加了“靜態(tài)測試”，本人認為這部分測試是對測試人員最具挑戰(zhàn)的部分。一個好的測試人員能夠第一時間找到需求分析、設(shè)計中的模棱兩可，遺漏，錯誤的地方，能夠促進團隊前期工作的高效完成，將很大程度降低將來產(chǎn)品的質(zhì)量缺陷的數(shù)量，積極影響了

29、敏捷開發(fā)的最終輸出。這部分工作是測試團隊，開發(fā)、設(shè)計團隊最默契合作的階段，交流非常頻繁，正是通過積極的溝通和及時的修正與團隊目標“誤差”使得團隊更加明確其方向，更有凝聚力和也得以發(fā)揮了團隊的最佳戰(zhàn)斗力。在筆者的項目經(jīng)歷中，往往這個階段會需要一個迭代周期 1/4 左右的時間。這同時也說明了靜態(tài)測試在敏捷測試類型中的重要性。        在敏捷開發(fā)過程的靜態(tài)測試即項目迭代開發(fā)前期測試人員的最主要工作。值得再次強調(diào)的是，在這段時期測試人員的工作重心是認真了解需求和用例設(shè)計，并針對設(shè)計的可行性，可用性進行驗證，確認設(shè)計是對需求的準

30、確實現(xiàn)，最佳實現(xiàn)。圖 6. 靜態(tài)測試需要的 Strategy Thinking        對于靜態(tài)測試的方法，我們在這里需要推廣 RUP 的 Use Case，這是個很好的分析需求的方法，也是測試人員作為靜態(tài)測試的使用的方法之一。對產(chǎn)品長期戰(zhàn)略和業(yè)務的熟悉可以幫助測試人員更好的理解團隊的用例設(shè)計，視圖、模塊等，也能夠通過對比分析，直接找出某些設(shè)計中的缺陷，以提高設(shè)計的質(zhì)量。項目的開發(fā)前期階段，設(shè)計是占有非常重要的比例，而設(shè)計是直接影響產(chǎn)品質(zhì)量的環(huán)節(jié)，因而確保這一階段的質(zhì)量對產(chǎn)品的品質(zhì)提高起到?jīng)Q定性作用。針對開發(fā)出來的用例

31、，設(shè)計者對用例的描述通常故事情節(jié)比較簡單，缺乏完備和邏輯的縝密。而開發(fā)和測試需要的是詳細的設(shè)計，這個用例設(shè)計和各種輔助的邏輯應該將用例定義的清晰和明確，例如邊界條件，例外條件，數(shù)據(jù)的格式和其他性能指標的界定等等都需要涵蓋。因此，測試人員應該領(lǐng)導團隊幫助明確出用例更多的細節(jié)。比如，在一次設(shè)計用例討論中，設(shè)計者提出“我需要一個 Overlayer”。那么測試人員應該要問：“如何打開這樣一個 Overlayer，如何關(guān)閉？”“這個 Overlayer 需要多大平面尺寸，是否支持調(diào)整，是否支持對屏幕大小的自動適應”，“Overlayer 的打開和關(guān)閉是否需要有動態(tài)漸變的效果？”，“Overlayer

32、的是否需要滾動條？”，等等。        這個過程能夠幫助團隊發(fā)現(xiàn)早期的設(shè)計缺陷，通過發(fā)現(xiàn)問題，并定制新的設(shè)計方案，團隊也通過這個過程，更好的了解了測試的重要性，也摒除了可能存在的對需求的種種“假設(shè)”，因而更加明確了團隊的目標和方向。這是個非常關(guān)鍵的過程。尤其是對測試人員而言，任何“假設(shè)“都是有害的，所以一定需要把不清楚和模棱兩可的問題從一開始就理清楚。敏捷測試的計劃與管理        做好了測試的思想準備，并了解如何從需求開發(fā)出測試用例，敏捷測試人員

33、接著需要做的就是參考產(chǎn)品需求和團隊的設(shè)計制定和計劃測試任務和各種測試活動，即測試策略和測試計劃的制定。每個迭代敏捷開發(fā)都將關(guān)系產(chǎn)品的功能點和非功能點的需求作為產(chǎn)品的 Backlog 編入待開發(fā)的序列，敏捷團隊從中會選擇適量的 Backlog 項目來作為當前迭代的 Backlog 去實現(xiàn)。測試人員同樣根據(jù)需要制定出相應的測試工作，并羅列于團隊的 Backlog 項目中，承諾了在迭代結(jié)束時可以做好的足夠的測試工作。        對于測試計劃中的 confirmative 測試，這部分必須做到高質(zhì)量的按時完成。而對于 Inves

34、tigative 部分，我們應該適量的計劃到當前迭代中，切忌不要做 over commit。圖 7. 計劃測試 Backlog 項目        接著，測試人員需要撰寫測試用例和測試腳本了。測試用例的撰寫和傳統(tǒng)測試基本沒什么差異，按照已有的模式撰寫就好了。筆者的測試團隊，使用了 XML 文件格式保存所有測試用例，原因主要是沿用了測試團隊原有的習慣，而同時也因為 XML 測試用例能夠更好的匹配自動化測試的需要，并且便于更新。測試腳本是自動化測試的產(chǎn)物，敏捷開發(fā)周期短，變化多，很難拿到一個穩(wěn)定的產(chǎn)品再開始做自動化。而自動化腳本

35、的設(shè)計自然要避免去測試不穩(wěn)定部分，開始的迭代周期幾乎百廢待興，自動化作用不大，到了中期，筆者的團隊自動化測試才稍成氣候。        測試人員需要的是在根據(jù)測試策略開發(fā)出這相應腳本和用例，需要把握測試范圍，與計劃和測試策略一致，測試也要量力而行，做到足夠的測試，保障迭代的正常退出就很好了。圖 8. 依據(jù) Business Scenario 制定測試策略敏捷測試的活動時間表        通過實施上述的敏捷測試原則，測試團隊可以逐漸形成符合自身特點的敏捷測

36、試流程、敏捷測試最佳實踐，久而久之形成獨立的敏捷團隊文化。以筆者所在團隊為例，歷時 1 年，經(jīng)歷 12 個迭代后，我們逐漸形成了一套可以遵循測試活動時間表。我將他放到文章的最后，這張表包含了敏捷測試團隊的各項活動安排和必要的前提與進入條件。在這張表中，測試團隊較早的涉入，較早的開展測試，以及各項相關(guān)工作，并與設(shè)計和開發(fā)人員緊密的合作，它確保了測試團隊乃至整個敏捷團隊的工作的按期完成，是值得向大家推薦一種最佳實踐。因為篇幅關(guān)系，這里僅對其做簡單的描述。圖 9. 敏捷測試 Work Flow 最佳實踐        第一周的工作如先前所講，做靜態(tài)測試，確定測試策略和制定可行的測試計劃，劃定測試范圍。這個階段的前提是敏捷團隊確定了當下迭代周期內(nèi)需要完成的 Backlog 項目。        第二周的工作是準備開始測試的執(zhí)行，因此要準備好測試用例和測試環(huán)境。特別的是，測試人員是根據(jù)需求和團隊討論、設(shè)計出的用例來開發(fā)測試用例的。雖然測試用例的細節(jié)程度不能與傳統(tǒng)開發(fā)中針對已經(jīng)開發(fā)完的產(chǎn)品、產(chǎn)品開發(fā)文檔開發(fā)的測試用例相比，相反，許多細節(jié)，尤其是還未由團隊最終確定的內(nèi)容仍是待定狀態(tài)；但是，這些細節(jié)并非影響測試的用例設(shè)計，相反它不但簡潔、易懂，也擁有