自動化測試
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。
個人認為，只要能服務於我們，能夠幫助我們提公升工作效率的，不管是所謂的自動化工具，還是寫個sql指令碼、寫個批處理、做個小工具等等，都屬於自動化範疇。自動化是乙個思想，而不是工具。
自動化並非萬能，人工測試還是必須的。自動化的目的是驗證問題，手工測試的目的是發現問題。完全自動化，拋棄手工測試，這種想法是存在誤區的，重複也是一種極致，當你在重複裡面找到靈感了，找到快樂了，你就比別人高乙個境界。手工測試，自動化測試，業務邏輯能力，測試技術存在乙個平衡點。
為什麼引入自動測試
直接一點的：就是為了節省人力、時間或硬體資源，提高測試效率，滿足版本需求的快速迭代，提公升產品測試質量。
自動化測試前提
軟體需求變動不頻繁，相對穩定的功能模組或介面
專案週期足夠長
自動化指令碼可重複使用
手工測試無法完成的，或者需要投入較大時間人力的
自動化測試的適用性
切入時機
以基本完成軟體的程式介面開發、頁面控制項相對穩定為宜。
適用場景
測試時間相對長，且存在大量重複性、機械性手工測試的專案
產品型軟體，每發布乙個新的版本或打補丁都需要對其他模組執行相同的測試
專案型軟體，需求變更頻繁，每變更一次，需要對原有的無爭議的功能做測試
經常需要更換應用程式部署站點的軟體，每更換一次需要對所有功能做驗證測試
測試時間相對長，且存在大量需要執行回歸測試的軟體專案
系統介面穩定，需要對業務流程進行驗證測試的軟體
採用增量開發持續整合的專案，需要對頻繁更新的程式執行驗證測試
軟體專案採用主流開發平台技術，且不存在物理互動的測試
（專案周期長，產品穩定，回歸需求量大，手工可替代性強....）
不適用場景
自動化測試過程
自動化測試需求分析》自動化測試框架選型、搭建》自動化測試用例、指令碼編寫》自動化測試結果分析》版本更新迭代維護、持續整合
自動化分類
ui自動化
維護成本高，受益最小。當然不是說ui自動化沒有價值，適當的介面自動化還是有用的。
目前應用較多的場景是在版本發布，可對功能穩定、基本無改動的模組開展ui自動化，從而縮短版本發布週期。
間接的，也讓人工測試把重心放在產品的核心業務場景以及改動較大的功能模組上。
介面自動化
維護成本適中，受益適中，可以考慮覆蓋大部分業務流程。
現在很多系統前後端架構是分離，後端介面服務開發是先行的，介面層發現問題，可預防和減少ui層的問題。
單元測試
維護成本低，受益最大，價值最大。但是目前基本是開發在做，測試人員參與較少，而且對測試人員要求較高。
自動化的利弊陳述
在軟體工業的測試行業也同樣存在同樣的問題，自動化的測試實際上是相當於在功能**之上，還要投入開發另外乙個專案並維護，這樣也無法避免的需要耗費寶貴的開發資源。
現在的情形說極端一點就是：
現實一點解讀就是：」找死「的不一定死，」等死「的則必然死。 」找死「 雖然說是主動尋死，但是這樣的人至少還是在想辦法求生路，存在成功的可能，」等死「 則是在消磨和透支自己的時間和機會，只能被動受死。
綜上：如果有長遠的產品線和長遠的眼光，決策者都應該花一定的精力來做 」自動化「。這裡所說的 」長遠「 是指生產過程需要有足夠的量或者時間來收回自動化投入上產生的首次成本
自動化測試之初步理解
一.what 什麼是自動化測試 自動化測試 通過機器 包括計算機 代替人，執行測試的過程 二.why 為什麼我們需要自動化測試 避免機械式的重複工作 避免人為的錯誤 避免手工測試的侷限性 提高測試效率 具有可重複性和一致性 更好利用資源 等等三 where 何地需要自動化測試 軟體週期足夠長 需求變...
介面自動化測試介紹
介面是有協議的，它規範了軟體之間進行資料互動時所應該遵循的規矩，介面的請求方法 報文格式 包括請求報文及返回報文 都必須按照協議所規定的規範來，如果不守規矩，則軟體之間就無法進行互動。常見的介面協議有 本質是基於某種協議 大協議，可模擬於憲法 按照介面文件 小協議，可模擬於各個法，如刑法 民法等 的...
自動化測試 Appium（介紹）
支援的平台 搭建依賴 支援的平台 ios 平台支援 android 平台支援 windows 桌面支援 1.不應該為了自動化而重新編譯你的應用或以任何方式修改它。2.不應該被限制在特定的語言或框架上來編寫執行測試。3.移動端自動化框架不應該在自動化介面方面重造輪子。4.移動端自動化框架應該開源，在精...