自動化測試用例設計的幾點分析

一、手工測試用例和自動化測試用例功能定位的區別

 

a)手工測試用例

 

i.較好的異常處理能力，能經過人爲的邏輯判斷校驗當前步驟的功能實現正確與否。

ii.人工執行用例具備必定的步驟跳躍性。

iii.人工測試步步跟蹤，可以細緻的定位問題。

iv.主要用來發現功能缺陷

 

b)自動化測試用例

 

i.執行對象是腳本，任何一個判斷都須要編碼定義。

ii.用例步驟之間關聯性強。

iii.主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重複的工做中解脫出來。

iv.目前自動化測試階段定位在冒煙測試和迴歸測試。

 

二、自動化測試用例設計管理不善能夠直接致使自動化測試開展的失敗

 

誤區：

一、不編寫測試用例直接投入測試腳本編寫。

二、直接拿手工測試用例來編寫自動化測試腳本。

 

自動化測試替代不了手工測試，目的僅僅在於讓測試人員從繁瑣重複的機械式測試過程解脫出來，把時間和精力突入到更有價值的地方，從而挖掘更多的產品缺陷。

 

目前我們TD中對用例加入了自動化測試的標籤。

 

目前自動化測試定位在冒煙測試和迴歸測試

 

冒煙測試執行的是主體功能點的用例

 

迴歸測試執行所有或部分的測試用例

 

怎麼編寫自動化測試用例，如何將自動化測試用例和手工測試用例相輔相成

 

用例選型注意事項：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

用例轉型注意事項：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

總結：今天討論的僅僅是自動化測試開展實施的一部分，這部分很關鍵，須要你們的支持，由於用例是整個自動化測試的靈魂，沒了靈魂，框架搞得再好，也僅僅是個軀殼，行屍走肉。

 

轉載：http://mp.weixin.qq.com/s?__biz=MjM5Mjg0MzMzMw==&mid=212914751&idx=3&sn=78e3660143ff76c24b500bfa7275760b&scene=0#rd