有一次，當開(kāi)發(fā)人員完成當前Sprint 任務(wù)的代碼之后，測試人員與開(kāi)發(fā)人員、產(chǎn)品經(jīng)理一起來(lái)瀏覽產(chǎn)品、從頭到尾走一邊，產(chǎn)品經(jīng)理發(fā)現了問(wèn)題，認為需要對功能進(jìn)行比較大的修改。這時(shí)開(kāi)發(fā)人員估計需要兩天時(shí)間才能完成代碼，但測試人員反對這樣做，我們本來(lái)只有5天測試時(shí)間，加上這次新做的功能比較多、開(kāi)發(fā)代碼質(zhì)量不高，驗收測試已經(jīng)很緊張。如果再延遲兩天，測試沒(méi)法完成。產(chǎn)品經(jīng)理說(shuō)，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊!
什么是敏捷測試呢?敏捷測試當然不能簡(jiǎn)單地理解測得更快，絕對不是比以前用更少時(shí)間進(jìn)行測試，也不是將測試的范圍縮小了或將質(zhì)量降低來(lái)減少測試任務(wù)。也有人說(shuō)，只有敏捷開(kāi)發(fā)，沒(méi)有敏捷測試。下面我們就要討論一下：
l 究竟什么是敏捷測試?
l 敏捷測試有哪些流程改進(jìn)?
l 測試人員如何面對敏捷測試的挑戰?
l 在敏捷測試中如何制定相應的自動(dòng)化測試策略?
等等各種問(wèn)題。
1. 什么是敏捷測試
假如將過(guò)去傳統的測試流程和方法硬塞入敏捷開(kāi)發(fā)流程中，測試工作可能會(huì )事倍功半，測試人員可能會(huì )天天加班，而不能發(fā)揮應用的作用。敏捷測試應該是適應敏捷方法而采用的新的測試流程、方法和實(shí)踐，對傳統的測試流程有所剪裁，有所不同的側重，例如減少測試計劃、測試用例設計等工作的比重，增加與產(chǎn)品設計人員、開(kāi)發(fā)人員的交流和協(xié)作。在敏捷測試流程中，參與單元測試，關(guān)注持續迭代的新功能，針對這些新功能進(jìn)行足夠的驗收測試，而對原有功能的回歸測試則依賴(lài)于自動(dòng)化測試。由于敏捷方法中迭代周期短，測試人員盡早開(kāi)始測試，包括及時(shí)對需求、開(kāi)發(fā)設計的評審，更重要的是能夠及時(shí)、持續的對軟件產(chǎn)品質(zhì)量進(jìn)行反饋。簡(jiǎn)單地說(shuō)，敏捷測試就是持續地對軟件質(zhì)量問(wèn)題進(jìn)行及時(shí)地反饋，如圖1所示。
圖1 敏捷測試定義的形象描述
2. 敏捷測試流程的優(yōu)化
在敏捷方法中，需求變化比較快、產(chǎn)品開(kāi)發(fā)周期很短，我們目前采用四周時(shí)間，也就是每個(gè)月發(fā)布一個(gè)新版本。開(kāi)發(fā)周期短，功能不斷累加，給軟件測試帶來(lái)很大的挑戰，軟件測試流程要做相應的調整。例如，我們原有的測試規范明確規定，首先要建立項目的主測試計劃書(shū)，然后再建立每個(gè)功能任務(wù)的測試計劃書(shū)，測試計劃書(shū)有嚴格的模板，而且需要和產(chǎn)品經(jīng)理、開(kāi)發(fā)人員討論，并和測試團隊其他人員(包括測試經(jīng)理)討論，最終得到大家的認可和簽字才能通過(guò)，僅測試計劃經(jīng)過(guò)“起草、評審和簽發(fā)”一個(gè)完整的周期就需要一個(gè)月。在敏捷方法中，不再要求寫(xiě)幾十頁(yè)的測試計劃書(shū)，而是在每個(gè)迭代周期，寫(xiě)出一頁(yè)紙的測試計劃，將測試要點(diǎn)(包括策略、特定方法、重點(diǎn)范圍等)列出來(lái)就可以了。
在原有測試規范中，要求先用Excel寫(xiě)出測試用例，然后進(jìn)行討論、評審，評審通過(guò)以后再導入測試用例庫(在線(xiàn)管理系統)中。在敏捷測試中，可能不需要測試用例，而是針對use case 或user story直接進(jìn)行驗證，并進(jìn)行探索性測試。而節約出來(lái)的時(shí)間，用于開(kāi)發(fā)原有功能的自動(dòng)化測試腳本，為回歸測試服務(wù)。自動(dòng)化測試腳本將代替測試用例，成為軟件組織的財富。原有測試規范還要求進(jìn)行兩輪回歸測試，在敏捷測試中，只能進(jìn)行一輪回歸測試。綜合這些考慮，敏捷測試的流程簡(jiǎn)單有效，如下圖2所示。
圖2 敏捷測試流程簡(jiǎn)要圖
在敏捷測試流程中，如前所述，測試是一個(gè)持續的質(zhì)量反饋過(guò)程，測試中發(fā)現的問(wèn)題及時(shí)反饋給產(chǎn)品經(jīng)理和開(kāi)發(fā)人員，而且某些關(guān)鍵方面也要得到我們足夠的關(guān)注，主要有：
l 測試人員不僅要全程參與需求、產(chǎn)品功能設計等討論，而且要面對面地、充分地討論(包括帶語(yǔ)言、視頻的即時(shí)通訊)，僅僅通過(guò)郵件是不夠的。
l 參與代碼復審(code review)，并適當輔助開(kāi)發(fā)人員進(jìn)行單元測試。
l 在流程中增加一個(gè)環(huán)節“產(chǎn)品走查(Product work-through)”——測試人員和產(chǎn)品經(jīng)理、開(kāi)發(fā)人員等在一起，從頭到尾將新功能看一遍，可直觀(guān)、快速地發(fā)現問(wèn)題。
3. 新功能的測試和回歸測試策略
測試任務(wù)簡(jiǎn)單地可分為新功能測試和回歸測試。在敏捷方法中，針對這兩部分的測試建立相應的策略，以提高測試的效率，最大限度地降低質(zhì)量風(fēng)險。新功能測試的策略主要有：
l 不需要測試用例，直接基于用例、基于對需求的理解來(lái)完成新功能的驗證。即使要寫(xiě)測試用例，只要保證各個(gè)功能點(diǎn)被覆蓋，不要過(guò)于詳細(大顆粒度)。
l 持續地進(jìn)行驗證，一旦某塊新代碼完成(code drop), 就開(kāi)始驗證，而不是等到所有代碼完成后才開(kāi)始測試。這也包括參與到單元測試和集成測試中。
l 實(shí)施端到端(end-to-end)的測試，確保完整的業(yè)務(wù)流程的實(shí)現，同時(shí)，也容易發(fā)現業(yè)務(wù)邏輯不夠清晰、不夠合理等各方面的問(wèn)題。
l 閱讀代碼來(lái)發(fā)現問(wèn)題，可以和開(kāi)發(fā)人員工作保持同步，消除測試周期的壓力。
l 基于經(jīng)驗，可以實(shí)施更多的探索性測試、組合交互性(interoperation)測試和用戶(hù)場(chǎng)景(user scenario)測試，更有效地發(fā)現埋藏較深的缺陷。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
