第二部分：方法與實踐

敏捷測試的實質

測試不僅僅是測試軟件本身，還包括軟件測試的過程和模式。產品發布后才發現很多問題，很可能是軟件開發過程出了問題。因此測試除了需要確保軟件的質量，即軟件做了正確的事情，以及軟件做了應該做的事情以外，敏捷的測試團隊還要保證整個軟件開發過程是正確的。

敏 捷測試即是不斷修正質量指標，正確建立測試策略，確認客戶的有效需求得以圓滿實現和確保整個生產的過程安全的、及時的發布最終產品。敏捷測試人員因而需要 在活動中關注產品需求，產品設計，解讀源代碼；在獨立完成各項測試計劃、測試執行工作的同時，敏捷測試人員需要參與幾乎所有的團隊討論，團隊決策。作為一 名優秀的敏捷測試人員，他（她）需要在有限的時間內完成更多的測試的準備和執行，并富有極強的責任心和領導力。更重要的是，優秀的測試人員需要能夠擴展開 來做更多的與測試或許無關，但與團隊共同目標直接相關的工作。他（她）將幫助團隊其他成員解決困難、幫助實現其預期目標，發揚高度協作精神以幫助團隊的最 終獲取成功。需要指出的是，團隊的高度協作既需要團隊成員的勇敢，更需要團隊成員的主動配合和幫助。對于測試人員如此，對于開發、設計人員，其他成員也是 如此。

?

敏捷測試的方法與實踐

敏捷團隊組織構成，敏捷測試團隊的任務和使命；

敏捷開發團隊以測試為驅動的開發方式——測試驅動開發，這是種獨特的測試？還是開發？

遞增型的迭代測試，它首先是對敏捷測試過程活動和生命周期模型的介紹，通過學習經典的敏捷增量測試模型，我們將敏捷測試的各類活動有機的組合到了一起。在此之上，對定制后的獨特敏捷增量測試模型的分析和理解，幫助我們理解測試活動的規劃和管理；

以 及需要特別關注的遞增型迭代測試的關鍵活動之一——“靜態測試”；這也是筆者認為的最高難度、最具影響力的敏捷測試活動。它將測試團隊最早的引入產品開發 環節，測試人員以第一用戶的角度判斷設計的有效性，此活動較早的暴露了設計缺陷、避免了團隊對目標的不一致理解等，是測試活動中最有創造性價值的部分；

最后，筆者將談談測試活動中的測試計劃和管理，即關于測試任務估計，測試活動計劃，各個重要測試活動時間分配與安排的介紹。

然而，敏捷測試不是一蹴而就的，做到真正的敏捷，無論是從傳統測試模式向敏捷測試的過渡，還是組建全新的團隊都是需要循序漸進的，同時也需要團隊成員的通力合作和不斷的實踐來完善敏捷測試的實踐原則和方法。

?

敏捷團隊

筆者曾共事的整支產品開發團隊被劃分成 4 個相對獨立的敏捷開發隊伍，而每支隊伍擁有相同配置的 7 名成員，他們分別具有不同的職能屬性。

每支敏捷隊伍組成成員角色包括：

1 名 UCD（User Centered Designer），主要負責產品的主要設計，其工作主要包括界面設計、用戶的用例設計等等；

1 名 Visual Designer，主要負責產品界面的色彩搭配、控件的外觀設計和 UCD 界面設計方案的初步實現和美化；

1 名 Information Developer，主要負責產品中信息的編輯和重要文檔的撰寫工作；

3 名開發人員，主要負責產品的實現；

1 名 Tester，主要負責產品質量的保障。

4 支敏捷的隊伍擁有相同的 SCRUM MASTER STAKEHOLDER。通常會在同一時間進入一個迭代周期，制定各自的敏捷計劃，并在同一時間退出，發布各自功能實現。而 4 支隊伍的勞動果實被集成到一起就形成了可發布的產品了。

因為敏捷團 隊中只有 1 名測試人員，因此需要一臂承擔測試策略的制定，測試計劃，測試腳本，測試用例設計以及測試的執行，幫助團隊發現潛在問題，并協助解決問題的工作。敏捷團隊 的敏捷原則也是測試人員敏捷活動的規范，測試也需要擁有和團隊的良好溝通，高度迭代的活動和不斷的獲得 STAKEHOLDER 的反饋。那團隊的結構與敏捷本身有什么直接關系呢？與敏捷測試又有多少關聯呢？

?

敏捷原則告訴我們敏捷團隊是高度協同、民主和平等的團隊，為了讓團隊中每個人充分高效的工作。相同職能下的組員至多不好超過 3 名，最佳配置也是不同職能下配置 1 個人頭。因此、在這樣一個小型、平行的組織結構里，溝通更加易于建立，溝通復雜度也相對較低，相比 17、20 人的團隊組織，溝通的代價也小很多。相反，很難想象在一個敏捷團隊中會擁有諸多不同風格的執行者，決策者將是個怎樣的混亂情況。

?

此外，經歷過敏捷測試的體驗，我們發現一個單一的敏捷團隊最好保持較小的“尺寸”。這是因為擁有很多測試人員的敏捷團隊通常不但需要更大的實際工作量來匹配龐大的機體而導致團隊任務量更巨大，更復雜，失去自我管理的信心，而每個測試人員也將要花費大量精力和時間投入到內部溝通，和可能因為內部缺乏一致而導致的更加頻繁的反復溝通中。

