前端進階之路: 前端架構設計(3) - 測試核心

可能不少人和我同樣, 首次聽到"前端架構"這個詞, 第一反應是: "前端還有架構這一說呢?" 在後端開發領域, 系統規劃和可擴展性很是關鍵, 所以架構師備受重視, 早在開發工做啓動以前, 他們就被邀請加入到項目中, 並且他們會跟客戶討論即將建成的平臺的架構要求, 使用還什麼技術棧? 內容類型是什麼? 這些內容如何被建立?軟件架構師的職責就是要保證項目中每一步都在整體架構的指導下進行, 而不會隨機決定.

如今的前端領域, 隨着JS框架, UI框架和各類庫的豐富, 前端架構也變得十分的重要. 若是一個大型項目沒有合理的前端架構設計, 那麼前端代碼可能由於不一樣的開發人員隨意的引入各類庫和UI框架, 致使代碼量變得異常臃腫, 最終結果多是代碼變得沒法維護, 頁面性能低下,不得已只能推翻重構. 因此咱們須要在項目開始前, 一樣的須要對前端代碼進行架構, 一旦前端架構師設計出全部前端開發人員都要遵循的檢驗機制, 創建起系統設計的規範, 那麼項目就擁有了能夠衡量代碼質量的標準, 前端開發人員也能享受到更高效的工做流. 因此, 前端架構的定義能夠用如下一句話來總結:

前端架構是一系列工具和流程的集合, 旨在提高前端代碼的質量, 並實現高效, 可持續的工做流.

本系列的前端架構文章, 將分別圍繞前端架構的四個核心展開, 分別是代碼, 流程, 測試, 文檔.

前端架構的四個核心

(一) 代碼

歸根到底, 全部的網站都是由一堆文本文件和資源文件組成的. 當咱們面對製做網站所產生的大量代碼時, 就會發現爲代碼和資源設定一個指望是多麼重要. 在代碼部分, 咱們會專一於若是實現系統架構中的HTML, CSS, JavaScript.

(二) 流程

如今早已過了FTP上傳文件的時代, 那麼如今重要的是思考怎麼用工具和流程構建一個高效且避免出錯的工做流. 工做流變得愈來愈複雜, 那些用於它們的工具也一樣如此. 這些工具在提升生產力, 加快效率和保持代碼一致性上帶來了驚人的效果, 但也伴隨着過分工程化和抽象化的風險. 因此, 現有的工做流是須要改變的.

(三) 測試

要構建一個可擴展和可持續優化的系統, 必須保證新代碼和老代碼可以很好的兼容. 咱們的代碼不會獨立存在, 它們都是大型系統中的一部分. 建立覆蓋面普遍的測試方案, 能確保老代碼還能正常運做.

(四) 文檔

通常而言, 若是不是團隊中的重要成員要離開, 咱們幾乎都不會意識到文檔的重要性. 等到那個時候, 你們將不得不停下手頭的工做, 優先編寫全部的文檔. 做爲前端機構師, 你要善於在項目開發的同時編寫良好的文檔.

測試核心

(一) 傳統手工測試的侷限性

軟件測試是在規定的條件下對程序進行操做, 以發現程序中的錯誤, 衡量軟件質量, 並對其是否能知足設計要求進行評估的過程, 軟件測試的目的是但願以最小的代價儘量多地找出軟件中潛在的錯誤和缺陷.

首先,測試人員會針對開發人員開發的功能寫出測試用例, 例如表單應該填入的數據, 頁面單擊順序, 以及最後頁面期待的效果, 而後, 測試人員會按照用例一步步進行手工校驗, 若是頁面行爲異常, 例如沒法打開頁面或生成的數據不許確, 則會在企業缺陷管理系統中提交缺陷記錄, 供開發人員進行修正. 在開發過程當中, 若是有新版本編譯出來, 測試人員須要根據測試用例從新測試, 確認是否有新缺陷, 或者老缺陷是否已經獲得了修正.

長久以來, 這種傳統手工測試在各大公司普遍應用, 並已被證實可以行知有效的保證產品質量, 但伴隨着互聯網技術的發展, 這種傳統的測試模式已經顯示出愈來愈多的瓶頸.

1. 重複性工做, 測試質量低

