敏捷企業中的性能測試如何實現?

　　在你所在的企業中，你是那個正在做或者是已經做了段時間的敏捷的人?你是否為性能測試所困擾?是否嘗試讓如何讓性能測試在這個新文化中運作?如果是這樣的話，這篇文章就是為你而寫。

　　在生命周期中敏捷團隊執行性能測試

　　大多數企業已經以某種形式在相對的敏捷中進行性能測試。我之所以說“相對敏捷”是因為企業傾向于將性能測試看作是“不肯定的、易變化的”活動，由個人或者團隊組織，對于開發團隊來說既是完全隔離的，也是松捆綁的。當這個團隊使用非敏捷的SDLC開發應用，這種情況就會傾向于不理想的狀態，但是或多或少還是有用的，因為每個人都接納了，盡管性能測試由一人管理，或者甚至是兩個人，在開發之后構建。

　　然而，性能測試本身就是敏捷的，因為其持續不斷的迭代反饋環。實踐證明，每一次性能測試結果都會是三種狀態之一，沒有新消息、提出新問題或者是下一次性能活動通過這些提前測試的導致的狀態完全確定，從而識別新的風險。圖一就是一個簡單，但是很有用的性能測試循環描述。

　　圖一：性能測試周期

　　我通常將這幅圖描述為性能測試活動、復雜的未知性和金絲估計的循環表示。

　　將性能測試集成到敏捷開發中并不容易

　　為了理解為什么集成現有的敏捷性能測試實踐到敏捷開發周期中并不容易，我們首先來看一下一個普通敏捷軟件開發模型。如圖二所示：

　　圖二：普通敏捷開發周期可視化描述

　　我一般將這幅圖描述為核心敏捷活動重復周期。

　　相當簡單不是嗎?但是當企業試圖集成現有的性能測試模型到敏捷開發周期的時候，事情就復雜了，敏捷開發周期是在最初沒有進行性能測試的時候確立的。如圖三所示。

　　圖三：集成性能測試到現有的敏捷開發模型中

　　如果在看過圖三之后，你認為“太難了!”那咱們得觀點一致。很明顯的結論就是在實現敏捷開發時集成性能測試要更有效率。不行的是，這一點只對于哪些計劃但還沒有開始過度到敏捷方法的企業有價值。

　　三種方法實現敏捷中性能測試

　　對于已經鐘情于敏捷開發，但還沒有完全集成性能測試的企業，我介紹三種方法，這些方法我都親眼見證了不同程度的成功： on demand(按需)、on retainer(聘用)和full immersion(全部投入)。

　　On demand(按需)

　　也被看做是“卓越中心”，這個模型的功能等價于將其外包給一個內部組織。這并不是一個過渡敏捷的模型，但是這個是大多數企業試圖一開始集成其性能測試到敏捷開發周期中，因為性能測試已經是敏捷轉換開始之前的“on demand”模型了。

　　對于“On demand”模型的性能測試，要和敏捷開發周期共同運作，有幾處需要處理的不同于在非敏捷開發工作。尤其是：

　　定期利用“On demand”服務，不僅僅是為產品發布候選版構建。

　　性能目標、目的、宗旨或是預算必須成為每一個用戶故事的標準部分。

　　開發者必須對測試單元層、組件層負責。

　　全職的團隊成員必須管理性能相關工作，包括這些沒有明確提到的部分。

　　“On demand”在性能非常重要的情況下可能并不充分，比如開發者沒有進行性能測試并在他們的水平不斷調試，或者當非全職團隊成員負責協調、支撐以及管理性能相關的任務。

　　On retainer(聘用)

　　“On retainer”模型通常是企業所使用的一種“On demand”和“full immersion”之間的過渡模型。因為企業沒有足夠的性能測試人員、性能測試環境或者是性能測試工具來支持“full immersion”模型。

　　在這個模型中，每一個開發項目都分配給具體的性能測試人員，但是性能測試人員會被分配給兩個或者更多的開發項目。盡管這個模型為每一個項目帶來了更多的性能測試專業意見以及為每個性能測試人員帶來了更多的項目級知識，但是性能測試人員缺乏與團隊的完全整合。結果導致性能測試人員傾向于獨立工作，但是提供了周期性地提供建議和指導。為了讓這個模型運作并提供比“on- demand”更多的增加價值。

原文轉自：http://www.uml.org.cn/Test/201308222.asp