本文介紹如何編寫自動化測試用例
(記得收藏，**哦)
下面分享一篇關於自動化用例編寫的文章。
用例選型注意事項：
1、不是所有的手工用例都要轉為自動化測試用例。
2、考慮到指令碼開發的成本，不要選擇流程太複雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現指令碼。
3、選擇的用例最好可以構建成場景。例如乙個功能模組，分n個用例，這n個用例使用同乙個場景。這樣的好處在於方便構建關鍵字測試模型。
4、選擇的用例可以帶有目的性，例如這部分用例是用例做冒煙測試，那部分是回歸測試等，當然，會存在重疊的關係。如果當前用例不能滿足需求，那麼唯有修改用例來適應指令碼和需求。
5、選取的用例可以是你認為是重複執行，很繁瑣的部分，例如字段驗證，提示資訊驗證這類。這部分適用回歸測試。
6、選取的用例可以是主體流程，這部分適用冒煙測試。
7、自動化測試也可以用來做配置檢查，資料庫檢查哦。這些可能超越了手工用例，但是也算用例拓展的一部分。專案負責人可以有選擇地增加。
8、如果平時在手工測試時，需要構造一些複雜資料，或重複一些簡單機械式動作，告訴自動化指令碼，讓他來幫你。或許你的效率因此又提高了。
用例轉型注意事項：
1、首先測試人員應該了解指令碼是怎麼替代人工來執行用例。
2、當你寫自動化測試用例時，你需要意識到你的用例是寫給乙個「智障人士」執行，執行物件是指令碼。
3、當前的測試用例前置配置資訊要寫清楚。
4、每乙個步驟都要銜接好，錯了，指令碼要報異常，我要去煩你。
5、每乙個步驟要做什麼，驗證什麼要寫清楚，寫具體。有時乙個檢查點，你只需看一眼，但是指令碼要寫一堆**去驗證，這樣的做法是不可行的。
6、用例之間不要有關聯性，自動化測試開發同樣是軟體開發工程，指令碼編寫同樣提倡高內聚低耦合的理念。
7、不是每乙個步驟都需要驗證點，讓子彈飛一會兒。
8、別在多個地方重複相同的驗證。指令碼很忙！我沒空。當然，除非有必要。
9、開門記得要關門，配置資訊要回歸原點，否則指令碼要迷路。
10、當你設計自動化測試用例時，難免對乙個用例的功能點加加減減。不要因此而剪掉了一些驗證點。因為手工用例+自動化用例=1。
寫給專案測試負責人的一些話：
1、專案加入了自動化測試平台，負責人要有全域性的把握。因為你的用例被拆分成自動化測試 和手工執行用例，原來一些被打入冷宮的用例因自動化測試而重生，重生的用例需要你的維護。
2、當你迎來專案新立項，拿到需求文件，開始設計新用例，此時，別忘了該如何統籌安排你的用例。是的，這很像排兵布陣，有了自動化測試這把利劍，還得看你會不會用。
3、不要永遠做自動化測試的門外漢。可能你的職業規劃是測試經理，產品經理，或者其他，又可能你對其感到畏懼或厭倦，認為自己無法跨越對編碼的恐懼。但是，無論如何，今天你是這個專案的測試負責人(乙個資深的測試工程師)，你要負起這個責任，挑起大樑。
4、如果以後你看到自動化測試報告單，沒有發現乙個bug，請不要抱怨，自動化指令碼主要不是來幫你找缺陷，而是告訴你沒有缺陷。
5、如果將來你參與了自動化測試指令碼編寫工作，請做好面對一大堆錯誤的心理準備。在前期，測試結果往往會夾雜著一大堆的各種錯誤，可能是框架機制問題，可能是指令碼編寫問題，可能是用例問題，還有可能是需求自身的問題。
6、咱們部門剛剛開展自動化測試，需要大夥的支援和理解。它的發展需要乙個漸進的過程，從無序到有序，從困惑到豁然開朗。這個過程難免曲折艱辛，甚至會引來非議，但是從一些成功案例中，還是堅定了我繼續走下去的信心。我渴望和大家一起分享這份成果，儘管現在連花兒都未曾開放。
7、會自動化測試和會qtp是兩回事，學習自動化測試不一定要會qtp，你也可以通過selenium入門。
8、請考慮下你負責的專案是否需要實施自動化測試，我們可以一起坐下來討論，圈定乙個範圍和實施的計畫。我們都是產品線上的一顆螺絲釘，我這顆螺絲釘很樂意為你的專案提供自動化測試的幫助。
9、不要過度信任自動化測試，它也是個撒謊高手。所以，自動化用例需要測試，框架需要測試，指令碼函式需要測試，指令碼過程需要測試，驅動資料需要測試。
10、看到這裡，你一定覺得開展自動化測試很累人。沒錯，這本不是一件立竿見影的利索活。它的發光，需要一定時間的沉澱，我們現在討論的，和接下來要做的工作就是為了如何來縮短這部分的時間。
總結：
今天討論的僅僅是自動化測試開展實施的一部分，這部分很關鍵，需要大家的支援，因為用例是整個自動化測試的靈魂，沒了靈魂，框架搞得再好，也僅僅是個軀殼，行屍走肉。我自己寫測試用例的水平遠不如咱們部門的測試負責人，這是真話。討論自動化測試用例的選型和轉型難免有些力不從心，儘管這樣，我還是憋著喊出來，希望能得到大家的更好見解，俗稱：拋磚引玉。
android adb命令大全
匯入匯出檔案測試點
手把手帶你入門git操作
記得收藏，**哦！
自動化測試用例編寫守則
先來說下一般自動化測試的流程，今天乙個朋友也問過我這個問題，就順便說說。一般在開始自動化測試，如拿到乙個程式包或apk或 檔案後，我們首先要做的就是要分析這個程式適不適合進行自動化測試 之後再對程式的執行路徑進行分析，找出一些關鍵路徑和有針對性的進行測試設計 然後就是測試用例編寫和指令碼編寫執行了 ...
php介面自動化測試用例編寫
最近用php寫完了一版專案的介面，有點多，意味著bug也會很多，人工測試起來有點麻煩，於是準備用php編寫乙個測試bug的程式。以前是沒有這種意識的。這篇文章主要是提醒我未來程式寫完後，能養成編寫介面自動化測試用例的習慣。其實編寫介面自動化測試用例很簡單，比如測試乙個登陸的介面 public fun...
Web自動化測試 測試用例斷言
執行測試用例時，需要判斷用例是否執行成功，此時需要有乙個我們期望的結果來進行驗證。這裡unittest中，如果乙個case執行的過程中報錯，或者我們判斷結果不符合期望，就會判定此條用例執行失敗，判斷的條件主要是根據斷言來實現，這節主要學習下斷言的使用。一 斷言的方法 1.1 testcase類中的部...