敏捷開發下測試的處境

從傳統模式到敏捷開發，產品或專案的迭代增多，很有可能達到每兩週就會有一個版本。雖然沒有達到每天部署3~4個版本的devops開發模式，但這個時候測試的壓力依然陡然增大，既沒有那麼多的時間寫完善的用例，更做不到每個版本都進行完整的迴歸測試。以前的同事便是在敏捷開發環境下測試某電信運營商相關的金融類app。她經常會遇到即使上線，缺陷也不斷的湧現。有些在測試時已經修復的問題，在生產環境又再次出現；或者之前修復的問題，下次測試又再次出現。測試到最後經常顧此失彼，疲於奔命。這時候，測試如果僅僅只是在部署後才參與到產品或專案中，就會越來越累。測試需要肩負起軟體質量控制的重任。

測試遇到的問題

• 測試不參與產品或專案的需求評審，無法對產品或專案做測試計劃
• 即使參與到需求評審，但是沒有把控需求的可測試性
• 版本構建快，無法把控版本構建
• 測試不瞭解產品或專案內部流程，無法針對性的編寫更有效、更精簡的用例
• 測試人力不足，版本迭代快速，無法進行全面的迴歸測試

理論

Laurent提出一個測試左移和右移的概念:

測試左移，就是指在開發階段之前定義測試。

測試右移，就是直接在生產環境中監控，並且實時獲取使用者反饋。

實現方法

需求到任務到用例的轉化

用例的編寫

敏捷開發，擁抱變化。需求的變化相較於傳統模式越來越多，所以用例也需要跟著及時更新。為了提高編寫用例的效率，使用一個好的用例管理平臺比用Excel等工具要好。不管是給上級看到工作成果也好，還是方便其他測試接手也好，甚至評價分析測試用例覆蓋率都是很有幫助的。

用例從概括到逐步細化

剛有需求但沒有原型設計，或者需求不明確，用例往往是沒法寫具體的。所以這時候可以先概括的寫，甚至就是把需求描述的功能點寫到用例。當設計出來，需求不斷明確後，用例就可以逐步細化。就像畫畫，先勾勒一個輪廓，然後逐漸畫細節。

點-》線-》面

寫用例採用一種點-》線-》面的方式。以新增使用者為例。新增使用者這是一個功能點。點選新增使用者按鈕，輸入使用者資訊，點選確定，提示新增成功。這個功能看似流程走完了，其實不能保證所有資料入庫正確。這時加入一個功能點，查詢使用者。查詢該使用者，在查詢結果看不到剛新增的使用者，可能是新增使用者功能出現了問題。如果查詢到使用者，使用者記錄也顯示正確了，但同樣不能保證所有資料入庫正確了。這時再加入使用者登入功能點。如果登入不了，或者登入後用戶資料顯示與新增時不符，還有可能是新增使用者時出現的問題。所以功能點不是孤立的，應該用業務串起來，這就是線。如果在新增使用者時，設定該使用者是使用者A的好友。則新增使用者成功後，還要登入使用者A，檢視使用者A的好友列表是否有該使用者。這就是在新增使用者後的另一條分支，也可以說是另一條線。每個業務邏輯會產生多條線，線越來越多，就形成了面。

把控版本構建

會用程式碼提交工具，檢視提交程式碼內容，確定測試大致範圍

每次構建或者部署一個測試版本，僅針對修改的部分做測試而不是做迴歸測試。可以通過檢視開發提交記錄確定提交的程式碼是不是都在ReleaseNote上體現了，還是會“夾雜一些私活"，最後沒有測試到。對於SCM是git或者SVN的，可以使用sourcetree這個程式碼檢視提交工具。掌握了程式碼提交工具的使用，可以檢視提交程式碼的內容。可以通過檢視提交的描述判斷這次提交修改的部分是那些功能。大部分後臺服務都是用Java編寫的。而後臺Java服務大都遵循MVC分層。所以程式碼檔案的名字的字尾來判斷這次提交修改的部分是那些功能。

**Util.java 工具類 
**service.java 相對具體的業務邏輯服務層類 
**manager.java 通用業務處理層類 
**controller.java 控制器類，對訪問控制進行轉發
**DAO.java 資料訪問層類
**Model.java model類 
*.properties 配置檔案
*.xml 配置檔案

大部分服務也會遵循分層領域模型。

**DO.java（Data Object）：與資料庫表結構一一對應，通過DAO層向上傳輸資料來源物件。
**DTO.java（Data Transfer Object）：資料傳輸物件，Service和Manager向外傳輸的物件。
**BO.java（Business Object）：業務物件。可以由Service層輸出的封裝業務邏輯的物件。
**VO.java（View Object）：顯示層物件，通常是Web向模板渲染引擎層傳輸的物件。

**表示省略的具體的類名。比如LoginController.java。可以知道這個控制器是用來負責處理登入業務。

持續整合工具的使用

持續整合環境的搭建可能我們不關心，但是使用應該是要了解一下的。如果持續整合環境的構建不是無中斷的，就是說，構建時服務可能會有短暫時間的不可訪問，這取決於測試環境架構或部署指令碼的編寫。比如突然訪問不了測試環境，以為環境出了問題，其實也許只是開發在重新構建測試服務應用。瞭解了CI工具的使用，可以儘快確定是構建導致的訪問不了還是真的出了問題。建議在測試環境由測試人員負責點選構建的工作，一方面可以瞭解構建時整個CI工具做了那些工作，構建時出了問題也可以及時看到。另一方面可以把控版本的構建，在必要的時候進行控制。比如在確定開發確實提交了相關修改時，再做構建，畢竟提交程式碼也是會花費一定時間的，而構建一次會花更多的時間，所以儘量減少無意義的構建。

程式碼質量管理

程式碼規範

很多公司可能不太注意程式碼規範。但是程式碼規範與產品程式碼質量有著直接的關係。程式碼規範很重要的一點是程式碼的可讀性。提高了程式碼的可讀性，自己更容易理解，結對開發的同伴也更容易理解。這樣的程式碼由於清晰易理解，所以更不容易出錯。一旦出錯後也更容易找到問題所在。好理解的程式碼在出錯後自己或者同伴更願意去找問題，而不是對不容易理解的程式碼面露難色。可讀性高的程式碼開發也更願意去優化重構，形成良性迴圈。

程式碼稽核

sonarqube與sonarlint

unit test 與 BDD

自動化測試

TBD