這個文檔有點籠統，相信大家也都有自己的想法，我在這裡寫一些我自己的看法，請大家指教。
自動化測試工程師的了解
什麼叫做自動化測試工程師
首先，會使用自動化測試工具的測試人員不能夠稱之為完全的自動化測試人員，這類測試人員被稱為『工具小子』(Script Kid)。這個階段還是處于自動化測試的一個比較低級的階段，因為這些工具都不是測試人員開發的。
對于高手來說，要能寫一些獨立的測試腳本甚至測試工具。
更高的高手則是能腳本和工具和實際工作緊密結合起來，解決工作中遇到的問題。
自動化測試工程師應該具有開發能力嗎
- 通過上述内容，應該可以看得出來，自動化測試人員一定要有開發能力，而這恰恰是測試人員目前所欠缺的。沒有開發能力的測試人員雖然也可以做一些所謂的自動化，但是僅僅是一些皮毛，沒有辦法做到活學活用。
- 根據某機構的調查資料，目前所有從事測試工作的人中，90%的人都沒有任何開發能力。根據目前的市場行情，如果在精通一門開發語言，能夠從純手工測試轉型為自動化測試工程師，月薪至少增加3~5k。(沒有前提, 這就是社會! ! !)
自動化測試的層級
一般來說，自動化測試分為三個層級：單元測試、接口測試和UI測試，這三層成一個金字塔形狀分布。最底層是單元測試，接口測試在中間，UI測試在最上層。下面通過一個表格來對比着三層測試。
| 層級 | 所處位置 | 受益 | 測試對象 | 運作速度 | 定位問題難度 | 維護成本 |
|---|---|---|---|---|---|---|
| 單元測試 | 底層 | 70% | 類或者方法 | 極快 | 十分容易 | 低 |
| 接口測試 | 中間 | 20% | 服務接口 | 快 | 一般 | 低 |
| 功能測試 | 上層 | 10% | 界面 | 慢 | 較難 | 非常高 |
不是說功能測試不好, 而是根據接口測試,與單元測試進行對比得到的結果!
測試人員應該怎麼辦
單元測試
單元測試無疑是最适合做自動化的，但是，大多數單元測試都是由研發人員自己完成。單元測試的代碼行覆寫率能夠達到70%，就是一個非常不錯的程度了。測試人員不做單元測試，但是可以嘗試推動研發人員來編寫單元測試用例。
單元測試架構
- 單元測試常用的架構——XUnit，比如Java的JUnit，PHP的PHPUnit，Python的unittest等等；
- 一個測試用例通常由三部分組成——setUp，測試邏輯，tearDown。setUp用于準備測試資料，tearDown用于清理資料；
-
一般單元測試架構都支援裝飾器設計模式的注解，比如跳過執行，測試套件的組織，測試用例依賴管理等等
單元測試架構可以無縫地在UI測試和接口測試中使用，它們的基本思想都是相通的。
UI測試
目前，大衆眼中關注的比較多的是UI的自動化測試，這是由大家的思維慣性導緻的。傳統的測試行業，測試工程師都是從UI下手，來完成所有的測試工作，是以到自動化領域，大家也理所當然的喜歡從UI層來進行自動化。做UI自動化，最重要的是要能有一個好的自動化測試架構，這裡有一些架構的基本設計思路供大家參考：
- 分布式——case增加到一定程度後，如何快速的運作所有的case，這就涉及到分布式的概念。對于Selenium，官方提供了一個Grid，感興趣的同學可以研究一下；
- 行為驅動——也就是常說的Cucumber，這個領域筆者沒有太多的涉足，不誤導大家
- 關鍵字驅動——由『操作對象』、『操作』、『資料』關鍵字組合成測試用例，架構來把關鍵字解析為腳本并執行。這種架構最大的優點就是可以提供給不懂代碼的測試人員使用，典型的代表是Robot framwork
- 資料驅動——同一段代碼的業務邏輯通過更換資料輸入來生成多個測試用例，我們隻需維護測試資料就可以維護case，這種架構思想在很多測試工具中都有實作
-
關鍵字和資料混合驅動——目前最進階的架構，将上述兩種架構結合起來
當然，這些思路不僅僅能用在UI層的自動化。
對于UI自動化，我個人的建議是隻做冒煙測試用例的自動化，這樣既可以從UI的角度來重複性的驗證主業務主流程沒有問題，又可以降低維護成本。
以上 原文出自: https://blog.csdn.net/flying1943/article/details/51504651
接口測試(重點)
1. 什麼是接口測試
接口的自動化是目前最适合測試工程師進行自動化的一層。接口不但變化小，運作速度快，受益高，還有着出現問題後能夠很快定位的優點。(說白了, 就是我還不會單元測試)
顧名思義，接口測試是對系統或元件之間的接口進行測試，主要是校驗資料的交換，傳遞和控制管理過程，以及互相邏輯依賴關系。其中接口協定分為HTTP,WebService,Dubbo,Thrift,Socket等類型，測試類型又主要分為功能測試，性能測試，穩定性測試，安全性測試等。
在分層測試的“金字塔”模型中，接口測試屬于第二層服務內建測試範疇。相比UI層（主要是WEB或APP）自動化測試而言，接口自動化測試收益更大，且容易實作，維護成本低，有着更高的投入産出比，是每個公司開展自動化測試的首選。
下面我們以一個HTTP接口為例，完整的介紹接口自動化測試流程：從需求分析到用例設計，從腳本編寫、測試執行到結果分析，并提供完整的用例設計及測試腳本。
2. 基本流程
基本的接口功能自動化測試流程如下：
需求分析 -> 用例設計 -> 腳本開發 -> 測試執行 -> 結果分析
2.1 需求分析
一般情況是 産品經理, 或者産品人員在原型, 或者需求文檔評審完成以後, 開發人員會很久原型文檔設計接口, 咱們接口測試人員就要根據開發設計出來的文檔設計, 來分析接口和原型文檔定義的是否完全, 同時根據接口設計用例.
2.2 用例設計
到了這一步, 就要設計了, 不過,不用像功能測試用例那樣, 設計的特别詳細, 隻需要有主流程, 或者流程分支的用例就好了, 畢竟自動化測試, 不是用來發現BUG的, 而是用來确定這個流程上, 是不是有問題.
2.3 腳本開發
這一步, 就有很多種選擇了, 可以用 JMeter, postMan, readAPI, java, python 等等 測試工具都可以使用. 具體的我後面會寫. (我使用過很多工具, 最後我決定了用靈活的程式設計語言python, 來寫自動化接口測試. 沒有複雜的文法, 卻又有不一般的靈或性. )
2.4 測試執行
這一步, 就簡單了, 右鍵 RUN 所有工具全都是, 運作結果要儲存起來, 不然, 根本不知道運作完了, 有沒有問題.
比如說: 注冊的接口, 注冊完了, 資料庫裡有沒有添加資料. 或者說, 查詢接口,有沒有吧資料庫裡的資料查詢出來. 等等這都是需要斷言的地方. 用一個專門的日志檔案, 儲存起來, 還有有專門的程式,去斷言. 不然寫完了, 也要自己去看, 這不能是自動化測試.
2.5 結果分析
這個就是分上一步輸出的日志, 或者說是斷言結果.
總結
接口測試嗎, 可不是, 用個工具, 寫個路徑, 添點參數, 調用一下, 一看傳回值是成功的, 就說這個接口就成功了.
實際上, 就一個簡單的 添加資料,
- 資料的接口, 是給出接口需要的參數, 然後調用接口
- 看接口的傳回值, 是成功的, 還是失敗的.
- 在看接口儲存資料的地方, mysql , mongDB 等等的中的一個, 看資料是否儲存進去.
-
在調用查詢接口看這條資料能夠白查詢出來
看上去複雜的4步, 但是用 python腳本來執行的話, 執行下來,連 1秒鐘都用不上.
用例要怎麼設計, 腳本要怎麼寫, 執行結果要怎麼看, 我後邊會慢慢的更新, 求大家給個關注 謝謝了