阿里java開發規范---日志規約，單元測試，安全規約

 

(二)日志規約

1. 【強制】應用中不可直接使用日志系統（Log4j、 Logback） 中的 API，而應依賴使用日志框架
SLF4J 中的 API，使用門面模式的日志框架，有利於維護和各個類的日志處理方式統一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);
2. 【強制】日志文件至少保存 15 天，因為有些異常具備以“周”為頻次發生的特點。
3. 【強制】應用中的擴展日志（如打點、臨時監控、訪問日志等） 命名方式：
appName_logType_logName.log。
logType:日志類型， 如 stats/monitor/access 等； logName:日志描述。這種命名的好處：
通過文件名就可知道日志文件屬於什么應用，什么類型，什么目的，也有利於歸類查找。
正例： mppserver 應用中單獨監控時區轉換異常，如：
mppserver_monitor_timeZoneConvert.log
說明： 推薦對日志進行分類， 如將錯誤日志和業務日志分開存放，便於開發人員查看，也便於
通過日志對系統進行及時監控。
4. 【強制】對 trace/debug/info 級別的日志輸出，必須使用條件輸出形式或者使用占位符的方
式。
說明： logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
如果日志級別是 warn，上述日志不會打印，但是會執行字符串拼接操作，如果 symbol 是對象，
會執行 toString()方法，浪費了系統資源，執行了上述操作，最終日志卻沒有打印。
正例： （條件） 建設采用如下方式
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
正例： （占位符）
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
5. 【強制】避免重復打印日志，浪費磁盤空間，務必在 log4j.xml 中設置 additivity=false。
正例： <logger name="com.taobao.dubbo.config" additivity="false">
6. 【強制】異常信息應該包括兩類信息：案發現場信息和異常堆棧信息。如果不處理，那么通過
關鍵字 throws 往上拋出。
正例： logger.error(各類參數或者對象 toString() + "_" + e.getMessage(), e);
7. 【推薦】謹慎地記錄日志。生產環境禁止輸出 debug 日志； 有選擇地輸出 info 日志； 如果使
用 warn 來記錄剛上線時的業務行為信息，一定要注意日志輸出量的問題，避免把服務器磁盤
撐爆，並記得及時刪除這些觀察日志。
說明： 大量地輸出無效日志，不利於系統性能提升，也不利於快速定位錯誤點。 記錄日志時請
思考：這些日志真的有人看嗎？看到這條日志你能做什么？能不能給問題排查帶來好處？
8. 【推薦】可以使用 warn 日志級別來記錄用戶輸入參數錯誤的情況，避免用戶投訴時，無所適
從。如非必要，請不要在此場景打出 error 級別，避免頻繁報警。
說明： 注意日志輸出的級別， error 級別只記錄系統邏輯出錯、異常或者重要的錯誤信息。
9. 【推薦】盡量用英文來描述日志錯誤信息，如果日志中的錯誤信息用英文描述不清楚的話使用
中文描述即可，否則容易產生歧義。 國際化團隊或海外部署的服務器由於字符集問題，【強制】
使用全英文來注釋和描述日志錯誤信息。

三、單元測試

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. 【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成臟數據。或者
對單元測試產生的數據有明確的前后綴標識。
正例： 在 RDC 內部單元測試中，使用 RDC_UNIT_TEST_的前綴標識數據。
12. 【推薦】對於不可測的代碼建議做必要的重構，使代碼變得可測，避免為了達到測試要求而
書寫不規范測試代碼。
13. 【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試范圍，單元測試最好
覆蓋所有測試用例。
14. 【推薦】單元測試作為一種質量保障手段，不建議項目發布后補充單元測試用例，建議在項
目提測前完成單元測試。
15. 【參考】為了更方便地進行單元測試，業務代碼應避免以下情況：
 構造方法中做的事情過多。
 存在過多的全局變量和靜態方法。
 存在過多的外部依賴。
 存在過多的條件語句。
說明： 多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。
16. 【參考】不要對單元測試存在如下誤解：
 那是測試同學干的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。
 單元測試代碼是多余的。 系統的整體功能與各單元部件的測試正常與否是強相關的。
 單元測試代碼不需要維護。一年半載后，那么單元測試幾乎處於廢棄狀態。
 單元測試與線上故障沒有辯證關系。好的單元測試能夠最大限度地規避線上故障。

 

 

四、安全規約

1. 【強制】 隸屬於用戶個人的頁面或者功能必須進行權限控制校驗。
說明： 防止沒有做水平權限校驗就可隨意訪問、 修改、刪除別人的數據，比如查看他人的私信
內容、修改他人的訂單。
2. 【強制】用戶敏感數據禁止直接展示，必須對展示數據進行脫敏。
說明： 中國大陸個人手機號碼顯示為:158****9119，隱藏中間 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. 【推薦】發貼、評論、發送即時消息等用戶生成內容的場景必須實現防刷、文本內容違禁詞過

濾等風控策略