如何設計自動化測試用例

用例選型注意事項：

一、  不是全部的手工用例都要轉爲自動化測試用例。

二、  考慮到腳本開發的成本，不要選擇流程太複雜的用例。若是有必要，能夠考慮把流程拆分多個用例來實現腳本。

三、  選擇的用例最好能夠構建成場景。例如一個功能模塊，分n個用例，這n個用例使用同一個場景。這樣的好處在於方便構建關鍵字測試模型。

四、  選擇的用例能夠帶有目的性，例如這部分用例是用例作冒煙測試，那部分是迴歸測試等，固然，會存在重疊的關係。若是當前用例不能知足需求，那麼惟有修改用例來適應腳本和需求。

五、  選取的用例能夠是你認爲是重複執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用迴歸測試。

六、  選取的用例能夠是主體流程，這部分適用冒煙測試。

七、  自動化測試也能夠用來作配置檢查，數據庫檢查哦。這些可能超越了手工用例，可是也算用例拓展的一部分。項目負責人能夠有選擇地增長。

八、  若是平時在手工測試時，須要構造一些複雜數據，或重複一些簡單機械式動做，告訴自動化腳本，讓他來幫你。或許你的效率所以又提升了。

 

用例轉型注意事項：

一、  首先測試人員應該瞭解腳本是怎麼替代人工來執行用例。

二、  當你寫自動化測試用例時，你須要意識到你的用例是寫給一個「智障人士」執行，執行對象是腳本。

三、  當前的測試用例前置配置信息要寫清楚。

四、  每個步驟都要銜接好，錯了，腳本要報異常，我要去煩你。

五、  每個步驟要作什麼，驗證什麼要寫清楚，寫具體。有時一個檢查點，你只需看一眼，可是腳本要寫一堆代碼去驗證，這樣的作法是不可行的。

六、  用例之間不要有關聯性，自動化測試開發一樣是軟件開發工程，腳本編寫一樣提倡高內聚低耦合的理念。

七、  不是每個步驟都須要驗證點，讓子彈飛一下子。

八、  別在多個地方重複相同的驗證。腳本很忙！我沒空。固然，除非有必要。

九、  開門記得要關門，配置信息要回歸原點，不然腳本要迷路。

十、當你設計自動化測試用例時，不免對一個用例的功能點加加減減。不要所以而剪掉了一些驗證點。由於手工用例+自動化用例=1。

 

寫給項目測試負責人的一些話：

一、  項目加入了自動化測試平臺，負責人要有全局的把握。由於你的用例被拆分紅自動化測試 和手工執行用例，原來一些被打入冷宮的用例因自動化測試而重生，重生的用例須要你的維護。

二、  當你迎來項目新立項，拿到需求文檔，開始設計新用例，此時，別忘了該如何統籌安排你的用例。是的，這很像排兵佈陣，有了自動化測試這把利劍，還得看你會不會用。

三、  不要永遠作自動化測試的門外漢。可能你的職業規劃是測試經理，產品經理，或者其餘，又可能你對其感到畏懼或厭倦，認爲本身沒法跨越對編碼的恐懼。可是，不管如何，今天你是這個項目的測試負責人（一個資深的測試工程師），你要負起這個責任，挑起大梁。

四、  若是之後你看到自動化測試報告單，沒有發現一個bug，請不要抱怨，自動化腳本主要不是來幫你找缺陷，而是告訴你沒有缺陷。

五、  若是未來你參與了自動化測試腳本編寫工做，請作好面對一大堆錯誤的心理準備。在前期，測試結果每每會夾雜着一大堆的各類錯誤，多是框架機制問題，多是腳本編寫問題，多是用例問題，還有多是需求自身的問題。

六、  我們部門剛剛開展自動化測試，須要大夥的支持和理解。它的發展須要一個漸進的過程，從無序到有序，從困惑到豁然開朗。這個過程不免曲折艱辛，甚至會引來非議，可是從一些成功案例中，仍是堅決了我繼續走下去的信心。我渴望和你們一塊兒分享這份成果，儘管如今連花兒都不曾開放。

七、  會自動化測試和會QTP是兩回事，學習自動化測試不必定要會QTP，你也能夠經過Selenium入門。

八、  請考慮下你負責的項目是否須要實施自動化測試，咱們能夠一塊兒坐下來討論，圈定一個範圍和實施的計劃。咱們都是產品線上的一顆螺絲釘，我這顆螺絲釘很樂意爲你的項目提供自動化測試的幫助。

九、  不要過分信任自動化測試，它也是個撒謊高手。因此，自動化用例須要測試，框架須要測試，腳本函數須要測試，腳本過程須要測試，驅動數據須要測試。

十、看到這裏，你必定以爲開展自動化測試很累人。沒錯，這本不是一件立竿見影的利索活。它的發光，須要必定時間的沉澱，咱們如今討論的，和接下來要作的工做就是爲了如何來縮短這部分的時間。