引用谷歌上的壹篇論文《The ML Test Score》來回答，在這篇論文裏，谷歌總結了非常具體的機器學習系統相關工程實踐準則，其中就包含了特征與數據測試。
特征期望值編寫到schema中：很多特征的分布情況或數值期望是有壹些先驗知識可以去校驗的。比如壹般人身高都在0-3米的範圍內、英語中最常見的詞是”the”、整體的詞頻壹般服從冪律分布等。我們可以把這些先驗領域知識，或是從訓練集中計算出的數學期望值編寫在數據schema文件中，後續對於新的輸入數據，構建完特征後的模型訓練數據以及最終上線使用模型時都能進行自動化的檢查，避免因為數據不符合預期而導致的錯誤預測情況。
確保所有的特征都是有用的：在之前的機器學習技術債論文中也有提到研發人員總是傾向於不斷往系統中添加新的特征，尤其在上線時間比較緊迫的情況下，缺少細致的特征選擇和有效性驗證工作。這會導致特征數量越來越多，構建訓練集需要花費的時間也越來越長，後續的維護成本也會更高。所以跟業務代碼壹樣，沒有幫助的特征也要及時清理，輕裝前行。文中給出的方法基本是常見的特征選擇法，比如計算特征相關度，使用單獨或小批量特征來跑模型看是否有預測能力等。
去除性價比低的特征：計算添加任何壹個特征都需要消耗資源，包括生成和訓練模型開銷，模型預測開銷，甚至還要考慮到對上遊數據的依賴，額外的庫函數引入，特征本身的不穩定性等等。對於任何壹個特征的添加，都要綜合考慮這些開銷與它能帶來的性能提升來決定是否引入。如果只是非常有限的效果提升，我們應該果斷放棄那些過於復雜的特征。
特征必須遵循業務規範需求：不同的項目對機器學習系統可以使用的數據可能有不同的規範需求，比如可能有些業務禁止我們使用從用戶數據中推演出來的特征。所以我們也需要從代碼工程層面把這些規範需求進行實現，以避免訓練與線上特征出現不壹致或違反了業務規範等問題。
數據流水線必須有完善的隱私控制：與上壹條類似，機器學習系統從數據源獲取用戶相關隱私數據時已經通過了相應的控制校驗，後續在系統內部流水線做處理時我們也要時刻註意對隱私數據的訪問控制。比如各種中間數據集，數據字典的存放與訪問控制，上遊系統的用戶數據刪除能夠級聯更新到機器學習系統的整個鏈路中，諸如此類需要特別註意的問題。
能夠快速開發新特征：壹個新特征從提出到實現，測試，上線的整個流程所需要花費的時間決定了整個機器系統叠代演進，響應外部變化的速度。要實現這壹點，良好的工程結構、不同模塊的抽象設計都是非常重要的。文中沒有給具體的例子，不過我們可以借鑒sklearn中pipeline模塊設計的思想，以及類似FeatureHub這樣的開源系統的實現來不斷優化完善特征工程實踐。
為特征工程代碼寫相應的測試：在實驗探索階段，我們經常會寫完壹個特征之後，粗略地取樣壹些數據，大致驗證通過後就認為這個特征基本沒有問題了。但這其中可能就隱藏了不少bug，而且不像業務代碼中的錯誤，要發現這些bug極其困難。所以必須養成良好的習慣，在特征開發階段就寫好相應的測試代碼，確保特征的正確性，後續應對各種系統變更也都能很快通過測試來進行快速驗證。
以上。希望對題主有幫助。