軟體行業發展到今天，可以說是步伐越來越快了。老闆們堅信，時間就是金錢。早一天上線就是早一點佔領市場。於是敏捷開發，敏捷測試的概念流行開來。所謂敏捷，說白了就是沒時間。在敏捷模式下，團隊幾乎沒有時間寫文件。在不斷強調質量之後，研發團隊又被要求一快再快。那麼作為測試人員，如何“敏捷”的完成自己的工作呢？

我們回顧一下常規的測試流程：需求分析--編寫用例--執行用例--迴歸驗收。其中，寫測試用例佔用了我們大量的時間。很多小夥伴都抱怨說，測試時間太緊張啦，根本沒有時間寫測試用例啊！嗯，敏捷模式下我們確實沒有時間寫詳細的測試用例（包含詳細測試條件、步驟）。但是，沒有文件的測試常常讓測試人員感到心裡沒底，甚至邏輯混亂。那麼，我們可以寫測試點。關於測試點，我分享一下我個人的經驗，希望能幫助大家。

曾經習慣用Excel寫測試用例。到了敏捷，就習慣用它來寫測試點。一般來說用一句話概括一個測試點，一句話中包含測試條件以及預期結果。測試時用顏色標記執行結果。

常用句式為：XXX（條件）時，XXXX（預期結果）。以登陸舉例：

測試點1 輸入正確的使用者名稱和密碼時，登陸成功。

測試點2 輸入正確的使用者名稱和錯誤的密碼時，登陸失敗，提示：密碼錯誤。

如此，以足夠指導自己測試。有小夥伴喜歡把測試點寫成思維導圖的形式，清晰明瞭，也不失為一種好的方法。工具形式神馬的看個人習慣，能簡單高效的寫清楚就好。

對於多個平臺相互關聯的測試，我一般習慣把平臺放在一起列在表格裡。如比較常見的是app和pc端關聯，思路一般為同一條件下，app如何顯示，pc端如何顯示。如此用例清晰明瞭，也比較高效。

很多小夥伴的公司用例都是有固定模板的，我這裡想要和大家說明的一點是，固定的模版是比較影響發揮的。為了高效，大家完全可以打破模版，根據待測產品的特點來設計模版，讓用例更清晰明瞭，執行更高效，讓測試人員思路更清晰，這個才是最重要的。

下面說點敏捷下關於測試的兩個小tips

01 關於測試能力

很多小夥伴都有這樣的困惑：空有一身的本領，面試之後就完全用不上了，到了實際工作中還是點點點，完全不能理解企業為什麼花大價錢請了一個點工。

這裡我想給這樣的小夥伴打打氣。其實企業比我們想象得精明的多，在敏捷模式下，企業希望招聘更有能力的測試，來提高效率。會資料庫的測試可以更準確的找到資料問題，懂介面的測試可以更精準的定位問題所在，懂程式碼的測試更容易猜出開發哪裡寫的不對。

在測試初期，當待測模組受上游功能限制時，有能力的測試會自己做測試資料來滿足自己的測試條件，而不是一味的找開發給做資料或乾等全流程做好了再測。我們都知道，測試介入得越早，越能爭取到更多的測試時間，也能更好的幫助團隊保證質量，提高效率。所以，就算是我們做點工，我們也是一個高效的點工。

02 關於迴歸和驗收

測試的最後階段，很多測試人員都曾遇到這樣的情況：提出的bug開發人員已經全部修改完了，現在怎麼點也點不出bug了，但是因為沒有像傳統測試那樣的流程一板一眼的執行測試，總覺得心裡慌慌，生怕漏測而不敢提交。

這個時候，我要對你說的是：兄弟莫慌！其實這個階段從研發團隊的角度來說不會再發現什麼明顯的問題了，那麼我們要做的就是結合具體的業務來進行測試。可以從生產上匯出真實資料進行測試，也可以請教使用系統的客戶進行操作。

總之，想辦法讓自己站在客戶的角度上，儘可能的用客戶真正使用的角度上去操作。此方法對於專業性比較強的軟體來說尤其適用。很多公司會安排準生產環境邀請客戶來做最終的驗收測試。這些都是保證產品質量的方法。

敏捷模式對於開發和測試都比較有壓力。壓縮的工期，不足的人手，龐大的工作量，都是敏捷模式下帶來的問題。除了加班為了提高效率非常重要的一點是，必須對業務非常非常非常熟悉。團隊中的每一個人，無論是研發還是測試，除自己負責的模組外，儘量去多瞭解瞭解其他相關模組的業務。這樣不僅能夠減少漏洞，還能使團隊更緊密的配合，從而提高整個研發團隊的工作效率。

以上是我在版本週期高速迭代的團隊中總結的實戰經驗，希望能幫助一些在敏捷環境中工作的測試小夥伴。