目錄

三、單元測試

四、安全規約

---

三、單元測試

1. 【強制】 好的單元測試必須遵守 AIR 原則。
說明： 單元測試在線上運行時，感覺像空氣（ AIR）一樣并不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重復執行的特點。
? A： Automatic（自動化）
? I： Independent（獨立性）
? R： Repeatable（可重復）

2. 【強制】 單元測試應該是全自動執行的，并且非交互式的。測試用例通常是被定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。
單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。

3. 【強制】 保持單元測試的獨立性。為了保證單元測試穩定可靠且便于維護，單元測試用例之間決不能互相調用，也不能依賴執行的先后次序。
反例： method2 需要依賴 method1 的執行， 將執行結果作為 method2 的輸入。

4. 【強制】 單元測試是可以重復執行的，不能受到外界環境的影響。
說明： 單元測試通常會被放到持續集成中，每次有代碼 check in 時單元測試都會被執行。如果單測對外部環境（網絡、服務、中間件等） 有依賴，容易導致持續集成機制的不可用。
正例： 為了不受外界環境影響，要求設計代碼時就把 SUT 的依賴改成注入，在測試時用 spring 這樣的 DI框架注入一個本地（內存）實現或者 Mock 實現。

5. 【強制】 對于單元測試，要保證測試粒度足夠小，有助于精確定位問題。單測粒度至多是類級別，一般是方法級別。
說明： 只有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯，那是集成測試的領域。

6. 【強制】 核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。
說明： 新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。

7. 【強制】 單元測試代碼必須寫在如下工程目錄： src/test/java，不允許寫在業務代碼目錄下。
說明： 源碼編譯時會跳過此目錄，而單元測試框架默認是掃描此目錄。

8. 【推薦】 單元測試的基本目標：語句覆蓋率達到 70%；核心模塊的語句覆蓋率和分支覆蓋率都要達到 100%
說明： 在工程規約的應用分層中提到的 DAO 層， Manager 層，可重用度高的 Service，都應該進行單元測試。

9. 【推薦】 編寫單元測試代碼遵守 BCDE 原則，以保證被測試模塊的交付質量。
? B： Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。
? C： Correct，正確的輸入，并得到預期的結果。
? D： Design，與設計文檔相結合，來編寫單元測試。
? E： Error，強制錯誤信息輸入（如：非法數據、異常流程、業務允許外等），并得到預期的結果。

10.【推薦】 對于數據庫相關的查詢，更新，刪除等操作，不能假設數據庫里的數據是存在的，或者直接操作數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。
反例： 刪除某一行數據的單元測試，在數據庫中，先直接手動增加一行作為刪除目標，但是這一行新增數據并不符合業務插入規則，導致測試結果異常。

11.【推薦】 和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成臟數據。或者對單元測試產生的數據有明確的前后綴標識。
正例： 在企業智能事業部的內部單元測試中，使用 ENTERPRISE_INTELLIGENCE _UNIT_TEST_的前綴來標識單元測試相關代碼。

12.【推薦】 對于不可測的代碼在適當的時機做必要的重構，使代碼變得可測，避免為了達到測試要求而書寫不規范測試代碼。

13.【推薦】 在設計評審階段，開發人員需要和測試人員一起確定單元測試范圍，單元測試最好覆蓋所有測試用例。

14.【推薦】 單元測試作為一種質量保障手段，在項目提測前完成單元測試， 不建議項目發布后補充單元測試用例。

15.【參考】 為了更方便地進行單元測試，業務代碼應避免以下情況：
? 構造方法中做的事情過多。
? 存在過多的全局變量和靜態方法。
? 存在過多的外部依賴。
? 存在過多的條件語句。
說明： 多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。

16.【參考】 不要對單元測試存在如下誤解：
? 那是測試同學干的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
? 單元測試代碼是多余的。 系統的整體功能與各單元部件的測試正常與否是強相關的。
? 單元測試代碼不需要維護。一年半載后，那么單元測試幾乎處于廢棄狀態。
? 單元測試與線上故障沒有辯證關系。好的單元測試能夠最大限度地規避線上故障。

四、安全規約

1. 【強制】 隸屬于用戶個人的頁面或者功能必須進行權限控制校驗。
說明： 防止沒有做水平權限校驗就可隨意訪問、 修改、刪除別人的數據，比如查看他人的私信內容、修改他人的訂單。

2. 【強制】 用戶敏感數據禁止直接展示，必須對展示數據進行脫敏。
說明： 中國大陸個人手機號碼顯示為:137****0969，隱藏中間 4 位，防止隱私泄露。

3. 【強制】 用戶輸入的 SQL 參數嚴格使用參數綁定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 訪問數據庫。

4. 【強制】 用戶請求傳入的任何參數必須做有效性驗證。
說明： 忽略參數校驗可能導致：
? page size 過大導致內存溢出
? 惡意 order by 導致數據庫慢查詢
? 任意重定向
? SQL 注入
? 反序列化注入
? 正則輸入源串拒絕服務 ReDoS
說明： Java 代碼用正則來驗證客戶端的輸入，有些正則寫法驗證普通用戶輸入沒有問題，但是如果攻擊人員使用的是特殊構造的字符串來驗證，有可能導致死循環的結果。

5. 【強制】 禁止向 HTML 頁面輸出未經安全過濾或未正確轉義的用戶數據。

6. 【強制】 表單、 AJAX 提交必須執行 CSRF 安全驗證。
說明： CSRF(Cross-site request forgery)跨站請求偽造是一類常見編程漏洞。對于存在 CSRF 漏洞的應用/網站，攻擊者可以事先構造好 URL，只要受害者用戶一訪問，后臺便在用戶不知情的情況下對數據庫中用戶參數進行相應修改。

7. 【強制】 在使用平臺資源，譬如短信、郵件、電話、下單、支付，必須實現正確的防重放的機制，如數量限制、疲勞度控制、驗證碼校驗，避免被濫刷而導致資損。
說明： 如注冊時發送驗證碼到手機，如果沒有限制次數和頻率，那么可以利用此功能騷擾到其它用戶，并造成短信平臺資源浪費。

8. 【推薦】 發貼、評論、發送即時消息等用戶生成內容的場景必須實現防刷、文本內容違禁詞
過濾等風控策略。
?

總結

以上是生活随笔為你收集整理的熟读《阿里巴巴java开发手册》（三、单元测试，四、安全规约）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。