本文筆者對髒數據的來源、髒數據的危害、髒數據的預防、如何對已出現的髒數據進行處理等問題進行詳細闡述。

“小光，今天那個詭異的生産環境問題找到原因了嗎？”

“還是數據問題！之前做的一個功能有一部分數據遷移工作沒有做好，導緻生産環境有髒數據，委托人的聯系人已經不為該委托人服務了，應該移除掉的……”

“又是髒數據……”

“嗯，好在不是代碼問題。”

這是在藍鲸項目發生的真實對話。其中提到的髒數據（Dirty data），也叫壞數據（Bad data），通常是指跟期待的數據不一樣、會影響系統正常行為的數據。

藍鲸項目的QA會定期分析生産環境的缺陷，當定位某個缺陷為髒數據引起之後，往往就到此為止了。

生産環境下的缺陷分析流程是這樣的：

調查分析生産環境缺陷，到最後定位是數據問題的時候，總是讓人渾身輕松……于是，“髒數據”就跟測試的“随機挂”一樣，成為了光榮的“背鍋俠”！

髒數據 ≠ 代碼問題，真的是這樣嗎？先來深入了解一下髒數據。

髒數據是怎麼回事？

髒數據産生的原因多種多樣，有的甚至很難解釋清楚到底發生了什麼……

通常，以下原因可能造成髒數據：

1. 髒讀：讀了事務處理中間狀态的數據
2. 重複插入了相同的數據：多次點擊同一個按鈕導緻
3. 不能為空的字段存為空：數據庫字段沒有驗證，或者對于曆史數據沒有做好遷移處理
4. 人工錄入不合法的數據：比如電話号碼含有特殊字符
5. 運行SQL腳本插入了不合法數據：比如不同實體id搞混等
6. 存入了多餘的空格
7. 測試環境可能由于部署了半成品産生一些不合法數據
8. ……

因此，髒數據跟代碼有關，髒數據的産生是因為沒有做好防禦工作！

髒數據有哪些危害？

根據不同的系統、不同的業務，髒數據帶來的危害也會不一樣。

• 髒讀産生的數據往往是錯誤的，導緻數據不真實性，或者數據的不一緻性；
• 重複和其他不合法數據則可能導緻系統行為的不正常，有時候還可能導緻非常嚴重的故障，甚至有些沒有暴露的髒數據可能帶來不可預知的緻命錯誤，危害可能是相當大的。

髒數據帶來的危害很難估量，有很大的不可預測性，對于髒數據的預防至關重要。

那麼，如何能夠防範于未然呢？

如何預防髒數據的産生？

嘗試對髒數據引起的生産環境缺陷做進一步分析，總結出髒數據的幾種類型，可以在敏捷軟件開發生命周期的不同階段對其進行防禦。

業務需求分析階段

在業務分析的時候，根據業務需求，明确業務相關數據的特定要求：

1. 不能為空的字段
2. 不能重複的數據
3. 日期範圍
4. 電話号碼可以有“ext.”、“ ”和“-” 但不能有其他字符
5. 特殊字符的限定
6. 功能升級的時候考慮已有數據的遷移
7. 還有一些跟常識不同有特定業務含義的數據需求
8. ……

數據庫和代碼實現階段

明确了數據的需求，可以根據需求定義和軟件使用常識，在實現層面對數據進行嚴格的約束和校驗：

1. 數據庫表的主外鍵、字段類型、是否允許為空，事務處理隔離等。
2. 前後端對數據進行嚴格的校驗，防止各種手段存入不合法的數據，包括需求定義的數據和常識性的數據，比如身份證号碼最多18位等。
3. 考慮多用戶同時處理可能帶來的并發問題。
4. 防止按鈕或者鍊接被重複多次點擊，可重複點擊通常在網速較慢時可能存入重複數據。
5. 程序讀取數據的時候進行處理，比如去掉多餘空格、去重、大小寫不敏感數據的處理。
6. ……

測試的進一步保障

有了需求定義和實現層面的校驗，大部分的不合法數據被阻止了，但是還是會有漏網之魚，在測試的時候繼續采取相應的措施來進一步防禦。

1. 業務需求規定的數據：這個毫無疑問是需要測試的，有底層的單元測試覆蓋會更好。
2. 常識性的數據：由于不同的人可能有不同的常識，這些問題在測試的時候還需要特别關注。
3. 探索隐藏邊界：關于隐藏邊界的概念大家可能不是很熟悉。咱們通常說的等價類、邊界值分析方法設計測試用例，都是根據可見的邊界來考慮的，其實咱們程序後台可能還存在一些隐藏的邊界，也是很有可能會導緻數據問題的，需要在測試過程中進行探索發現它們并進行驗證。

關于隐藏邊界，可以參考John Ruberto的文章《Uncovering Hidden Boundary Values in Testing》，裡邊提到了四種隐藏邊界：數據類型邊界、信任域邊界、特殊數據值、複活節彩蛋。

除此之外，咱們平常測試過程中可以多積累，總結出還有哪些可能會導緻數據問題的隐藏邊界。

對線上用戶的培訓

做了前面一層層的防禦，如果最終用戶在使用的時候能夠按照規範操作數據，對減少髒數據的産生會很有幫助。

