專案的敏捷開發與敏捷測試

敏捷開發：1. 敏捷型方法是「適配性」而非「預設性」。

重型方法試圖對乙個軟體開發專案在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。

其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。2.敏捷型方法是「面向人」的 (people-oriented) 而非「面向過程」的 (process-oriented)。

它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。

我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心。

敏捷開發其實借鑑了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有多。

改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。

「在敏捷軟體開發的過程中，我們每兩周都會得到乙個可以工作的軟體，」fowler介紹，「這種非常短的迴圈，使終端客戶可以及時、快速地看到他們花錢構建的軟體是乙個什麼樣的結果。」

敏捷開發的理念：

· 個體和互動勝過過程和工具

· 可以工作的軟體勝過面面俱到的文件

· 客戶合作勝過合同談判

· 響應變化勝過遵循計畫

並提出了以下遵循的原則：

· 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。

· 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

· 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

· 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。

· 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。

· 在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。

· 工作的軟體是首要的進度度量標準。

· 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。

· 不斷地關注優秀的技能和好的設計會增強敏捷能力。

· 簡單是最根本的。

· 最好的構架、需求和設計出於自組織團隊。

· 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

敏捷測試流程總結：

在敏捷方法中，xp方法強調測試在整個專案開發過程中的重要性。針對敏捷開發方法的敏捷測試不同於以往針對傳統開發模式的測試,在敏捷團隊中,測試是整個專案組的「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。測試員為專案組提供豐富的資訊，使得專案組基於這些可靠的資訊作出正確的決定。

不僅是測試員要保證質量，而是整個專案組的每乙個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標,共同為達到專案的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態調整測試計畫、測試的執行。

並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計畫。

根據公司專案目前採用的敏捷開發模式，相應的敏捷測試建議採用以下流程：

1. 驗證需求和設計

需求和設計具體來說一般包括：（1）由專案經理根據需求文字而編寫的功能設計文字（functional design specification）；（2）由開發人員根據功能文字而編寫的實施設計文字（implementation design specification）包括(architecture document, project scope statement, use case )。作為測試人員，審核重點是檢查文字對使用者需求定義的完整性、嚴密性和功能設計的可測性.

在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一使用者積極參與專案和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。

要盡早的開始測試，不要等待到功能完全做好才開始。

產出物:測試需要提交評審結果文件,可以讓測試更多的參與db design,框架的評審中來

2. 測試計畫，測試用例

2.1 編寫計畫、測試用例

在敏捷開發的過程中由於是根據每個user story來估算時間的。開發人員將對本次迭代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先順序。

好處：客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先順序。

問題：在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。

分析：由於版本更新很快，任務的時間都是以小時來進行估算的。開發人員一般會忽略掉開發以外的時間，比如開發中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。

舉個例子：

開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。於是開發人員給的估算時間是2天。

開發階段實際的花費時間如下，每天花費開例會的時間。在例會中專案的其他成員需要技術上的支援。於是髮費了3個小時進行幫助。

在開發的過程中遇到了一些沒有預見到的問題，結果解決問題花費了4個小時。（也許更多）。需要處理一些公司突發性的事務等等。

所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本 xp相關的書上寫到，在時間估算上最好的時間是編碼時間的2－3倍。聽起來很嚇人，但是實際的過程中，的確需要這麼多的時間。

測試人員根據已審核通過的需求和設計編制測試計畫，設計測試用例。在前面提到的三種文字中，功能設計文字是主要依據。測試的這兩個文字也要被專案經理和開發人員審核。

2.2 測試用例的審核

為使開發人員能參與到test case的review中來，以保證tc的質量和可行性，確保測試工作的順利進行，讓開發人員迅速地了解測試的重點並給出相應的意見和建議，測試人員在出 tc的同時，應出乙份tc_matrix（test case跟蹤矩陣），其中註明tc已覆蓋了哪些features，具體每個features對應的tc的編號，這樣在測試經理和pm對tc進行 review的時候，能夠對tc的覆蓋率一目了然，對覆蓋率不足（如某個重點feature的test case不夠）的地方能夠及時給出意見。

另外，在每天早上的morning meeting上，測試人員可以簡潔地講述一下當天測試的重點部分，以及專案中存在哪些嚴重的bug，讓開發人員了解當天測試的重點是什麼，怎樣進行測試，並提出自己的意見和建議。這樣做加強了開發與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。

在迭代後期測試要抽時間更新test case。

3. 實施執行測試

在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發人員來完成的，接收測試是由客戶代表來完成。

由於我們客戶無法在現場，我們採取了，開發人員做單元測試，測試人員做驗證測試，最後由客戶進行接收測試。在每個版本發布給客戶之前必須由測試人員進行測試，發布版本之後由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下乙個發布完成。

· 單元測試

在daily build版本給測試前，開發首先要做單元測試，提前告知軟體中的薄弱環節，幫助測試人員調整測試重點。unit test

做單元測試的好處是可以提高版本質量，減輕測試的工作量，減少淺層次的bug的發生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面。

· 驗證測試

測試人員的驗證測試從總體上說就是將上一步設計的測試用例按計畫付諸實施的過程。這一階段的測試必須在周密的計畫下進行。這種計畫性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模組的依賴關係，按照專案的總體計畫共同推進。

從測試的過程來看，測試執行的一開始可以是針對部分功能的，之後可以逐步擴充套件。接著開始採用迭代的過程完成測試任務，即將測試任務劃分為多個週期，一開始可以做些關鍵的功能性測試，可以對**中的可復用部分（元件，構件）做完整的測試。接著的迭代週期可以做邊緣化的功能測試和其他測試，最後的幾個迭代應該用於回歸測試，和關鍵的效能和穩定性測試。

3.1 每日提供bug趨勢

為方便衡量專案的進度，測試可每天測試完畢後提供測試的bug趨勢，即將每天新生成的bug數和每天被解決的bug數標成乙個趨勢圖表。一般在專案的開始階段新生bug數曲線會呈上公升趨勢，到專案中後期被解決bug數曲線會趨於上公升，而新生bug數曲線應下降，到專案最後，兩條曲線都趨向於零。 pm會持續觀察這張圖表，確保專案健康發展，同時通過分析**專案bug，對於每個版本的bug，開發都應該想想為什麼會出現這樣的問題，特別是很低階的 bug，對於同類的bug，是否可以避免。

測試需要考慮:探索性測試用例的編寫

3.2 測試用例的維護

在執行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對於當初測試設計不周全的領域，二是對於外部的bug（比如從beta客戶報告來的），沒有被現有測試用例所覆蓋。

當產品的功能設計出現更改時（敏捷專案中功能設計的更改頻繁），所涉及的測試用例也要相應地修改，使測試用例保持和現有的功能需求同步。

3.3 根據專案不斷補充common sense

在專案進行過程中，測試人員需要不斷積累經驗，不斷補充、完善各類目的common sense標準。例如，由ctts專案總結出的common sense for usa標準，在以後的美國專案中要嚴格按照它來執行測試，保證以前出現過的失誤在以後的專案測試中不會再出現。在保證專案質量的同時，不斷積累新的經驗。

專案的敏捷開發與敏捷測試

敏捷開發與敏捷測試

敏捷開發方法

敏捷專案管理

相關推薦