每名敏捷的 測試人員需要和其他敏捷團隊成員保持頻繁而必要的溝通以保證對目標，需求、設計的充分正確的理解，對需求變化能夠迅速的做出反應。另外，還需要與職能隊伍 中的其他測試成員保持一致性。如此一來，溝通代價激增了，它將占到測試人員的工作中的較大比例。而這種內部溝通、協調，卻不能定義為敏捷的 Backlog 項目來計入團隊整體的工作輸出。因此，整體的測試效率并不一定隨著人力資源的投入而遞增。非但沒有實現敏捷原則，而恐怕因為團隊的組織結構變得更加龐雜。 所謂的“自我管理、自我發展”的團隊只能因而依靠傳統的管理和規劃了。筆者認為，除了因為特殊階段，特殊時期，敏捷團隊需要“聚合”更多資源來一并解決存 在的高優先級的體力型問題外，敏捷的團隊應該盡量保持著較小的“尺寸”。

果真項目投 入了很多的人力資源，無論設計還是實現、測試團隊擁有較大的人數，那么我們應該考慮將這樣的團隊可以分得更小些，工作量也相應分得更精細些，直至接近我們 建議的最佳組合。至少我們認為要做好敏捷測試，就要確保敏捷團隊中的每一個職能擁有足夠清晰的職責范圍和一定程度下自由空間和在這個空間內的充分授權。因 此，但從人數和職能構成上，敏捷團隊的構成一定是不可忽略的重點。

正像我們前 面提到的，確認軟件開發過程的正確性也尤為重要，因此作為敏捷的測試人員，更要了解敏捷的過程，比如說，測試人員需要幫助 UCD 和開發人員確定需求的可行性，測試人員要督促開發人員及時發布 build，以保障迭代結果最終能夠在通過足夠的測試后成功發布等。在 build 發布后，測試人員要首先驗證當前迭代的任務是否已經完成，其次才是驗證產品功能的正確性。也為了能夠在日后重復性和體力型勞動中解放出寶貴的時間去覆蓋測 試更加緊要的內容，如可用性，全球化等，測試人員需要自動化一部分測試，創新的、靈活的工作。

敏捷團隊是自我管理的團隊，高度協作的團隊，質量目標即是測試團隊也是整個開發團隊追求的目標，因此開發團隊應將做好單元測試，設計團隊將幫助測試團隊設計好測試用例作為計劃內的一項工作。這里我們推廣、建議開發人員采用、普及測試驅動開發模式。

測試驅動開發

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

在單元測試 活動中，測試人員也被鼓勵參與到單元測試的設計中來，不但可以幫助開發人員構思出更多的單元測試用例來擴大單元測試的覆蓋率，還可通過學習如何使用單元測 試，如何復用單元測試用例到回歸測試和功能測試，以達到最大化利用有效的資源（如下圖）和節約成本的作用。同時，在回歸測試和用戶接收測試（User Acceptance Test）中如能將單元測試腳本有機的關聯起來，并自動化其執行，更能夠進一步提高測試的成效并降低測試成本。

單元測試腳本因隨需求、設計的變化隨時更新。需要開發人員站在全局的立場，開發始終堅持先修改測試腳本，再修改產品原代碼。此時，也建議測試人員參與單元測試腳本的改進，幫助開發人員合理的變更單元測試腳本，同時著手修改測試計劃和測試策略。

靜態測試

一個好的測 試人員能夠第一時間找到需求分析、設計中的模棱兩可，遺漏，錯誤的地方，能夠促進團隊前期工作的高效完成，將很大程度降低將來產品的質量缺陷的數量，積極 影響了敏捷開發的最終輸出。這部分工作是測試團隊，開發、設計團隊最默契合作的階段，交流非常頻繁，正是通過積極的溝通和及時的修正與團隊目標“誤差”使 得團隊更加明確其方向，更有凝聚力和也得以發揮了團隊的最佳戰斗力。在筆者的項目經歷中，往往這個階段會需要一個迭代周期 1/4 左右的時間。這同時也說明了靜態測試在敏捷測試類型中的重要性。

在敏捷開發過程的靜態測試即項目迭代開發前期測試人員的最主要工作。值得再次強調的是，在這段時期測試人員的工作重心是認真了解需求和用例設計，并針對設計的可行性，可用性進行驗證，確認設計是對需求的準確實現，最佳實現。

測試人員應 該領導團隊幫助明確出用例更多的細節。比如，在一次設計用例討論中，設計者提出“我需要一個 Overlayer”。那么測試人員應該要問：“如何打開這樣一個 Overlayer，如何關閉？”“這個 Overlayer 需要多大平面尺寸，是否支持調整，是否支持對屏幕大小的自動適應”，“Overlayer 的打開和關閉是否需要有動態漸變的效果？”，“Overlayer 的是否需要滾動條？”，等等。

這個過程能夠幫助團隊發現早期的設計缺陷，通過發現問題，并定制新的設計方案，團隊也通過這個過程，更好的了解了測試的重要性，也摒除了可能存在的對需求的種種“假設”，因而更加明確了團隊的目標和方向。這是個非常關鍵的過程。尤其是對測試人員而言，任何“假設“都是有害的，所以一定需要把不清楚和模棱兩可的問題從一開始就理清楚。

轉載于:https://www.cnblogs.com/zyp1/p/5765472.html

總結

以上是生活随笔為你收集整理的敏捷的最佳实践-2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。