nodejs SWQA平台缺陷模組資料處理

最近重構資料平台的bug模組，由於不熟悉，對於一些資料的處理折騰了一小段時間

資料平台的bug模組主要是從jira平台中請求獲取資料，介面文件參考jira的官方文件：

缺陷型別（bug、bug-上版本漏測、bug-與需求不符、bug-未自測、bug-需求未更新、tracking）

缺陷嚴重程度（致命、嚴重、一般、次要）

缺陷關閉型別（不能復現、侷限性、已解決、無效bug、未處理、設計如此、重複問題）

缺陷型別（bug、bug-上版本漏測、bug-與需求不符、bug-未自測、bug-需求未更新、tracking）

缺陷嚴重程度（致命、嚴重、一般、次要）

缺陷狀態（新建、重新開啟、測試中、開發中、待掛起、被拒絕）

缺陷優先順序（highest、high、medium、low、lowest）

出現頻率（總是、無法重現、有時、沒有試驗、隨機）

缺陷模組

缺陷經辦人

以上為需要統計的缺陷的狀態和相關的資料，缺陷的型別和狀態梳理ok後，研究一下請求的語句

使用的url為/rest/api/2/searchmethod：get

請求引數為 sql 語句

關於請求不同型別的bug，如果不分專案，一次性的全部請求後再次解析，目前的bug數量為差不多1w條，而且這個數值是增長的趨勢，故不宜將所有資料獲取然後解析，因此分開四種狀態，用不同的sql條件去獲取bug

ps：這裡說明一下，原本因為打回和關閉缺陷在原先jira平台中並沒有預設的字段，將配置了「缺陷打回時間」、「缺陷關閉時間」和「缺陷關閉型別」等字段後，即可進行搜尋，避免了原來的得到新增和遺留問題後計算獲得關閉缺陷的無奈之舉

新增、關閉、打回和遺留缺陷分別進行查詢，因為jira平台中部分缺陷是不需要進行計算和查詢，故查詢時只進行了部分專案的查詢，將每個sql語句進行了封裝

var param = ,,,

],}return param;

}現在看一下請求介面獲得的資料

比如現在獲取的是某乙個專案某一天建立的缺陷，請求jira後響應的資料為：

,
,] }

現在解析其中的issues中乙個資料，得到的資料：

},

根據解析的資料，將需要的資訊組合成物件：

var bugdata =

當然，在處理資料時，發現有些缺陷的某些資料可能是null，故需要進行判斷後進行處理

現在的機制是，每天早上7點10分從資料庫中獲取昨天一天的資料，發現每天的遺留bug資料約為1000條，3個月即可達到10w的數量級，如果已寫在資料庫中的遺留bug只進行update處理，那麼乙個遺留bug的狀態、優先順序和經辦人等資訊儲存相對比較困難，故不採用這樣的方式

由於僅僅是遺留的問題數量級比較大，故將遺留問題在資料庫中存為乙個表，另外三種狀態存為另外乙個表中

因為前段不同的模組需要展示不同維度的bug資料，而且各個專案還需要每個開發的各個維度的bug資料的情況，故如何處理資料並且將什麼資料傳給前端

在讀取資料庫的資料時，如果沒需要乙個維度的資料就進行一次查詢，這樣對於資料庫的請求次數較為頻繁。故使用left join的方式將查詢表進行拼接

如這樣的資料庫查詢語句：

select a.projectgroup,a.project,ifnull(a.legacy_all,0) as legacy_all,ifnull(b.legacy_status_build,0) as legacy_status_build,ifnull(c.legacy_status_reopen,0) as legacy_status_reopen 
from 
(select projectgroup, project,count(*)as legacy_all from dataplatform_bugdata_legacy_org where thedate = '2017-03-13' and project = 'sr' group by projectgroup,project)a left join
(select project, count(*) as legacy_status_build from dataplatform_bugdata_legacy_org where thedate = '2017-03-13' and project = 'sr' and statuss='新建' group by project,statuss)b on b.project = b.project left join
(select project, count(*) as legacy_status_reopen from dataplatform_bugdata_legacy_org where thedate = '2017-03-13' and project = 'sr' and statuss='重新開啟' group by project,statuss)c on c.project = c.project

查詢的表為：

程式請求獲取的資料格式為：

rowdatapacket

這樣json left的方式進行表拼接有個問題，目前當個查詢的時長為0.001s的級別，但是如果資料庫的資料量較大時，這樣的方式查詢耗時較大，資料庫每個表在乙個時刻點只處理乙個事件查詢，這樣會造成堵塞部分查詢超時失敗

開始想著怎麼把這些資料拼湊在一起直接傳給前端，故使用map對資料進行組合

/**
* 按照map鍵值對組合資料
* @param bugdbsql
* @param callback
*/var bugdata = function (bugdbsql,callback) else
}callback(bugmap);})}

此時資料格式為：

],
'專案二' => [ rowdatapacket ],
'專案三' => [ rowdatapacket ],
legacy_severity_d: 15 } ],
'專案四' => [ rowdatapacket ],
'專案五' => [ rowdatapacket ] }

感覺這個資料已經完整的組成傳給了前端，但是問題來了，這樣的資料格式對於前端真的是ok的麼？

開始想著的是需要哪個資料直接這樣的方式獲取：

data.get('item.project').legacy_all

但是問題來了，這個是分為新增、關閉、打回和遺留四個模組，前端資料處理也比較麻煩，而且前端的資料的格式應該是這樣的（前期沒有確認前端的資料什麼方式比較好，這個坑了）

其實給前端的資料格式以陣列的方式即可

好吧，這個時候將資料處理成相應的格式

var a = 
a["abc"] = 1;
console.log(a)

使用async.series的方式進行done(error,null)進行組合

在資料組合過程中沒有母表，如果建立乙個表的話有一大串的資料量，因為只要該專案存在即有遺留的bug，故將遺留問題這個做為基表，將其他資料加入其中

for(var item_newbug of data.newbug)}}

如果不存在新增問題這個選項時，將該專案所有的新增物件置為0

if(item_legacybug_last.new_all==null)

這樣就按照既定的格式完成了資料取

nodejs SWQA平台缺陷模組資料處理

缺陷檢測紅色模組

無線數傳模組

移動平台中的模組復用

nodejs SWQA平台缺陷模組資料處理

缺陷檢測 紅色模組

無線數傳模組

移動平台中的模組復用

相關推薦

缺陷檢測紅色模組