測試已死？我看未必！分享我在華為做敏捷測試的那些流程……

一、 開發和測試的通性困擾？

面對複雜性（客戶）：不斷地修改計劃、不斷地增加預算、低劣的產品質量……

面對複雜性（專案組成員）：經常加班到深夜、提交的產品不合格……

二、敏捷開發中的敏捷測試目的：

敏捷宣言

個體和互動比過程和工具更有價值；能工作的軟體比全面的文件更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計劃更有價值。其核心是:以人為本,發揮人的主觀能動性.

三、傳統測試和華為敏捷測試區分：

3.1 、傳統的測試

1.守門員:質量保證者，阻止那些不可靠的、無效的、充滿 BUG 的版本釋出。

2.資訊提供者:提供大量積極的、關於專案開發的狀態的資訊。告訴大家哪些功能正常工作、哪些功能不能正常工作、哪些 BUG 必須處理。

3.2 、 華為敏捷測試

測試和開發的角色界線變得模糊。有些人主要做測試工作，有些人主要做開發工作，但是在快速推進的過程中，所有人都會被號召起來測試或支援測試的工作。更多職責:幫助開發人員理解需求,儘早確定測試規範。

3.3 、 敏捷測試中測試人員扮演的角色

1.測試是專案的“車頭燈”，它告訴大家現在到哪了，正在往哪個方向走。

2.測試為專案組提供資訊，使得專案組基於可靠的資訊作出正確的決定。

3.測試人員不作出專案釋出的決定。

4.測試員不保證質量，整個專案組對質量負責。

5.測試不是抓蟲子的遊戲，它的目的不是糾纏在錯誤中，而是幫助找到目標。

四 、 敏捷測試用例的設計和評審要素：

4.1 、 基於需求的用例場景來設計測試用例：

1.基於需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟體的根本，驗證對需求的覆蓋是軟體測試的根本目的。

2.把測試用例當成“活”的文件,因為需求是“活”的、善變的。因此在設計測試用例方面應該符合敏捷的“及時響應變更比遵循計劃更有價值”這一原則。

3.測試用例的設計不是一個階段，測試用例的設計也需要迭代，在軟體開發的不同的階段都要回來重新審視和完善測試用例。

4.2 、 敏捷測試用例設計原則

通常我們所看到的測試用例的設計是其中一項。

測試用例可以寫得很簡單，也可以寫得很複雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。而最複雜的測試用例就像銀行取款機系統中工作指令系統介面一樣，會指定輸入的每項資料，期待的結果及檢驗的方法，具體到介面元素的操作步驟，指定測試的方法和工具等等。

測試用例寫得過於複雜或過於詳細，會帶來兩個問題：一個是效率問題，一個是維護成本問題。另外，測試用例設計得過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。

測試用例寫得過於簡單，則可能失去了測試用例的意義。過於簡單的測試用例設計其實並沒有進行“設計”，只是把需要測試的功能模組記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，並把對軟體系統的測試方法的思路記錄下來，以便指導將來的測試。

大多數測試團隊編寫的測試用例的粒度介於兩者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。我們應該根據專案的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。

軟體是開發人員需要去努力實現敏捷化的物件，而測試用例則是測試人員需要去努力實現敏捷化的物件。要想在測試用例的設計方面應用“能工作的軟體比全面的文件更有價值”這一敏捷原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。

4.3 、 敏捷中測試用例評審：

1．同行評審是最敏捷的檢查測試用例的方式，它主要強調測試用例設計者之間的思想碰撞、互補，透過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是儘可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在侷限性。因此需要一起設計測試用例，從而體現敏捷的“個體和互動比過程和工具更有價值”。

2．除了同行評審，還應該儘量引入使用者參與到測試用例的設計中來，讓他們參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。

備註：這裡顧客的含義比較廣泛，關鍵在於你怎樣定義測試，如果測試是對產品的批判，則顧客應該指終端使用者或顧客代表（在內部可以是市場人員或領域專家）；如果測試是指對開發提供幫助和支援，那麼顧客顯然就是程式設計師了。

五、 華為常用敏捷的測試方法和測試流程：

1．進行敏捷測試主要分以下幾個步驟：

敏捷測試採用的功能測試方法是我們常用的基本的測試方法，例如：

等價類劃分、

邊界值分析法、

錯誤推測法……

2．敏捷測試和傳統測試不同的是：

需要高度的迭代工作、

頻繁得到客戶的反饋，

需要動態調整測試計劃、

測試的執行。

3．敏捷測試過程中效能測試方法和考慮：

效能測試的方法？

效能測試、負載測試、壓力測試、配置測試、併發測試

效能測試：透過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能是否滿足生產效能要求。

負載測試：透過在被測系統上不斷增加壓力，直到效能指標，例如“響應時間”超過預定指標或者某種資料使用已經達到飽和狀態。

配置測試：透過對被測系統的軟/硬 件環境的調整，瞭解各種不同環境對系統效能影響的程度，從而找到系統各項資源的最優分配原則。

壓力測試：測試系統在一定的飽和狀態下，例如 CPU、記憶體等在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。

併發測試：透過模擬使用者的併發訪問，測試多使用者併發訪問同一個應用、同一個模組或者資料記錄時是否存在死鎖或者其他效能問題。

六 、 與您共勉

最後送大家一句話，兵無常勢，水無常形，能因敵變化而取勝者謂之神，相信在測試的過程程中只有找對了方法，不管是傳統的測試還是現當今國外比較流程的敏捷測試，只要應用得當就是好的測試。