测试工作中，不知道大家是否遇到过这种情况：有时遇到一些问题、BUG，提交之后开发会遇到项目时间紧、暂时难以解决、问题影响可能较少优先级低等原因被一再的遗留，慢慢的当再次见到这些问题，大家渐渐的麻木了，很自然的就继续遗留，遗留多了欠下的债就大了，但是到底是否到了该修改的时候呢？怎么去评估呢？用数据说话！
相信很多公司都有用户反馈信息，这些反馈的信息就是一笔宝贵的财富，它能帮助你评估你的产品做的怎么样、有什么问题甚至用户会主动给你提出一些建议，因此测试应该多关注这部分信息，用以帮助优化测试方案、流程，那么怎么处理这些信息呢？
举一个例子：
作为测试，可能不怎么知道自然语言处理的知识、大数据处理的各种算法，但是依然能够处理它们。首先，给这些留言划分关键字，将N条数据拆成名词、动词等等各种片段关键字，然后对它们进行统计，对所有关键字进行排序，可能有M个，取前边一部分关键字就能够反映出主要的问题了，但是关键字可能依然很多，此时将取出来的关键字两两成对进行正则表达式匹配，此时将匹配的数量进行排序，相信用两个关键字索引出来的会更有说服力，此时人工进行分类、统计得到粗略的数量占比，例如下图：
可能之前你找报资源、输入法消失等问题时，会被推迟，但是看到它们占比很靠前、很重要的时候，就会被重视，专门抽出时间去解决。
当然这仅仅是开启问题兜底的第一步，面对各种问题，不是找到问题就丢给开发去解决，尽量给别人比较明确的问题，才会更容易被接收，比如占用什么资源了？占用多少？ 是否能够帮助提前找到哪些功能占用？例如占用的是内存：
这个图是某个进程的内存占用，使用PerformanceMonitor画的，很容易得到占用的大小，并且还能知道需要解决的是那个峰值，此时如果对于这个进程熟悉的人来讲，就会容易定位问题的所在，如果依然不知道问题出在哪，还应当做下深入调研，比如HOOK HeapAlloc，在内存满足什么情况时生成dmp文件，之后就可以去分析原因了。如此流程，就可以把问题从大的分类到具体原因逐渐分析出来，当然只是能分析出部分问题。
从上边的这个例子可以很清楚的发现，测试需要关注的内容其实还是挺多的，绝不仅仅是当前的功能测试，用功能测试减少问题，用尚存的问题辅佐功能测试，这样变可以逐渐完善整套测试流程，更好的保证产品的质量。
