測試工作中，不知道大家是否遇到過這種情況：有時遇到一些問題、BUG，提交之後開發會遇到項目時間緊、暫時難以解決、問題影響可能較少優先級低等原因被一再的遺留，慢慢的當再次見到這些問題，大家漸漸的麻木了，很自然的就繼續遺留，遺留多了欠下的債就大了，但是到底是否到了該修改的時候呢？怎麼去評估呢？用數據說話！
相信很多公司都有用戶反饋信息，這些反饋的信息就是一筆寶貴的財富，它能幫助你評估你的產品做的怎麼樣、有什麼問題甚至用戶會主動給你提出一些建議，因此測試應該多關注這部分信息，用以幫助優化測試方案、流程，那麼怎麼處理這些信息呢？
舉一個例子：
作爲測試，可能不怎麼知道自然語言處理的知識、大數據處理的各種算法，但是依然能夠處理它們。首先，給這些留言劃分關鍵字，將N條數據拆成名詞、動詞等等各種片段關鍵字，然後對它們進行統計，對所有關鍵字進行排序，可能有M個，取前邊一部分關鍵字就能夠反映出主要的問題了，但是關鍵字可能依然很多，此時將取出來的關鍵字兩兩成對進行正則表達式匹配，此時將匹配的數量進行排序，相信用兩個關鍵字索引出來的會更有說服力，此時人工進行分類、統計得到粗略的數量佔比，例如下圖：
可能之前你找報資源、輸入法消失等問題時，會被推遲，但是看到它們佔比很靠前、很重要的時候，就會被重視，專門抽出時間去解決。
當然這僅僅是開啓問題兜底的第一步，面對各種問題，不是找到問題就丟給開發去解決，儘量給別人比較明確的問題，纔會更容易被接收，比如佔用什麼資源了？佔用多少？ 是否能夠幫助提前找到哪些功能佔用？例如佔用的是內存：
這個圖是某個進程的內存佔用，使用PerformanceMonitor畫的，很容易得到佔用的大小，並且還能知道需要解決的是那個峯值，此時如果對於這個進程熟悉的人來講，就會容易定位問題的所在，如果依然不知道問題出在哪，還應當做下深入調研，比如HOOK HeapAlloc，在內存滿足什麼情況時生成dmp文件，之後就可以去分析原因了。如此流程，就可以把問題從大的分類到具體原因逐漸分析出來，當然只是能分析出部分問題。
從上邊的這個例子可以很清楚的發現，測試需要關注的內容其實還是挺多的，絕不僅僅是當前的功能測試，用功能測試減少問題，用尚存的問題輔佐功能測試，這樣變可以逐漸完善整套測試流程，更好的保證產品的質量。