我們的測試為什么不夠敏捷(2)

　　click()表示在找到的當前控件上執行點擊操作;

　　2、在新增用戶頁面，輸入“帳號”、“密碼”、“姓名”，選擇“性別”、“生日”和“國籍”，然后點擊“保存”按鈕，回到用戶列表頁面，并判斷是否增加成功：

　　1) String account="autotest2";

　　2) webDriver.findElement(By.xpath("//div[contains(@id,'account_userForm')]//input")).sendKeys(account);

　　3) webDriver.findElement(By.xpath("//div[contains(@id,'password_userForm')]//input")).sendKeys("1");

　　4) webDriver.findElement(By.xpath("//div[contains(@id,'name_userForm')]//input")).sendKeys(account);

　　5) webDriver.findElement(By.xpath("//div[contains(@id,'sex_userForm')]//input")).click();

　　6) webDriver.findElement(By.xpath("//span[text()='女']")).click();

　　7) webDriver.findElement(By.xpath("//div[contains(@id,'birthdate_userForm')]//input")).click();

　　8) webDriver.findElement(By.xpath("//div[contains(@id,'nationality_userForm')]//input")).click();

　　9) webDriver.findElement(By.xpath("//span[text()='中國']")).click();

　　10) webDriver.findElement(By.xpath("//a[contains(@id,'userSaveBtn')]//button")).click();

　　11) WebElement ele = webDriver.findElement(By.xpath("//div[text()='"+account+"']"));

　　12) Assert.assertNotNull(ele);

　　腳本解讀：

　　sendKeys ()表示在找到的當前控件上輸入字符;

　　2~9行表示通過輸入或點擊選擇的方式為用戶相關屬性賦值;

　　第10行表示點擊“保存”按鈕(點擊后會自動轉向用戶列表頁面);

　　11~12行表示查找頁面上文本內容為新增帳號的div，并斷言該div是存在的(不為空);

　　3、刪除剛剛增加的人員，然后判斷是否刪除成功：

　　1) webDriver.findElement(By.xpath("//a[contains(@id,'deleteUserBtn')]//button")).click();

　　2) WebElement ele = webDriver.findElement(By.xpath("//div[text()='"+account+"']"));

　　3) Assert.assertNull(ele);

　　腳本解讀：

　　第1行表示點擊“刪除”按鈕;

　　2~3行表示查找頁面上文本內容為新增帳號的div，并斷言該div已經不存在了(為空);

　　通過上面的腳本就可以實現“用戶增加、刪除”的自動化測試，并且可以跨瀏覽器?？吹竭@里您會不會覺得整體還不錯，如果測試腳本再能通過錄制的方式自動生成就更好了!

　　“看”起來確實還不錯，但在實際項目中用起來就沒那么爽了。這其實是在技術/工具選型時普遍存在的現象：在驗證/試用階段的評價很高，但在投入生產使用時會遇到各種各樣的問題，因此大家在選型階段除了考慮功能，還要考慮技術/工具本身的開放性和可擴展性。

　　上面的方案單純從技術的角度來講是很不錯的：開源、社區活躍、標準化程度高、支持跨瀏覽器、腳本回放穩定、可集成性高，等等。

　　但是如果就這樣應用在實際項目中，會從過程的角度暴露一些棘手的問題：

　　測試腳本是“代碼級”的，那么應該由誰來編寫呢?

　　測試人員和開發人員好像都有編寫這些測試腳本義務，但似乎又都有不寫的理由。

　　測試腳本必須不斷的修改才能在最新版本上跑通，誰該為此買單?

　　在敏捷開發過程中需要快速響應需求的變化(新增、變更)，這一點整個團隊都好理解。因此如果需求發生變化，開發人員修改代碼、測試人員修改測試腳本，一切順理成章，大家相安無事。但是在用戶需求沒有變化時，開發人員頻繁修改代碼的情況也很常見：比如，修改Bug、針對“壞味道”做重構、調整頁面布局或樣式。于是在“毫無征兆”的情況下，測試腳本又無法執行了!

　　這時候測試人員可能會質問開發人員：“做之前怎么不想清楚?都已經測試完成的功能，為什么還總是反復修改?什么時候代碼才能穩定?”。

　　而開發人員此時也會非常理直氣壯：“有Bug能不改么?頁面布局不合理導致用戶體驗差，能不改么?而且敏捷中的一個重要的實踐就是重構啊”。

　　大家又是似乎都有道理、也都有苦衷。我雖然作為測試人員，但是在這個問題上還是“偏向于”開發人員的： 在軟件生命周期的各個階段(需求、設計、開發、測試)中，后面的階段對前置階段是有一定依賴的，所以越往后期響應變化的難度越大。比如，在“開發”環節不僅需要響應“需求”的變化(新增、變更)，而且需要響應“設計”的變化。從這個角度來看，“測試”本就應該響應“開發”的變化。

　　對于在實際項目自動化測試過程中遇到的上述問題，歸根到底是因為“自動化測試方案本身的敏捷程度不夠”，主要體現在如下三個方面：

　　1、 學習成本高

　　測試人員除了要掌握WebDriver接口之外，還要掌握XPath、TestNG的用法，甚至還需要對功能的前臺實現有一定了解。

　　2、 腳本維護困難

　　敏銳的開發/測試人員從上面的示例腳本中，可以馬上嗅出一些“壞味道(Bad Smell)”: 代碼相似度非常高、可能變化的數據被硬編碼在測試代碼里、代碼可讀性差、測試代碼與頁面源碼耦合度大，等等。這些壞味道的出現，通常意味著需要進行重構，否則會愈演愈烈，最終變得尾大不掉。

原文轉自：http://www.infoq.com/cn/articles/test-no-agile-enough