我在華爲作敏捷測試的那些流程

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

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

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

　　 

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

　　敏捷宣言

　　個體和交互比過程和工具更有價值；能 工做的軟件比全面的文檔更有價值；顧客的協做比合同談判更有價值；及時響應變動比遵循計劃更有價值。

　　其核心是:以人爲本,發揮人的主觀能動性.

　　 3、傳統測試和華爲敏捷測試區分：

　　3.一、傳統的測試

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

　　2.信息提供者:提供大量積極的、關於項目開發的狀態的信息。告訴你們哪些功能正常工做、哪些功能不能正常工做、哪些BUG必須處理。

　 　3.二、華爲敏捷測試

　　測試和開發的角色界線變得模糊。有些人主要作測試工做，有些人主要作開發工做，可是在快速推動的過程當中，全部人都會被號召起來測試或支持測試的工做。

　　更多職責:幫助開發人員理解需求,儘早肯定測試規範。

　 　3.三、敏捷測試中測試人員扮演的角色

　　1.測試是項目的"車頭燈"，它告訴你們如今到哪了，正在往哪一個方向走。

　　2.測試爲項目組提供信息，使得項目組基於可靠的信息做出正確的決定。

　　3.測試人員不做出項目發佈的決定。

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

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

　   ... ...

 

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

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

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

　　2.把測試用例當成"活"的文檔,由於需求是"活"的、善變的。所以在設計測試用例方面應該符合敏捷的"及時響應變動比遵循計劃更有價值"這一原則。

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

　　 4.二、敏捷測試用例設計原則

　　一般咱們所看到的測試用例的設計是其中一項。

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

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

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

 

 

轉載：http://www.51testing.com/html/47/n-3650047.html