事件的起因在於老闆最近的兩次「故障」，一次去年的，一次最近。共同原因都是腳手架在發布平台發布打包時出錯，導致線上應用白屏不可用。
最神奇的是，事後多次 code review，結果還是沒有發現任何能夠導致該問題的 bug，最後推測有可能是伺服器在發布打包的時候出了問題。
當老闆第 n + 1 次吐槽因為他寫的工程化工具領來的天外飛鍋，我突然思考起來，如何才能避免這種天外飛鍋。
歸根結底，導致這類線上故障的原因都是在於打包上線的**沒有經過驗證。針對這個問題，有兩種方法可以解決：
治本，由於請求位址不同，預發（測試）版本不可直接發線上，而線上版本缺少了上線之前的驗證過程。所以，可以通過在發布系統的預發和線上之間，新增乙個 beta 發布，beta 發布使用線上發布的打包流程，不同的是，只允許內網訪問，專門用於內部測試。有人可能會問，哪怕新增了 beta 發布，依然無法保證線上發布重新打包的時候不出錯呀？重點來了，這種解決方案的核心就在於，beta 發布測試通過後，直接將 beta 發布的打包產物進行線上發布，因為不需要二次打包，所以避免了打包過程中產生新的問題。由於新增 beta 發布需要不同崗位，比如運維、後端、移動端的協作，所以實施難度較大。
治標，既然線上版本上線之前驗證不了，那麼上線之後立刻回歸驗證，如果發現問題，立刻手動回滾。正所謂沒有人發現的故障就不是故障，perfect！
正如之前所說的，治本的方法實施難度較大，所以，我們重點關注治標的方法，即上線之後進行回歸驗證。
說到這裡，問大家乙個問題，需求上線之後，作為前端，大家會主動進行回歸驗證而不是等測試進行驗證嗎？
不管你們會不會，反正我是不會[doge]。
在這種情況下，前端 ui 自動化測試閃亮登場。
眾所周知，測試是乙個很重要的環節，由於它的重要性，甚至軟體工程**現了 tdd 這種說法。
在之前，所謂的前端測試，更多的是在頁面上點點點，進行人肉測試，毫無疑問，效率低下。
所以，有了前端自動化測試，使用機器代替人工。一般來說，前端自動化測試分為兩種：單元測試以及 e2e 測試（ui 自動化測試）。
單元測試本質上是一種白盒測試，是對程式中的最小可測試單元進行測試。
e2e 測試本質上是一種黑盒測試，相當於模擬使用者訪問應用程式，主要檢查介面或功能是否正確。
相比於單元測試，ui 自動化測試更多的是站在使用者角度，從使用者的角度發現問題。但是，由於它其實是一種黑盒測試，所以效率相對於白盒測試要低一些。
selenium：e2e 測試鼻祖級的框架，有多種程式語言的版本，如果你去問問你們公司的測試，那麼你一定會發現，他們正在用 python 版本的 selenium 寫自動化測試指令碼。值得一提的是，它是基於 webdriver 而不是 webkit 核心實現的，所以，selenium 的瀏覽器相容性相對於其他瀏覽器要好很多。
phantomjs：開創性的 headless（無頭）測試框架，何為 headless？即沒有 ui 介面的瀏覽器。headless 最大好處在於可以像單元測試一樣，在命令列中跑 e2e 測試。
nightmare：一句話——加強版的 phantomjs，相對於 phantomjs，無論是開發還是執行效率都得到了很大的提公升。
tips：nightmare 還有個優點——它提供了乙個 chrome 外掛程式 daydream，該外掛程式可以通過錄製螢幕，自動化生成測試**，懶人福音。
nightwatch：名字和 nightmare 很像，但是完全不一樣的乙個 e2e 框架，使用 node 呼叫 webdriver 實現。相對於 selenium，開發和執行效率更高，最重要的是，迭代很活躍，這點，用開源產品的使用者懂得都懂。
cypress：我接觸的第乙個 e2e 測試框架，測試介面和文件做到極致的乙個產品，推薦大家可以試一試。
puppeteer：e2e 測試框架的集大成者，預設以 headless 模式執行，但是也可以通過配置變為 chromium 執行。開發效率以及執行效率一流，最重要的是，它像 nightmare 一樣，提供了測試**生成外掛程式——puppeteer-recorder。
綜上所述，如果考慮瀏覽器相容性，使用 nightwatch，反之，選擇 cypress 或者 puppeteer，如果需要 headless 或者自動化生成**的功能，那就使用 puppeteer。
從自動化測試的收益來說，自動化測試有個公式：
簡而言之，迭代越頻繁，維護成本越高的專案，新增自動化測試的價值越高。在基建專案或頻繁迭代專案中引入前端 ui 自動化測試，可以大大減少每次迭代後手動測試的時間。比起手動測試，前端 ui 自動化測試測試的更快也更徹底。自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本複製**
另乙個方面，隨著前端技術的高速發展，各個公司的前端開發、監控體系已經很完善了，但是缺少前端在測試方向上的延伸。而前端 ui 自動化測試最大的價值，就是在前端部分，彌補開發和監控之間的空白區域，形成乙個完整的閉環，三管齊下，極大地保障了專案的質量。
針對前端 ui 自動化測試，我思考了很久，個人認為主要有兩大方向：
針對單個專案，進行一系列關鍵功能的測試，不過如果需要追求測試覆蓋率的話，比較耗費時間，算是一種比較常規、精細的測試方案，所以比較適合一些長期維護的基建專案或者大型業務專案，缺點在於活動頁基本覆蓋不了。
針對所有專案，新增乙個自動化測試的腳手架（或者平台化），能夠通過配置項，自動訪問目標頁面，並進行一系列的 e2e 測試，根據不同的結果採取截圖、生成 pdf、報警等不同處理方案。
第二個方案，即通用化方案也是我最近開發的重點方向，接下來我應該會專門寫一篇文章，大概介紹下該方案的設計以及具體實現（如果我沒有懶癌發作的話[doge]）。
一次自動化測試面試總結
最近都是在面試，今天去某安公司面自動化測試工程師，因為感覺面試官問的問題大體還是挺有含金量的，趁熱總結一下！首先是有乙個筆試，筆試題目大致都是測試基礎 sql語句 下面是面試啦 首先是乙個自我介紹啦。我大致講的就是一些測試經歷，著重講了一下最近的乙份工作和自動化測試經歷，還沒講完，面試官可是是開啟了...
Airtest是乙個跨平台的UI自動化測試框架
airtest提供了跨平台的api，包括安裝應用 模擬輸入 斷言等。基於影象識別技術定位ui元素，你無需嵌入任何 即可進行自動化測試。測試指令碼執行後可以自動生成詳細的html測試報告，讓你迅速定位失敗的測試點。airtestide 是乙個強大的gui工具，可以幫助你錄製和除錯測試指令碼。airte...
Python自動化，一次完整的登陸測試
網頁的登陸測試 coding utf 8 登入測試，分下面幾種情況 1 使用者名稱 密碼正確 2 使用者名稱正確 密碼不正確 3 使用者名稱正確 密碼為空 4 使用者名稱錯誤 密碼正確 5 使用者名為空 密碼正確 importunittest fromseleniumimportwebdriver ...