某位高人曾說過：日復一日地重複著既有的測試，然後被類似的bug折磨得無可奈何，不如稍作停頓，分析總結找到bug的源頭，以除之。本篇文章我們就來聊聊如何通過視覺化的資料進行分析，進而提公升測試質量。
為了讓產品的質量可度量、視覺化，我們可以建立一些指標資料，以幫助我們發現產品質量的各種問題，比如：被測功能模組發現bug太晚，某位開發同學的**質量一直很低，某個功能總是在相容性方面存在大量問題等。有了問題之後，我們就可以有針對性地進行改進，有的放矢，從而使得被測產品的質量逐步改善。以搜狗的專案為例，我們建立的指標有以下三個方向：bug、**行和漏測問題數量。
關於bug的指標
bug是軟體開發過程中最基本的問題載體，在這一方向，我們可以細化為幾種資料指標，例如：
1.bug數量分布(功能模組維度)：
按照功能模組維度，分別統計bug的數量(也可以是嚴重bug數量)情況，該項指標用以反映哪個功能模組的質量情況最低。例如：搜狗輸入法有語音輸入、拼音輸入、手寫輸入，分別統計某個版本這三個模組的bug情況。
解釋說明：
首先我們可以判斷bug數量高的模組是否合理。如上圖所示，本次版本開發主要實現和修改的是語音功能，那麼bug數量多是合理的。
其次我們可以有針對性的部署測試策略。語音功能的問題數量較多，功能比較複雜，只是按照既有的測試計畫可能模組質量覆蓋不夠全面，所以我們有針對性地對這個模組進行二輪、三輪甚至四輪的回歸測試，或者安排更多地人力。
2.bug數量分布(開發人員維度)：
按照開發人員維度，分別統計每個開發人員所產生的bug數量情況，該項指標用以輔助評估開發人員的**質量情況。
解釋說明：
這一指標可以幫助我們了解哪位開發的bug修復壓力最大(壓力越大，連帶bug的可能性也會越大)，測試人員可以留意對應開發的bug修復率。
如果某位開發的bug數量常年居高不下，測試人員就要注意小心了~~。
需要特別說明的一點是，bug數量不能作為唯一評判開發人員*****壞的資料，bug數量是與開發人員提交**量和模組複雜度成正比的，綜合地檢視bug數量和**提交量是比較可行的方法。
3.bug易發現分布(功能模組維度)：
bug易發現是指乙個功能模組在使用者可觸及的主路徑上就會遇到的bug，例如：在輸入法的鍵盤上按下語音鍵進行語音輸入時，功能不能使用。該指標用以統計提測模組的開發自測情況，資料越多說明提測時質量越差。
4.bug易發現分布(開發人員維度)：
同上，以開發人員維度進行分析統計。
5.bug往返率(開發人員維度)：
該指標用於統計bug在缺陷管理系統中的來回指派數量的情況。比如：某bug在開發人員a和測試人員b之間來回指派了3次，那麼則統計開發人員a的bug往返平均數量。
6.bug發現的階段：
該指標可選項有**試、一輪測試、二輪測試、回歸測試、上線前測試、上線後幾個可選項，它用於體現bug的發現時間段。
解釋說明：
**試一般是開發提測後進行1天的測試，用以評估提測的版本是否符合測試的要求。如果大量的bug在**試階段發現(甚至是阻塞的bug出現)，說明提測版本的質量可能不好，這就需要督促開發給出質量更高的版本提測，以節省bug溝通處理的成本，從而大大提公升測試效率。
正式提測後，按照預期的效果，我們希望是大量的bug在一輪測試階段發現，少量的bug在二輪測試階段發現，極少量的bug在回歸測試階段暴露。但是實際情況可能有所不同，如果二輪和回歸階段的bug數量很多，這有可能是測試人員的測試方法、測試策略有問題，導致bug暴露發現得比較晚;也可能是開發修復bug時連帶其他bug數量多，這間接反映了開發修復bug的方式方法可能有問題。
7.bug產生的原因：
這一選項是bug在提交測試驗證時，由由開發人員填寫的字段，該欄位可選內容有：伺服器問題、第三方sdk問題、適配性問題、ui顯示問題、程式邏輯問題、效能問題、溝通不足問題、需求理解問題。(具體字段可選項可根據實際專案進行設定)，這一指標用來輔助開發人員分析bug產生的原因。
解釋說明：
服務端問題(本例因為是客戶端程式，所以選項中有服務端問題)如果存在大量的bug，這說明服務端的質量控制不足。
溝通不足、需求理解問題一般是工作配合類問題，如果是此類問題集中，應該重新評估整體專案流程運轉是否正常有效。
關於**的指標
借助功能強大的statsvn，我們可以方便地統計出與svn相關的各種資料指標，如：每位提交者的情況、每月的**提交情況，**修改佔**總數的百分比、每天中哪幾小時比較活躍、每週哪幾天比較活躍、檔案數量統計等，關於statsvn的介紹網上有很多使用教程，本文不再贅述，請感興趣的同學自行」搜狗 statsvn」即可。
千行**bug率：
在搜狗輸入法專案我們主要使用了statsvn的乙個資料項：開發人員**行數量，再結合上述1中的bug指標資料，我們可以得到乙個新的指標資料：千行**bug率，該指標用於側面體現開發人員的**質量情況。
解釋說明：
這一指標資料會定期傳送給開發leader，以便開發leader對其下的開發人員質量情況有乙個清晰的認識，同時也會督促開發人員提公升**質量意識。
關於漏測問題的指標
除了測試環節bug及**的統計分析，對於上線後使用者反饋暴露的質量問題，也應加以統計分析。在搜狗測試部，我們通過bug總結流程來進行這一環節的資料錄入和統計。(bug總結具體的流程和方法請見推文【質量管理改進】bug總結流程)
1.漏測問題數量分布(模組維度)
該指標從功能模組的維度，對線上使用者反饋的問題進行統計分析，例如：搜狗瀏覽器的線上使用者反饋數量最多的問題是瀏覽網頁這一功能。
2.漏測問題原因型別：
根據以往的工作經驗，我們將線上使用者反饋的問題歸為以下六大類，每一大類下細分小分類。
解釋說明：
通過分析線上漏測的問題原因，可以發現測試、開發或者流程上的不足，以pc瀏覽器的分析為例：
瀏覽頁面功能是top1被使用者反饋的功能模組(這也符合瀏覽器最主要的功能就是瀏覽網頁)，進而發現這一功能出現問題最多的是相容性站點的問題，或者是使用者的測試環境比較複雜特殊導致的。
基於以上的資料分析，我們重新制定了詳細的瀏覽器站點相容性測試方案，每個版本加大相容性站點的測試，在測試階段即發現了大量的bug。
總結
作為專案管理者，我們可以通過分析專案每個版本的bug資料、**行資料、漏測的問題數量，發現資料背後的問題(開發問題、測試問題、流程問題等)，針對問題尋找解決方案並實施，從而提公升整個產品的質量控制。 佚名
Python 資料分析視覺化
1 畫圖需要使用 matplotlib這個包 如下 importmatplotlib.pyplotasplt year 1950,1970,1990,2010 pop 2.519,3.692,5.263,6.972 values 0,0.6,1.4,1.6,2.2,2.5,2.6,3.2,3.5,3...
資料分析與視覺化
1.pip包管理 1 內建庫 包 庫 別人寫好的 直接引用，加快開發效率。內建包 python直譯器內建常用功能庫。直譯器安裝目錄 lib資料夾下，os time urllib等 資料夾裡有 init py 就成了乙個包。2 關於http模擬和html源 解析 python時代 urllib url...
視覺化BI軟體提公升企業資料分析效率
視覺化bi軟體經過幾十年的不斷發展，已成為大型企業進行商業決策不可缺少的工具。在bi軟體問世之前，由於做資料分析視覺化的時間較長 人力成本較高，企業一直處於忽視的狀態。視覺化bi軟體的出現極大地提高了企業處理分析資料的效率。以前很多企業 其實現在也有不少 做資料分析視覺化時，需要從企業內的各個業務系...