從功能測試到自動化測試

對於測試人員來講，無論進行功能測試仍是自動化測試仍是性能測試都是須要編寫測試用例，因此咱們必須先要了解清楚手工測試用例與自動化測試用例的一些特色，才能更好的開展自

現現在應該有不少 測試 人員應該有這樣的疑慮， 自動化 測試 要怎麼去作，今天把一些學習經驗分享給你們，但願對大家有幫助，有說的很差的地方，還請多多指教！

對於 測試人員 來講，無論進行 功能測試 仍是 自動化測試 仍是 性能 測試都是須要編寫 測試 用例 ，因此咱們必須先要了解清楚手工 測試 用例 與 自動化測試 用例的一些特色，才能更好的開展自動化測試工做。

在這裏插入圖片描述

一、手工測試和自動化測試用例

手工測試用例是針對功能測試人員的，而自動化測試用例是針對自動化測試用例框架或工具的。

1）手工測試用例特色

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

人工執行用例具備必定步驟跳躍性；

人工測試步步跟蹤，可以細緻定位問題；

主要用來發現功能 缺陷 ；

2）自動化測試用例特色

執行對象是腳本，任何一個盤算都須要編碼定義；

用例步驟之間關聯性強；

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

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

（注意：經過對比發現，自動化測試不能徹底替代手工測試，自動化測試的目的僅僅在於讓測試人員從繁瑣重複的測試流程中解脫出來，把更多的時間和精力放在更有價值的測試中，例如探索性測試。）

3）自動化測試用例注意事項

①不是全部手工測試用例都要轉爲自動化測試用例；

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

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

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

⑤選取的用例能夠是主體流程，這部分用於冒煙測試（若是不瞭解專業術語，下來要花費功夫哦）；

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

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

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

在這裏插入圖片描述

若是對 軟件測試 、接口測試、自動化測試、面試經驗交流。感興趣能夠加軟件測試 交流：1085991341，還會有同行一塊兒技術交流。

二、自動化測試類型

1）測試靜態內容

靜態內容測試是最簡單的測試，用於驗證靜態的、不變的ui元素的存在性，例如：

①每一個頁面都有預期的頁面標題，這能夠用來驗證連接指向一個預期頁面；

②應用程序的主頁包含一個應該在頁面頂部的圖片；

③網站的每一個頁面是否包含一個頁腳區域來顯示公司的聯繫方式、隱私政策以及商標信息等；

④每一頁的標題文本都使用< h1>標籤嗎？每一個頁面是否都有正確的頭部文本；

你可能須要（也可能不須要）對頁面內容進行自動化測試。若是你的網頁是不易受到影響的，則手工對內容進行測試就足夠了。假設你的應用文件的位置移動了，則內容測試就很是有價值。

2）測試連接

web 站點的一個常見錯誤爲失效的連接或連接指向無效頁。連接測試涉及各個連接和驗證預期的頁面是否存在。若是靜態連接不常常更改，則手動測試就足夠了。可是，若是你的網頁設計師常常修改連接或者文件不時被重定向，則連接測試應該實現自動化。

3）功能測試

在你的應用程序中，須要測試應用的特定功能，須要一些類型的用戶輸入，並返回某種類型的結果，一般一個功能測試涉及多個頁面，一個基於表單的輸入頁面，其中包含若干輸入字段，提交和取消操做，以及一個或多個響應頁面。用戶輸入能夠經過文本輸入域、複選框、下拉列表，或任何其餘瀏覽器所支持輸入。

 

原文  http://www.ltesting.net/ceshi/ceshijishu/zdcs/2020/0807/208764.html