隨著計算機技術的發展，人們越來越希望能運用IT技術為業務運營帶來便利和指導。例如通過對生產環境的數據進行分析整合得出業務趨勢以預測發展方向或者某項作業完成時間，也可能是通過對已有數據進行一定規則的計算，得到某種統計報告，為業務運營提供可視化和數據化的報告。似乎這樣的描述很符合大數據或者BI的范疇，個人這兩年陸續做過兩個非常類似的和數據相關的項目，我把其統稱為數據處理類項目。這類項目也包含數據處理之后的可視化，例如生成統計數據，圖標，或者儀表盤等等，所以我想是否也可以稱其為可視化項目？但是我所經歷過的這兩個項目算不上大數據項目，數據量還達不到，所以我們暫且就叫數據處理可視化產品吧。
1.數據處理可視化產品的特點
1)數據源來自真實的生產系統
第一個這類項目是幫助某礦業客戶計算其礦上某類設備的使用率，可用率，某段時間內的物理位置分布，車輛狀態統計等等。客戶期望根據該可視化產品能將礦上的幾千輛車輛的歷史工作狀態進行可視化以輔助設備采購、調度及維修運營工作的開展。屬于輔助決策自動化的范疇。這個產品的數據來自某類安裝在車輛上的物聯網傳感器，而且這些數據都是真實的礦上作業時車輛生成的真實數據。
第二個項目是一個內部計算敏捷交付團隊的交付效能的產品。根據團隊的持續集成，持續部署生成的數據，通過一定的算法處理，得出類似某段時間周期內團隊的部署次數，變更的平均前置時間，變更失敗率，失敗部署的修復時間等等。得到這些指標可以衡量一個團隊在交付的過程中的健康程度，幫助團隊自身實現交付效能的關注和檢測以實現持續改進。
2)簡單的數據ETL
不管是來自三方sensor的原始數據還是來自于持續集成平臺的原始數據，團隊都需要根據業務需求將數據進行簡單的抽取和轉換。例如將不具備結構的原始數據整合為可讀性強的結構化的數據源存儲于數據庫中。我所做過的兩個項目ETL都非常簡單，要么直接讀取并存儲入庫，要么就是提取所需信息進行結構化存儲。沒有復雜的數據清洗，或者轉換過程。如下為之前某一項目的數據庫示例：
3)包含業務規則的算法處理
兩個項目的產品都會對原始數據進行一定業務規則的算法類處理。例如采礦項目，需要根據車輛的物理位置，引擎狀態，行進速度等不同車輛屬性的不同取值進行該各個業務指標的計算和統計。第二個交付效能的產品也需要根據團隊的commit，deployment的狀態時間進行統計計算。如下為統計團隊交付效能4 key metrics的業務規則：
4)API層對計算結果的封裝處理
原始數據 根據業務 規則進行算法計算后，得到的統計數據一般是比較細粒度的，例如某一個輪班周期里某一輛車在礦區內裝填炸藥的總時間、行進總時間、維修總時間，但產品級的需求通常是某一個月或者某半年礦上3000輛車總的維修時間，總的使用率等。那么產品需要設計相應的API層對業務算法計算出來的基礎值進行二次整合封裝。這樣的做法是方便返回給前端具有某種業務意義的統計數據以方便其展示。
5)統計結果可視化
為了服務業務將計算結果以圖標或者儀表盤的方式進行展示和呈現是非常必要的，以達到一目了然，清晰可得的目的。這種圖標的展示方式更多是一種類似整個報告的感覺，業務人員或者管理層能清晰地指導某項指標的結果以方便其做決策。如下是之前項目的可視化示例：
2.數據處理可視化產品的測試點
根據上面對這類產品的描述，一句話概括就是把不具備直接業務價值的生產數據進行處理以得到清晰直接的有業務價值的統計數據。簡單點說就是數據處理，變廢為寶，指導業務運營和生產配置。我們可以 根據數據在各個緩解的處理加工進行相應的測試。如下是之前項目的數據流程圖和相應的測試點：
數據類產品，一定有非常清晰的數據處理流程，在每個處理的節點都是我們質量保障需要關注的點。例如：如果你的產品需要關注實時性，那數據源的持續性、完整性、正確性就需要在數據源頭進行核實。我之前的項目有個需求是根據礦場上車輛的數據信息在運用里展示出車輛當前的實時位置，如果數據源不連續，不準確，那用戶得到的位置信息一定是錯誤的。
既然是數據處理類產品，算法計算的正確性和健壯性也是需要關注的。往上走便是API借口層面的邏輯處理和計算、前端數據展示呈現的測試。
3.測試的難點
1）測試數據不具備場景性
如上我們看到的生產數據，雖然是結構化的，但是時間是Unix timestamp類型的，車輛的位置雖然有經緯度，但是我們很難在看到數據的同時非常直接知道此時車輛在哪里。即數據可讀性不強，每條數據是某一時刻的數據，所以可操作性較弱。
例如為了測試某輛車在不同區域停留的時長統計和在區域之間行進的時長統計是正確的，我們可能需要有這么一個場景數據，剛好這個數據的這輛車，在礦上的不同區域（炸藥區、維修中心、爆破區、跨礦區等等）停留的數據，同時為了讓這個場景接近真實的生產環境，我們會希望在不同區間之間的往返行進時間是合理的。最簡單的方式是，我們礦上有這么一輛車根據測試場景去使用，得到完整的使用數據，然后將這樣的數據喂給算法進行統計計算以驗證算法。通常交付團隊是得不到這樣的支持的。
2）測試數據的生成
如上所說，我們會看到數據的場景化特別重要，滿足測試目的才行。為了生成滿足測試目的的數據，測試團隊需要自己生成測試數據。之前在項目上我主要運用了python pandas和Excel進行數據生成。
第一步，根據測試目的，梳理測試用例生成scenario sheet
第二步，根據每個用例的數據要求整理車輛狀態變更的數據生成case sheet，一個case一個sheet
第三步，運用python pandas對 Excel的操作方法生成數據
第四步，將生成的具有業務場景的mock數據寫入數據庫
在度量交付效能的項目上，算法測試的時候選擇直接使用靜態文件進行數據生成，挑戰的點依然是為了測試build的不同狀態，編譯部署的不同方式，需要梳理出測試的最小集。生成最小的測試數據集以覆蓋盡可能多的測試場景。這中間需要測試人員對需求和算飯進行分析，設計以得到這樣一個最小集。
3）期望結果不直觀
測試場景有了，數據也有了，那某一批測試數據喂給算法計算得到什么樣的值才是期望值呢？算法測試相比其他類型的測試，明顯不一樣的點是，你需要對期望值進行提前計算。就像會計一樣，你需要自己去計算，才知道別人（算法）算得是否正確。
像我之前做過的兩個數據處理類運用，計算過程都和時間有關聯，例如時間點A到時間點B車輛在裝炸藥，例如團隊在時間點A對某一次的部署失敗了，在時間點B重新部署成功了。測試人員需要自己根據 ‘ 場景-> mock 測試數據 -> 計算期望值‘這條線上來回看。比較容易出錯的點是，mock數據的時候時間弄錯了，復制粘貼的unix timestamp錯了導致計算出來的期望值和預先設計的場景不一致。但基礎算法的測試，沒法去自動化，否則變成了和開發一樣去寫一套QA自認為的算法，你又怎么保證自己的算法沒問題呢？
4）客戶驗收算法困難
算法類故事卡的驗收相比業務流程，應用界面的驗收也是更難的。通常情況下，一些應用的功能，我們只用直接展示相應的功能，客戶即可知道該功能是否和預期一致。但是算法的正確性，演示是比較困難的。我當時的做法是，把自己的測試過程，包括場景設計、數據準備、算法輸出都跟客戶過一遍。再到界面上去直觀的展示計算結果。是相比其他應用類測試驗收更費時費力的，而且整個過程需要PO跟上你的測試思路。