如今的互聯網產品開發研究的是短平快, 小步快走, 短則兩三天, 長則一星期就會發布新版本. 在這短短的時間裏, 測試人員須要把新版本部署到測試環境, 更新數據庫 而後對全部的測試用例進行手工校驗. 這個過程事件緊迫, 工做量大, 並且具備很高的機械性和重複性, 當測試人員長期工做在重複性的驗證事物上, 每每會由於思惟習慣而忽略新出現的問題, 最後致使不只測試人員自身缺少工做熱情, 並且測試質量更難以保證.

2. 測試效率低

手工測試天生就決定了它的執行效率很低, 測試人員須要根據測試用例逐行逐字閱讀, 而後在頁面上一步步填寫表單, 在單擊按鈕提交, 這是一個很是繁瑣的過程. 而遇到複雜的業務流程更是涉及方方面面, 做者甚至見過一個多小時都沒法完成的測試案例. 到了開發後期, 可能天天或每兩天就要發佈一個版本進行測試, 若是一個軟件系統的功能點有幾千甚至上萬個, 手工測試將特別耗時和繁瑣, 不只消耗了大量的人力, 還可能影響到產品的如期發佈.

3. 沒法保證覆蓋代碼全路徑

是否有良好的測試覆蓋是考覈測試成熟度的重要指標, 其核心思想是對相同的業務邏輯提供多組甚至幾十組輸入, 全面覆蓋到業務中的大多數路徑, 重點考察軟件的邊界行爲. 好比某個頁面輸入框的字符個數在開發中被限制爲256個字符, 但測試人員極可能漏掉這樣的極端輸入狀況. 因爲手工測試效率很低, 不要說進行幾十組數據的測試, 就是幾組可能都難以實施. 另外, 有些軟件缺陷須要在大量數據或者大量併發用戶的狀況下才會暴露, 很難經過手工測試保證代碼的全路徑覆蓋.

4. 沒法有效兼顧多瀏覽器, 多平臺

Web前端的測試環境複雜, 兼容性要求高, 特別是要同時兼顧多種操做系統, 包括Window, Mac OS和Linux, 以及不一樣的瀏覽器IE, Edege, Chrome, Safari等, 還要考慮移動端的IOS, Andorid等操做系統, 其排列組合以後將會是經過手工測試沒法企及的數字. 很難想象有那個公司可以投入巨大的人力成本完成如此龐大的手工測試.

