重讀《從菜鳥到測試架構師》-- 單元測試測點啥

 

上回說到，小艾寫了一段產品代碼，卻因爲未作好單元測試而致使過多細微的bug流入到了功能測試階段，通過組長一番諄諄教誨，小艾明白了單元測試是什麼，誰來作單元測試以及爲何要作單元測試，但是對於單元測試測什麼，怎麼測卻依然毫無頭緒……

 

搖籃有多大——單元測試的範圍

單元測試須要保證：覆蓋到全部新開發代碼、修改代碼及受影響的代碼。

    覆蓋代碼全部分支，包括正常路徑及錯誤路徑

    覆蓋全部有效輸入/輸出狀況

    覆蓋無效的或預期外的輸入/輸出狀況

    覆蓋全部的日誌文件和返回代碼

    如有出錯恢復步驟，確保其正確

    驗證代碼的邏輯正確

    爲知足國際化要求，確保包含虛擬翻譯的build環境中經過測試

    對敏感代碼要測試其性能，如有必要，需描述代碼路徑及對數據庫的訪問

    單元測試須要在開發環境中完成

    修改全部可翻譯的代碼片斷，保證無錯誤

對於Java等代碼源文件，須要通過代碼審查，保證其知足代碼開發標準和編程規範~

 

有規範、有步驟地捉蟲子——單元測試的流程

單元測試開始的標誌：接到一份新的設計文檔或一個bug以後就要開始考慮單元測試了。

單元測試結束的標誌

    所有新增的代碼和更改的代碼都已經完成，且集成到代碼儲存庫

    代碼審覈完成

    全部單元測試已經執行並經過，用例集成到用例存儲庫

    全部的註釋已經在代碼中編寫且經過代碼審查

    全部已知的問題都已經獲得解決，或已經提出瞭解決遺留問題的下一步計劃

程序

1. 建立/修改代碼和相關文檔

2. 對新開發代碼或修改代碼進行單元測試

3. 代碼審覈

4. 版本控制

 

來一套殺蟲裝備：單元測試的工具

（做爲IBM的技術文章，書中是以JUnit來測試Java代碼的開源框架，因爲本人對Java不熟悉，也對JUnit不熟悉，在這篇代碼量佔比比較大的章節中，沒有打算一一敲代碼將其搬上來。若是對這一章節有興趣的朋友們，能夠上網搜尋JUnit的相關文章。固然，小編也並無偷懶哦，早在2015年4月，小編寫了一篇文章叫《利用單元測試框架進行單元測試》，固然，因爲小編使用的是C#語言，所以使用的是Visual Studio的測試模板，若是有興趣的話能夠查看這篇文章：http://www.cnblogs.com/Ribbon/p/4432455.html，這一章節的原文內容就此略過，敬請各位看官諒解。）

 

尾聲

在審覈單元測試報告時，需注意：

    手動的單元測試報告須要有詳細的步驟，包括使用到的數據集。

    自動化的單元測試報告不只要有運行結果，還要給出描述，說明這一組單元測試所測的是哪一部分的代碼。

而關於測試覆蓋率，須要保證：

    全部新增流程都已經被覆蓋到。

    覆蓋有效/無效的輸入/輸出

    覆蓋日誌信息

    覆蓋可接受性測試涉及的所有流程

    對於Services，覆蓋每個API.

    覆蓋全球化和國際化的要求

    沒法經過UI驗證的功能點，要在單元測試中覆蓋

 

小艾終於算是明白了單元測試的全過程了，而在工做過程當中，開發也愈發有效率的同時bug密度降低了，不過耦合度依然沒怎麼下降，忽然他隱約想起組長提到過測試驅動開發，好奇心起的小艾，因而又找到組長跟着學習了，那麼什麼是測試驅動開發，測試驅動開發又有什麼好處呢？咱們下回分解~

 

想要第一時間看到這一系列文章的更新及更多精彩內容能夠掃描下面二維碼關注微信公衆號: 倚樓聽風雨的如月