“小光，今天那個詭異的生產環境問題找到原因了嗎？”
“還是資料問題！之前做的一個功能有一部分資料遷移工作沒有做好，導致生產環境有髒資料，委託人的聯絡人已經不為該委託人服務了，應該移除掉的……”
“又是髒資料……”
“嗯，好在不是程式碼問題。”
這是在藍鯨專案發生的真實對話。其中提到的髒資料（Dirty data），也叫壞資料（Bad data），通常是指跟期待的資料不一樣、會影響系統正常行為的資料。
藍鯨專案的QA會定期分析生產環境的缺陷，當定位某個缺陷為髒資料引起之後，往往就到此為止了。生產環境下的缺陷分析流程是這樣的：
調查分析生產環境缺陷，到最後定位是資料問題的時候，總是讓人渾身輕鬆... 於是，“髒資料”就跟測試的“隨機掛”一樣，成為了光榮的“背鍋俠”！
髒資料 ≠ 程式碼問題，真的是這樣嗎？先來深入瞭解一下髒資料。
髒資料是怎麼回事？
髒資料產生的原因多種多樣，有的甚至很難解釋清楚到底發生了什麼…
通常，以下原因可能造成髒資料：
- 髒讀：讀了事務處理中間狀態的資料
- 重複插入了相同的資料：多次點選同一個按鈕導致
- 不能為空的欄位存為空：資料庫欄位沒有驗證，或者對於歷史資料沒有做好遷移處理
- 人工錄入不合法的資料：比如電話號碼含有特殊字元
- 執行SQL指令碼插入了不合法資料：比如不同實體id搞混等
- 存入了多餘的空格
- 測試環境可能由於部署了半成品產生一些不合法資料
- ……
因此，髒資料跟程式碼有關，髒資料的產生是因為沒有做好防禦工作！
髒資料有哪些危害？
根據不同的系統、不同的業務，髒資料帶來的危害也會不一樣。
- 髒讀產生的資料往往是錯誤的，導致資料不真實性，或者資料的不一致性；
- 重複和其他不合法資料則可能導致系統行為的不正常，有時候還可能導致非常嚴重的故障，甚至有些沒有暴露的髒資料可能帶來不可預知的致命錯誤，危害可能是相當大的。
髒資料帶來的危害很難估量，有很大的不可預測性，對於髒資料的預防至關重要。
那麼，如何能夠防範於未然呢？
如何預防髒資料的產生？
嘗試對髒資料引起的生產環境缺陷做進一步分析，總結出髒資料的幾種型別，可以在敏捷軟體開發生命週期的不同階段對其進行防禦。
業務需求分析階段
在業務分析的時候，根據業務需求，明確業務相關資料的特定要求：
- 不能為空的欄位
- 不能重複的資料
- 日期範圍
- 電話號碼可以有“ext.”、“+”和“-” 但不能有其他字元
- 特殊字元的限定
- 功能升級的時候考慮已有資料的遷移
- 還有一些跟常識不同有特定業務含義的資料需求
- ……
資料庫和程式碼實現階段
明確了資料的需求，可以根據需求定義和軟體使用常識，在實現層面對資料進行嚴格的約束和校驗：
- 資料庫表的主外來鍵、欄位型別、是否允許為空，事務處理隔離等
- 前後端對資料進行嚴格的校驗，防止各種手段存入不合法的資料，包括需求定義的資料和常識性的資料，比如身份證號碼最多18位等
- 考慮多使用者同時處理可能帶來的併發問題
- 防止按鈕或者連結被重複多次點選，可重複點選通常在網速較慢時可能存入重複資料
- 程式讀取資料的時候進行處理，比如去掉多餘空格、去重、大小寫不敏感資料的處理
- ……
測試的進一步保障
有了需求定義和實現層面的校驗，大部分的不合法資料被阻止了，但是還是會有漏網之魚，在測試的時候繼續採取相應的措施來進一步防禦。
- 業務需求規定的資料：這個毫無疑問是需要測試的，有底層的單元測試覆蓋會更好
- 常識性的資料：由於不同的人可能有不同的常識，這些問題在測試的時候還需要特別關注
- 探索隱藏邊界：關於隱藏邊界的概念大家可能不是很熟悉。我們們通常說的等價類、邊界值分析方法設計測試用例，都是根據可見的邊界來考慮的，其實我們們程式後臺可能還存在一些隱藏的邊界，也是很有可能會導致資料問題的，需要在測試過程中進行探索發現它們並進行驗證。
關於隱藏邊界，可以參考John Ruberto的文章《Uncovering Hidden Boundary Values in Testing》，裡邊提到了四種隱藏邊界：資料型別邊界、信任域邊界、特殊資料值、復活節彩蛋。除此之外，我們們平常測試過程中可以多積累，總結出還有哪些可能會導致資料問題的隱藏邊界。
對線上使用者的培訓
做了前面一層層的防禦，如果終端使用者在使用的時候能夠按照規範運算元據，對減少髒資料的產生會很有幫助。
下面兩個措施可以培訓使用者更規範的運算元據：
- 在介面上給出清晰的提示，告訴使用者某些資料輸入的要求
- 給使用者培訓或者提供使用者手冊，告訴使用者該怎麼正確使用系統
如何處理已產生的髒資料？
有那麼多預防髒資料產生的方法，但相信髒資料的產生還是在所難免的。髒資料一旦產生，導致的系統行為也是不可預測的，可能無足輕重，也可能暴露非常嚴重的缺陷。該如何應對產生的髒資料呢？
髒資料產生以後有兩種存在形式，一種是已經引起某些問題被發現了，另一種是還不被人知道，不知道哪天會發生什麼樣的問題。
已經暴露的髒資料
對於已經暴露的髒資料，首要的是對資料的快速修復，讓系統恢復正常運轉。對於專業的髒資料處理可以瞭解一下資料清洗（Data cleaning）技術。我們們平常對於髒資料的修復，可以根據業務需求，採用資料庫指令碼修復，或者在前端執行JS指令碼來修復。
修復資料需要特別注意不要引入新的髒資料，編寫指令碼之前要理清相關業務和資料之間的關係，編寫好指令碼之後要經過嚴格的測試才能線上上環境執行。
修復資料的同時，需要進一步調查資料產生的原因，檢查可以在哪個環節加固防禦措施，以儘量減少類似資料問題再次發生的可能性。
未暴露的髒資料
這樣的資料，其實我們並不知道它的存在，就像一個在黑暗處的幽靈，不知道什麼時候會給系統帶來麻煩。
由於系統環境的複雜性、使用者行為的多樣性，生產環境更加容易產生髒資料。儘早發現這種潛在危害的髒資料非常重要。
藍鯨專案就是這樣。在跟客戶做支援的同事溝通過程中，最大的擔憂就是生產環境的資料總能發現問題，如何能夠讓這些問題儘早暴露出來？
推薦生產環境下的測試（Testing in production，TiP）的一些實踐。
1.直接在生產環境測試
生產環境是高度受保護的，不可以隨意測試，以免破壞生產環境的穩定性。在生產環境寫入資料要特別謹慎，大批量的讀操作也要注意對系統效能的影響。
有些可以隔離出來的功能或操作，相對來說是安全的，可以在生產環境直接測試。比如，藍鯨專案的郵件服務，常會在生產環境部署單獨的伺服器來測試。
需要根據專案真實情況去做決定。
2.將生產環境資料清理後用於測試環境
生產環境資料含有PII（個人身份資訊，需要保護的隱私資訊）或者其他機密，通常不能直接用於測試環境。
將生產環境資料的PII和其他機密資訊清除後用於測試環境，測試人員基於這些資料做測試，就能有效的提前去發現由於生產環境資料引起的問題。
這個方案很好，但是要權衡ROI。對於一些複雜的系統，資料庫結構過於複雜，清理的成本太高，也是不太現實的。
3.利用藍綠部署等TiP實踐
藍綠部署是一種通過執行兩個相同的生產環境“藍環境”和“綠環境”來減少停機時間和風險的技術，是TiP非常典型的一個實踐。
在任何時候，只有一個環境是活的，活的環境為所有生產流量提供服務。通常綠環境是閒置的，藍環境是活的。部署新的版本到綠環境，可以先進行測試，而不會給真正在使用的藍環境帶來影響。完成部署和測試以後，再進行藍綠環境的切換。
此技術可以消除由於應用程式部署導致的停機時間。此外，藍綠部署可降低風險：如果新版本在綠環境上發生意外情況，可以通過切換回藍環境立即回滾到上一版本。這樣就有機會提前發現髒資料可能引起的問題。
類似的技術，還有金絲雀釋出等，也有助於提前發現髒資料的問題。
寫在最後
髒資料的防禦是關鍵
這跟敏捷測試的質量內建原則是一致的。質量內建強調缺陷預防，在預防缺陷產生的同時，要加強對於髒資料的防禦。根據敏捷測試的節奏，在敏捷開發生命週期各個環節做好髒資料的預防和處理工作，儘量減少髒資料給生產環境帶來的危害。
如果由於各種原因防禦工作不到位，髒資料產生後也要分析總結，回過頭來指導開發環節的工作，進一步加強防禦。
髒資料讓我們又愛又恨
恨的是髒資料的產生總是會導致系統行為的不可預測，讓系統質量保障變得複雜。尤其是一些髒資料不停的出現，還總是找不到原因的時候，很讓人抓狂！總想到此為止，讓髒資料來背鍋。
但這不是明智的做法，髒資料都是有原因的，不挖掘出真正的原因，可能帶來更加意想不到的後果。找出根因，做到防微杜漸，才是正道。
愛的不是因為髒資料可以幫我們背鍋，而是它的存在可以幫助我們暴露程式潛在的問題，是做好系統質量保障工作、生產環境下的QA不可或缺的助手。
QA朋友們，請加強對髒資料的重視，善待髒資料！
文/ThoughtWorks林冰玉
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見