下面兩個措施可以培訓用戶更規範的操作數據：

1. 在界面上給出清晰的提示，告訴用戶某些數據輸入的要求
2. 給用戶培訓或者提供用戶手冊，告訴用戶該怎麼正确使用系統

如何處理已産生的髒數據？

有那麼多預防髒數據産生的方法，但相信髒數據的産生還是在所難免的。髒數據一旦産生，導緻的系統行為也是不可預測的，可能無足輕重，也可能暴露非常嚴重的缺陷。

該如何應對産生的髒數據呢？

髒數據産生以後有兩種存在形式，一種是已經引起某些問題被發現了，另一種是還不被人知道，不知道哪天會發生什麼樣的問題。

已經暴露的髒數據

對于已經暴露的髒數據，首要的是對數據的快速修複，讓系統恢複正常運轉。對于專業的髒數據處理可以了解一下數據清洗（Data cleaning）技術。咱們平常對于髒數據的修複，可以根據業務需求，采用數據庫腳本修複，或者在前端執行JS腳本來修複。

修複數據需要特别注意不要引入新的髒數據，編寫腳本之前要理清相關業務和數據之間的關系，編寫好腳本之後要經過嚴格的測試才能在線上環境執行。

修複數據的同時，需要進一步調查數據産生的原因，檢查可以在哪個環節加固防禦措施，以盡量減少類似數據問題再次發生的可能性。

未暴露的髒數據

這樣的數據，其實我們并不知道它的存在，就像一個在黑暗處的幽靈，不知道什麼時候會給系統帶來麻煩。

由于系統環境的複雜性、用戶行為的多樣性，生産環境更加容易産生髒數據。盡早發現這種潛在危害的髒數據非常重要。

藍鲸項目就是這樣。在跟客戶做支持的同事溝通過程中，最大的擔憂就是生産環境的數據總能發現問題，如何能夠讓這些問題盡早暴露出來？

推薦生産環境下的測試（Testing in production，TiP）的一些實踐：

1） 直接在生産環境測試

生産環境是高度受保護的，不可以随意測試，以免破壞生産環境的穩定性。在生産環境寫入數據要特别謹慎，大批量的讀操作也要注意對系統性能的影響。

有些可以隔離出來的功能或操作，相對來說是安全的，可以在生産環境直接測試，比如：藍鲸項目的郵件服務，常會在生産環境部署單獨的服務器來測試。

需要根據項目真實情況去做決定。

2）将生産環境數據清理後用于測試環境

生産環境數據含有PII（個人身份信息，需要保護的隐私信息）或者其他機密，通常不能直接用于測試環境。

将生産環境數據的PII和其他機密信息清除後用于測試環境，測試人員基于這些數據做測試，就能有效的提前去發現由于生産環境數據引起的問題。

這個方案很好，但是要權衡ROI。對于一些複雜的系統，數據庫結構過于複雜，清理的成本太高，也是不太現實的。

3）利用藍綠部署等TiP實踐

藍綠部署是一種通過運行兩個相同的生産環境“藍環境”和“綠環境”來減少停機時間和風險的技術，是TiP非常典型的一個實踐。

在任何時候，隻有一個環境是活的，活的環境為所有生産流量提供服務。通常綠環境是閑置的，藍環境是活的。部署新的版本到綠環境，可以先進行測試，而不會給真正在使用的藍環境帶來影響。完成部署和測試以後，再進行藍綠環境的切換。

此技術可以消除由于應用程序部署導緻的停機時間。此外，藍綠部署可降低風險：如果新版本在綠環境上發生意外情況，可以通過切換回藍環境立即回滾到上一版本。這樣就有機會提前發現髒數據可能引起的問題。

類似的技術，還有金絲雀發布等，也有助于提前發現髒數據的問題。

寫在最後

髒數據的防禦是關鍵

這跟敏捷測試的質量内建原則是一緻的。質量内建強調缺陷預防，在預防缺陷産生的同時，要加強對于髒數據的防禦。根據敏捷測試的節奏，在敏捷開發生命周期各個環節做好髒數據的預防和處理工作，盡量減少髒數據給生産環境帶來的危害。

如果由于各種原因防禦工作不到位，髒數據産生後也要分析總結，回過頭來指導開發環節的工作，進一步加強防禦。

髒數據讓我們又愛又恨

恨的是髒數據的産生總是會導緻系統行為的不可預測，讓系統質量保障變得複雜。尤其是一些髒數據不停的出現，還總是找不到原因的時候，很讓人抓狂！總想到此為止，讓髒數據來背鍋。

但這不是明智的做法，髒數據都是有原因的，不挖掘出真正的原因，可能帶來更加意想不到的後果。找出根因，做到防微杜漸，才是正道。

愛的不是因為髒數據可以幫我們背鍋，而是它的存在可以幫助我們暴露程序潛在的問題，是做好系統質量保障工作、生産環境下的QA不可或缺的助手。

QA朋友們，請加強對髒數據的重視，善待髒數據！

作者：ThoughtWorks林冰玉，ThoughtWorks洞見

本文由@ThoughtWorks王健 原創發布于人人都是産品經理，未經允許，禁止轉載。

題圖來自Unsplash, 基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部