PAGEPAGE1敏捷測試的實踐摘要：在敏捷測試流程中,參與單元測試,關注持續迭代的新功能,針對這些新功能進行足夠的驗收測試,而對原有功能的回歸測試則依賴于自動化測試.由于敏捷方法中迭代周期短,測試人員盡早開始測試,包括及時對需求、開發設計的評審,更重要的是能夠及時、持續的對軟件產品質量進行反饋.關鍵詞：敏捷測試;敏捷開發;開發周期;單元測試1引言之前跟眾人一樣對敏捷開發比較熟悉，覺得新鮮而有效率。剛看到老師給的題目時才知道敏捷測試這個概念，自己一直局限于測試方法的學習，并沒有系統并從大體框架去學習和了解測試這個行業。在學習敏捷測試過程中了解到這樣幾個概念：TDD（測試驅動開發TestDrivenDevelopment）、ATDD(驗收測試驅動開發AcceptanceTestDrivenDevelopment)、UTDD(單元驅動測試UnitTestDrivenDevelopment)以及精益方法，并由此開始了解到軟件測試和其他知識領域的交叉處。敏捷測試進入國內研究領域還是一個新生力，查找到的國內文獻也是極其有限的，在這里也只是發表自己淺陋的理解。通過之前的對軟件項目案例的學習，我比較欣賞的是軟件生命周期中的螺旋式模型，那敏捷是先于開發，也就跟傳統的測試有本質的區別。傳統的測試是先寫測試計劃，此后的測試過程分布在螺旋式模型中的每一次完善的循環中，而敏捷測試則是在開發前寫好了用例，根據用例再去開發系統，可以減少很多錯誤，但這也就意味著開發人員的主導作用更明顯。與傳統的測試不同，敏捷軟件測試并不是一個獨立的過程，相反，它與整個敏捷開發中的其他活動交織在一起，處處都能看到它的影子。敏捷測試接納了敏捷的核心價值觀（溝通，簡單，反饋，勇氣，尊重），在敏捷軟件開發過程中開展的測試就可以被稱作是敏捷軟件測試。因此，敏捷軟件測試并不是一個與敏捷軟件開發同一層次的劃分，而是敏捷軟件開發中的一部分。2敏捷測試背景2.1敏捷測試敏捷測試是適應敏捷方法而采用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有不同的側重，例如減少測試計劃、測試用例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟件產品質量進行反饋。簡單地說，敏捷測試就是持續地對軟件質量問題進行及時地反饋，如圖1所示。圖1敏捷測試定義的形象描述2.2敏捷測試的核心首先要從整個項目全局考慮，及早發現需要更改設計的問題。其實這個測試更多的是觀察與思考，而是否能發現問題就要看開發人員對需求掌握是否透徹，對整個項目是否有一個全局的把握，是否從最終用戶角度去考慮問題，是否以實現客戶的商業價值為目標。然后在最短時間內完成所有功能和業務邏輯的測試，最好是每人分配不同的功能和業務邏輯進行測試，這樣就可以在最短時間內及時將優先級較高的缺陷及時反饋給開發人員。最后在開發人員忙于修改那些優先級較高，難度較大，比較耗時的缺陷的同時測試人員可以有充分的時間來對這一迭代進行較細致的測試，發現功能和業務邏輯中不易察覺的問題，次要功能問題、驗證、界面等。那么，作為一個測試工程師在測試中使用敏捷的思想進行測試，并且需要敏捷測試中需要保證其工作符合相應的準則：①獲取和明確用戶的質量期望；②建立合適的系統測試、用戶驗收測試質量標準；③推進單元測試、開發測試；④建立持續構建框架；⑤持續改進自動化測試；⑥保持質量度量結果的可見性。2.3敏捷測試流程優化在敏捷方法中，需求變化比較快、產品開發周期很短，我們目前采用四周時間，也就是每個月發布一個新版本。開發周期短，功能不斷累加，給軟件測試帶來很大的挑戰，軟件測試流程要做相應的調整。例如，我們原有的測試規范明確規定，首先要建立項目的主測試計劃書，然后再建立每個功能任務的測試計劃書，測試計劃書有嚴格的模板，而且需要和產品經理、開發人員討論，并和測試團隊其他人員（包括測試經理）討論，最終得到大家的認可和簽字才能通過，僅測試計劃經過“起草、評審和簽發”一個完整的周期就需要一個月。在敏捷方法中，不再要求寫幾十頁的測試計劃書，而是在每個迭代周期，寫出一頁紙的測試計劃，將測試要點（包括策略、特定方法、重點范圍等）列出來就可以了。在原有測試規范中，要求先用Excel寫出測試用例，然后進行討論、評審，評審通過以后再導入測試用例庫（在線管理系統）中。在敏捷測試中，可能不需要測試用例，而是針對UseCase或UserStory直接進行驗證，并進行探索性測試。而節約出來的時間，用于開發原有功能的自動化測試腳本，為回歸測試服務。自動化測試腳本將代替測試用例，成為軟件組織的財富。原有測試規范還要求進行兩輪回歸測試，在敏捷測試中，只能進行一輪回歸測試。綜合這些考慮，敏捷測試的流程簡單有效，如圖2所示。圖2敏捷測試流程簡要圖在敏捷測試流程中，如前所述，測試是一個持續的質量反饋過程，測試中發現的問題要及時反饋給產品經理和開發人員，而且某些關鍵方面也要得到我們足夠的關注，主要有：測試人員不僅要全程參與需求、產品功能設計等討論，而且要面對面地、充分地討論（包括帶語言、視頻的即時通訊），僅僅通過郵件是不夠的。參與代碼復審（CodeReview），并適當輔助開發人員進行單元測試。通用電子商務平臺測試用例的設計及執行（實踐部分）1.負責的任務和執行在本次測試過程中，由于之前有功能測試的經驗，所以被安排設計測試用例并執行。但在實際的工作中僅僅按照等價類劃分和判斷表驅動法這樣的分類方法去設計用例，并相應的刪除冗余。首先，熟悉了解需要測試的兩個模塊：購買模塊以及注冊模塊；然后根據系統設計文檔列出系統的待測功能點。第一部分是購買模塊的功能點，這部分主要是單元測試，除了購物車部分，其他部分均不需要輸入值，依次點擊鏈接查看功能是否實現。購物車物品數量部分本應該只存在正數，在我們輸入不合法字符之后，系統有提醒輸入異常，但當輸入的為負數值時，系統卻在結算部分顯示了相應的負數金額，這在實際操作中是不合理的，并且很有修改的必要。結算部分就算購物車沒有商品，它依然會跳轉至結算頁面，而按照需求和設計文檔，此部分應該提示購物車為空。購買流程測試：expectedresultpracticeresultcase01點擊商品，查看信息鏈接到商品詳情頁面鏈接失敗failcase02多次點擊購買，刷新鏈接正常，數據添加成功鏈接失敗，數據無法添加failcase03點擊購物車鏈接鏈接正常鏈接正常passcase04刪除購物車物品鏈接正常，數據刪除成功鏈接正常，數據刪除成功passcase05變更數量1180180passcase06100018000180000passcase07-1提醒輸入異常-180failcase08-100提醒輸入異常-18000failcase09a%提醒輸入異常無反饋failcase10商品金額總計只存在合理的正數金額值數量為負，金額總計也為負failcase11恢復記錄恢復恢復passcase12繼續挑選商品鏈接鏈接正常鏈接正常passcase13無商品，測試結算功能提示購物車為空進行結算fail第二部分是注冊模塊測試，因為系統需要輸入值的模塊并不多，所以特意選取了輸入值要求比較多的注冊模塊。在設計測試用例的過程中，由于需求和系統設計文檔等資料不詳細，所以在郵箱這部分的測試比較瑣碎，甚至為了測試用例覆蓋比較完整，特意去研究了郵箱的校驗機制varpattern=/\b(^['_A-Za-z0-9-]+(\.['_A-Za-z0-9-]+)*@([A-Za-z0-9-])+(\.[A-Za-z0-9-]+)*((\.[A-Za-z0-9]{2,})|(\.[A-Za-z0-9]{2,}\.[A-Za-z0-9]{2,}))$)\b/;這部分的測試用例主要是針對郵箱校驗的每一部分，但僅僅根據這個還是不夠的，因為這部分校驗機制也不一定完整并且合理，所以主要是校驗機制和大型郵箱網站的校驗機制想綜合進行測試用例的設計。此外根據之前的測試經驗進行了冗余測試用例的刪除，減少了測試用例的數量，使得執行效率變高。另外一個問題比較集中的是昵稱部分，在測試到此部分時，發現校驗機制做的餅不完善，無論輸入任何不合法的字符或者超過正常昵稱長度的昵稱都可以通過驗證，這在實際的項目中是一個比較嚴重的問題。在實際的測試中我們第一部分進行的是靜態測試，正常的代碼走查需要4個人左右，主要人員包括：總協調人1名、參與項目的程序員1名、設計人員1名、測試專家1名。而我們的項目中由于自己之前的經驗，所以充當了總協調人和測試專家的角色，當然除了程序的設計者和程序員，我們還安排有其他組員一起發現代碼設計或者采用框架上的不足。前期的代碼走查也為后期我做注冊部分的測試用例設計提供了很大的幫助，我不僅僅了解其他郵箱網站的輸入合理性，也了解本系統的校驗機制以及郵箱校驗的不合理之處、昵稱輸入的缺陷等問題。2.收獲和體會之前在公司做測試時主要的是執行測試用例以及做回歸測試，有試著寫過測試用例，但效果不理想，后期得益于組長的指導，對根據設計文檔寫測試用例有了一定的了解，但還不熟練，這一次在小組中由于自己的組織能力和之前的經驗，雖然不想擔任組長的責任，但仍然做著組長的事情，因為我想知道自己一個人去安排并負責這些到底能不能行。第一次去自己獨立完成測試用例，心里還是比較緊張的，不知道能做到什么樣的程度，首先是回顧之前自己學的測試的知識以及老師課堂教授的內容，然后列出功能點，再依次列出各部分需要執行的條件，一路走下來，對自己還是比較滿意的，因為老師給了這樣一個機會去讓我看到自己是可以做到這些的，雖然在測試用例的設計中還存在很大的問題。3.實踐中的困難一個主要的問題，并且一直放在心上的是，老師課堂講授的正交表排除冗余，當時沒有聽懂，課下也一直因為事情比較多，所以至今未深入學習這部分，但我知道我一定要學會這個知識點，不然自己在測試的路上還會積累更多的疑惑。本次測試過程中本來想實際應用下老師講的減少冗余的方法，但對這些方法掌握有限，所以做不到靈活的運用。讀軟件工程，很多同學是為了做開發，很多人跟我講測試開發人員都會做等這樣輕視測試人員的話，但我從未放棄，我的目標至始至終都是為了成為了一名頂尖的測試大師，我學習各種算法，我努力研究項目管理，各種過去的以及現在流行的測試手段及方法，在年初實習的時候就已經完整了讀完了《theartsof