關于自動化軟件測試用例設計的幾點分析

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

　　a)手工測試用例

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

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

　　iii.人工測試步步跟蹤，能夠細致的定位問題。

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

　　b)自動化測試用例

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

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

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

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

　　2、自動化測試用例設計管理不善可以直接導致自動化測試開展的失敗。

　　誤區：

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

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

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

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

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

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

　　回歸測試執行全部或部分的測試用例。

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

　　用例選型注意事項：

　　1、不是所有的手工用例都要轉為自動化測試用例。

　　2、考慮到腳本開發的成本，不要選擇流程太復雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現腳本。

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

　　4、選擇的用例可以帶有目的性，例如這部分用例是用例做冒煙測試，那部分是回歸測試等，當然，會存在重疊的關系。如果當前用例不能滿足需求，那么唯有修改用例來適應腳本和需求。

　　5、選取的用例可以是你認為是重復執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用回歸測試。

　　6、選取的用例可以是主體流程，這部分適用冒煙測試。

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

　　8、如果平時在手工測試時，需要構造一些復雜數據，或重復一些簡單機械式動作，告訴自動化腳本，讓他來幫你?；蛟S你的效率因此又提高了。

　　用例轉型注意事項：

　　1、首先測試人員應該了解腳本是怎么替代人工來執行用例。

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

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

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

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

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

　　7、不是每一個步驟都需要驗證點，讓子彈飛一會兒。

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

　　9、開門記得要關門，配置信息要回歸原點，否則腳本要迷路。

　　10、當你設計自動化測試用例時，難免對一個用例的功能點加加減減。不要因此而剪掉了一些驗證點。因為手工用例+自動化用例=1。

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

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

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

原文轉自：http://www.uml.org.cn/Test/201203191.asp