(二）前端測試的分類

1. 單元測試(Unit Test)

在軟件開發過程當中, 最基本的測試就是單元測試, 這是針對程序單元(軟件設計的最小單位)來正確性檢驗的測試工做. 程序單元是應用的最小可測試部件. 在過程化編程中, 一個單元就是單個程序, 函數, 過程等; 對於面向對象編程, 最小單元就是方法. 在企業的質量控制體系中, 單元測試是由開發部門在軟件提交測試部門前完成.

單元測試的目標是打破程序單元間的依賴關係, 隔離單元並證實這些單個單元是正確的, 因此單元測試應該無依賴和隔離, 一般在單元測試中, 把系統的依賴組件提取出來, 用測試替身(Test Double)取而代之, 把單元測試把注意力集中放在測試"單元"的邏輯上面而不是和第三方系統的交互上.

2. 集成測試(Integration Test)

即便一個程序在單元測試中運做良好, 也不能肯定他們放在一塊兒能正常工做, 集成測試是取出應用程序裏能夠獨立運行的組件, 一般是一些單元的集合, 來測試這部分單元做爲一個總體的表現, 以驗證他們可否協調一致的運做. 集成測試通常位於單元測試以後 端到端測試以前.

例如一個常見的集成測試場景是使用數據組件對數據庫進行操做的測試. 測試人員須要安裝並配置好數據庫, 而後在數據庫裏插入預先準備好的數據, 再執行須要測試的組件, 運行完畢後檢驗數據庫裏的數據. 在這個測試場景中, 被測單元依賴數據庫訪問模塊, 因此它不是一個單元測試. 可是它也沒有模擬一個完整的用戶真實場景, 因此它也不是一個端到端的測試.

3. 端到端測試(End-to-End Test)

端到端測試(一般縮寫爲E2E)是把產品或服務當作一個總體進行驗證, 典型的作法是模擬真實的用戶場景, 經過與系統的需求定義作比較, 來發現產品和需求定義不符合或存在矛盾的地方, 其最終目的是爲了發佈產品. 例如在Web應用程序中, 測試人員會啓動服務器, 打開瀏覽器, 訪問被測網頁, 並操做網頁上須要測試的功能, 檢查瀏覽器中發生的特定的事件, 以確保被測功能能夠正常運行.

端到端測試一般由測試部門完成, 通常有如下特性:

• 須要搭建專門的測試環境模擬真實的用戶場景, 成本較高
• 測試用例複雜, 運行時間長
• 一旦測試發現問題, 因爲涉及的模塊比較多, 定位問題難度較高

端到端測試能夠手工完成, 也能夠變現測試框架和測試代碼自動執行. 在Web前端應用中, 端到端測試一般從用戶界面開始, 覈實用戶與應用之間的交互, 確保用戶界面向用戶提供了適當的訪問測試對象功能的操做, 同時還要確保內部的對象符合預期要求. 若是進行手工測試的話, 效率低下, 沒法知足快速迭代的Web前端應用的測試需求, 因此迫切須要將Web前端應用的端到端測試自動化.

(三)測試驅動開發的理念(TDD: Test-Driven Development)

1. TDD的優點

TDD的基本思路就是經過測試來推進整個開發的進行。而測試驅動開發技術並不僅是單純的測試工做。

需求向來就是軟件開發過程當中感受最很差明確描述、易變的東西。這裏說的需求不僅是指用戶的需求，還包括對代碼的使用需求。不少開發人員最懼怕的就是後期還要修改某個類或者函數的接口進行修改或者擴展，爲何會發生這樣的事情就是由於這部分代碼的使用需求沒有很好的描述。測試驅動開發就是經過編寫測試用例，先考慮代碼的使用需求（包括功能、過程、接口等），並且這個描述是無二義的，可執行驗證的。

經過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設計。並且這種從使用角度對代碼的設計一般更符合後期開發的需求。可測試的要求，對代碼的內聚性的提升和複用都很是有益。所以測試驅動開發也是一種代碼設計的過程。

開發人員一般對編寫文檔很是厭煩，但要使用、理解別人的代碼時一般又但願能有文檔進行指導。而測試驅動開發過程當中產生的測試用例代碼就是對代碼的最好的解釋。

快樂工做的基礎就是對本身有信心，對本身的工做成果有信心。當前不少開發人員卻常常在擔憂：「代碼是否正確？」「辛苦編寫的代碼還有沒有嚴重bug？」「修改的新代碼對其餘部分有沒有影響？」。這種擔憂甚至致使某些代碼應該修改卻不敢修改的地步。測試驅動開發提供的測試集就能夠做爲你信心的來源。

固然測試驅動開發最重要的功能還在於保障代碼的正確性，可以迅速發現、定位bug。而迅速發現、定位bug是不少開發人員的夢想。針對關鍵代碼的測試集，以及不斷完善的測試用例，爲迅速發現、定位bug提供了條件。

2. TDD的原理

測試驅動開發的基本思想就是在開發功能代碼以前，先編寫測試代碼。也就是說在明確要開發某個功能後，首先思考如何對這個功能進行測試，並完成測試代碼的編寫，而後編寫相關的代碼知足這些測試用例。而後循環進行添加其餘功能，直到徹底部功能的開發。

3. TDD的過程

測試驅動開發的基本過程以下：

• 明確當前要完成的功能。能夠記錄成一個 TODO 列表。
• 快速完成針對此功能的測試用例編寫。
• 測試代碼編譯不經過。
• 編寫對應的功能代碼。
• 測試經過。
• 對代碼進行重構，並保證測試經過。
• 循環完成全部功能的開發。

(四) 測試工具推薦

1. Jasmine

Jasmine應該算是最成熟的Javascript測試框架，它自帶斷言和測試執行環境, 並有擁有靈巧而明確的語法可讓你輕鬆的編寫測試代碼。

2. Mocha

Mocha一樣也是一個前端框架, 它上手簡單且有豐富的插件.若是想學習的, 能夠看一下阮一峯的教程:測試框架 Mocha 實例教程

3. Karma

Karma是由Google團隊開發的一個測試工具, 它不是一個測試框架, 只是一個跑測試的驅動. 你能夠經過karma的配置文件集合你喜歡的框架, 斷言庫和瀏覽器.

---

參考資料

1. Web前端測試與集成——Jasmine/Selenium/Protractor/Jenk
2. IBM: 測試驅動開發(TDD)