最近一段時間，「敏捷測試」成為了乙個熱門詞彙，我的朋友、包括學生也會來問我，什麼是敏捷測試？究其原因大概是因為敏捷開發這一概念的火熱。看了朱老師這本書的試讀章節，讓我也對敏捷測試有了更深一步的了解，那麼我也順著試讀中的內容，以我第一次開展的「敏捷測試」做乙個簡單闡述。
第一次開展敏捷測試是在我剛進入測試領域不久，在乙個小型公司的小型專案組中應用了「敏捷」這樣一種思維。那首先我要說這次的敏捷嘗試是徹底失敗的，而且我相信像我們這樣失敗的例子絕不僅僅是個例，各位看官可以繼續向下了解。當時的團隊共有六個人，乙個po，負責user story的整理，sprint的制定；乙個pm，負責整個sprint的計畫和任務分配；三名開發人員以及我。然而最終的形態是什麼呢？變成了乙個類似敏捷的瀑布式流程；由po作為需求人員，整理需求，pm進行任務的分配，開發人員只管悶聲寫**，而我，則作為最後乙個測試環節，在要「持續的交付給客戶」前進行該版本的驗收測試以及上一版的回歸測試。唯一保留下來的就是敏捷裡的「每日站立會議」，以及沒有任何文件記錄的傳統。
這樣乙個「偽敏捷」的流程裡是否有真實存在的意義？我想答案幾乎是no，反而是無休止的會議、沒有文件記錄但又逐漸缺少交流讓整個流程中走了更多彎路。後來當我真正完成了乙個敏捷流程後，回過頭來總結這次失敗的歷程，發現了大概如下幾點：
一、就像朱少民老師在書中提到的，敏捷測試要強調「自動化測試」，沒有自動化，又何來敏捷，怎樣持續的交付讓客戶滿意的軟體？擁抱需求變化，也是要依靠完善的自動化測試包括單元測試，否則所謂擁抱需求變化，只是空談。
二、敏捷強調交流，因為很少有工作文件產出。而往往在最初進行敏捷的時候，熱情猶在，交流更頻繁些，而逐漸的，大家感覺不到交流的意義，所以敏捷便成了空談。
三、測試驅動開發的思想。換言之就是單元測試是一切的基礎，而不管開發人員也好，測試人員也好，在我們專案當時都不具備或者不願意去做「額外的」單元測試工作。結果是什麼？每次提測就出現很多問題，修復這些問題佔據了大量的時間。「敏捷」又從何而來？
除了提到這三點，其實還有很多問題存在，在這兒我只想舉這個例子告訴所以同行，無論是po、pm、開發還是測試，都要記得「敏捷」不是掛在口頭上，也不是保持幾個會議什麼的就可以搞定的，而是一種思維觀念。敏捷是大勢所趨，但是也需要充分的條件才能開展。
也談軟體測試地位
如果從理論，也就是講道理的角度去說服他人要重視測試 提高測試的地位，這純屬於扯淡的行徑，不要對這種做法抱希望。理由 1 測試本身不創造直接利潤。當然除了銷售直接創造利潤外，其它崗位都是消費崗。2 個人理解測試本身屬於支撐 服務角色 測試階段起主導作用 相對於開發人員直接 創造 了軟體來講，測試是默默...
全程軟體測試 測試型別
1.單元測試 對軟體基本組成單元進行的測試，其測試物件是軟體設計的最小單位 模組或元件，也可以是類或函式。2.整合測試 將已通過測試的單元按設計要求組合起來再進行的測試，以檢查這些單元之間的介面是否存在問題。整合測試一般是乙個逐漸加入單元進行測試的持續過程，直至所有單元被組合在一起，成功地構成完成的...
軟體測試試題
應用題 1.有乙個模組，有兩個輸入x,y 取值範圍分別是 1,1000 和 2,89 模組功能是判斷x和 y的大小，請劃分出它的等價類。2.nextdate是乙個有三個整數變數 y,m,d 的函式，分別表示年份 月份和日期的值。函式返回的是輸入日期的第二天的年份 月份和日期的值，其中 1 y 210...