在這段時間實現自動化的過程中有一些小小的收穫，在這裡記錄一下，為了以後為自己和朋友們提供借鑑。一般在設計自動化測試時，我們都會新增對預期結果的斷言以驗證系統功能是否符合需求要求。自動化測試的目的是為了減少人力投入，進而將人力投入到更需要的地方，而非完全代替人力，所以在新增斷言時就要求細緻全面。

  首先說一下assertText這個API，說到assertText就不得不說assertTextPresent這個API，先說說這兩個API的不同中說起。對於文字資訊的驗證一般是以assertTextPresent和assertTextNotPresent，但有些時候還是不夠的，需要進一步完善。在最近的工作中，為了驗證一個數據的某個特定元素的文字用到了assertText這個API。assertText和assertTextPresent很像但有很大不同。assertTextPresent只關心文字是否存在，所以對於頁面上唯一出現的文字驗證比較方便；另外，assertTextPresent也不關心文字所在位置。而assertText則不同，對於頁面上可能多次出現的文字我們可以根據一些輔助元素進行判斷是否與預期相符，例如，某個頁面資訊的文字內容是否是xxx，即與輔助元素在位置上存在間接關聯性。這個時候assertText則更具有針對性，對自動化測試驗證點的覆蓋自然更加全面。

  由此，為了更全面的驗證需要對xpath的用法諳熟於心，理解並運用。在之前關於Selenium xpath中說明了一些謂語的用法，類似的有following,preceding等等，這次遇到了ancestor又有了一些體會，在這裡分享給大家。在xpath的教程中提到過xpath有個格式--謂語::軸形式。之前在用following這些謂語的時候，對軸的概念沒有特別深刻的體會，就覺得是子元素的一個標籤。在這次用到ancestor的時候，才深刻體會到這個軸是一個定位點，向上找祖先節點到某個節點結束，再往下找匹配的子節點。這樣說有點亂，還是直接上圖上真相吧，呵呵。

可能大家覺得這個例子並不貼切，這裡只是為了說明軸就是我們要找的一個參考節點，以這個節點再去定位最後要找的的元素。那這個節點必定和之前的和之後的節點存在著某種關係，或父子或兄弟，這個就要看實際情況了。在實際使用時體會一下應該會更有幫助吧，呵呵。

  最後，說一下框架，在之前的一次中提到了用到過的兩個不同框架，一個是用java code寫類selenium的語句，當然這其中會用到封裝；另一個是在htm中寫tr/td由框架進行解析，解析成selenium中的action進行操作。在上一篇中感覺通過框架解析的方法很好，簡單易用，但隨著業務邏輯的深入發現這種框架很難達到對業務邏輯的驗證，只能驗證頁面元素的存在或正確，如果頁面上的幾個值存在一定業務關係，這種框架是無從驗證的，在html中無法對這些資料進行操作去驗證是否符合預期。相反的，用java code的程式碼就可以達到對頁面上資料進行一些業務驗證的可能性。我們可以用selenium API(例如storeValue)獲得資料，通過java code進行比較，再通過if/else比判斷是否符合業務邏輯。這樣從頁面的角度也驗證了部分業務邏輯，不僅僅是“死板”的頁面驗證，無疑這樣對自動化測試的覆蓋又提高了一塊兒。

  3點小小的體會，工作中的總結吧，拿出來和大家分享，希望有幫助。