e2e測試
- 端對端測試 (End-to-end testing) (E2E testing)所謂的「端對端」(E2E) 是指從使用者的角度出發(一端)，對真實系統(另一端)進行測試。這種類型的測試對許多公司來說，就是「人工測試」的主要範圍，因為你可以透過人工對已經完整部屬的網站進行測試，因此可以驗證出系統是否符合客戶的實際需求。這部分也可以透過撰寫 E2E 測試程式來進行自動化，增加測試效率。這裡有個未通過 E2E 測試的案例相當有趣，雖然每個整套系統每個模組都通過所有單元測試與整合測試，但最後組裝起來後，從使用者的角度無法接受：
你可以看到，在大部分的公司裡，單元測試與整合測試固然重要，但卻最少人投入，一來學習測試開發有點門檻，需要花上一些時間熟悉與試錯；二來維護測試的過程，通常會隨著需求變更而導致成本大幅增加；第三，單元測試與整合測試都無法確保程式最終的執行結果是客戶真正要的，因為這兩種測試類型，一個是針對程式碼的最小單位進行測試，另一個是針對模組與模組之間的整合進行測試，就算測試結果是成功的，最終還是無法確保需求正確這件事。
端對端測試則完全不同，它以真實、完整的系統進行測試，從開啟瀏覽器開始，一步步的操作與輸入，並且讓瀏覽器與後端 API 進行互動，然後直接透過最終的顯示狀態來診斷其結果是否符合預期。如果測試結果正確，通常也意味著「需求正確」，因此這可以說是最容易讓客戶、老闆放心的測試類型。也是為什麼一般公司寧願不去寫單元測試、整合測試，卻願意投入端對端測試的原因。很可惜的是，大部分的端對端測試都是人工進行的！
撰寫測試程式的價值
其實並不是所有網站都值得撰寫測試，對於一個需求不確定、價值性不高的網站來說，撰寫測試就是浪費時間，任何類型的測試都一樣。
- 需求不確定有時候專案建置初期，在需求尚未明朗又必須交付成果的時候，撰寫測試就顯得不具意義，因為當需求改變時，測試程式肯定也要跟著改寫，開發成本也會跟著墊高。業界有很多人推廣 TDD (測試先行開發)，工程師可藉由撰寫測試程式碼來進一步釐清設計需求，從輔助設計的角度出發，的確是不錯的點子。但是這樣的點子不見得適用於所有專案類型，像是 PoC (驗證可行性) 的專案，對於設計架構上就沒有特別要求，這時後撰寫測試就會增加開發時間，反而降低業務競爭力 (因為拉長提案的時間)。
- 價值性不高網站的價值性，取決於網站經營者對價值的設定，其實跟工程師沒多大關係。我們都知道撰寫測試需時間，而時間就是金錢，當客戶、老闆不願意給予合理的工時撰寫測試，自然也就沒有撰寫測試的可能性。如果客戶不給足夠的人力資源，用戶不給足夠的開發時間，同時又要求高品質的軟體產出，你應該很清楚接下來該怎麼做了！市面上講授測試的書籍與課程都不少，但企業界實際導入測試開發的卻依然是寥寥無幾，你可以說大家所做的網站都不重要嗎？No! 那是因為價值的定位並不是你說重要就重要，最終還是依賴上位者如何感受撰寫測試的價值，當老闆感受不出價值，自然沒有投入自動化測試的必要。如果老闆知道叫個人把網站功能全部使用一遍 (端對端測試)，就能知道網站是否可用，那我想他會毫不遲疑的請個人去測一遍網站所有功能。因為這是他唯一能理解的價值呈現方式！
這三種不同類型的測試，其實也有不同的價值定位：
nightwatch
安裝nightwatch
-g代表全域安裝
-g代表全域安裝
npm install -g nightwatch
安裝成功
安裝 瀏覽器 driver
我們目前使用的版本是
版本 75.0.3770.142 (正式版本) (64 位元)
下載相對應版本 (你想要的相對應版本)
先放d槽
增加配置檔案
這邊可以看到 會
版本 75.0.3770.142 (正式版本) (64 位元)
下載相對應版本 (你想要的相對應版本)
先放d槽
增加配置檔案
這邊可以看到 會
module.exports = {
"webdriver": {
"server_path": "/usr/bin/safaridriver", // 浏览器 driver 的 bin 执行路径
"start_process": true, // 需要启动 driver
"port": 9515 // driver 启动的端口, 一般是 9515 或 4444
},
"test_settings": {
"default": {
"desiredCapabilities": {
"browserName": "safari" // 浏览器的名字叫 safari
}
}
}
}https://blog.miniasp.com/post/2019/02/18/Unit-testing-Integration-testing-e2e-testing
