测试工作中遇到的一些问题与工作总结--线上bug

入行软件测试已有3年有余，工作年限来看已然不算是一个新人，但是也会感到焦虑，有时也会迷茫。

今日闲来无事，整理了一些日常工作中遇到的问题，及想法，愿与诸君共勉

线上bug

发布后，难免会有bug流落到线上，当看到用户报问题，你的心理活动又是怎么样的呢？

我想作为测试同学，发现线上报问题会比任何人都要伤心，自责。

那么遇到线上问题，该怎么办呢？

1、排查、复现

遇到问题，首先第一时间就是让研发同学排查bug原因，那么作为测试同学我们可以做什么呢。

研发同学排查的时间，我们可以在主分支上根据用户所描述的场景，进行复现，复现的好处个人认为有2点，

第一：便于尽快的知道bug的属性，是必现，还是偶现？是否真的是bug，毕竟也有很多线上bug不是程序本事有问题引起的，例如第三方平台推送数据不正确，不及时，产品需求本身未考虑，甚至一些就不是bug。

第二：便于bug回归时，确保bug被修复掉，如果你都没做复现，就匆匆忙忙将bug回归关闭，是无法保证bug修复的准确性的，有可能是你的操作步骤不正确，导致问题不再出现，误以为bug已经修复了。

2、排期

根据bug的严重程度，紧急情况，一般可分为2种情况，

一是，从master上拉取hotfi分支，当即修复发布。

二是，对于那种不太影响用户使用，不紧急的bug，可移进当前迭代中，跟随迭代一起发布。

还有一些比较特殊，可能你提了好几月了，也没见这个bug被安排修复掉，历史bug的长久堆积，对测试同学来说也是一种不好的体验，会错杀积极性，你不改，我提什么呢？

那么如何推动此类问题呢，我们的做法是

一，对长久挂起的bug，进行复现，有一些bug因功能的改动已经无法复现了，那么写明复现结果原因，将其关闭

二、复现后，仍然存在的bug，进行分类，有必要修复的，发给负责人推动修复，对于一些影响范围小的bug，与需求负责人沟通，确认不修复的，也是写明原因，将其关闭

3、回归

对于回归bug，需要求研发同学写明bug原因，改动范围，测试建议，避免漏测

回归的过程中，也要注意做发散测试，提高准确性

4、总结

不知道各位有没有做漏测分析的习惯，个人认为遇到问题并不可怕，我们更应关注，后续怎么避免此类问题的发生。

时间允许的情况下，建议bug回归后，当即记录总结，忙的时候也最好抽出时间，定期做漏测分析。

5、漏测分析

对于功能性bug，漏测的原因大致可分为3种

一，设计漏测 

       设计漏测又分设计用例时未考虑，此类可以将测试点记录归档，加深影响，下次再有类似的需求，就可以有效避免掉，也算是一种测试经验的累积吧

       再者就是需求理解有误，用例设计错误，一段文字，每个人的理解都各有不同，无关对错，那么如何避免呢，方法有很多，开发前 需求反讲，用例评审等都能有效避免

二，执行漏测 

       想对于其它的原因，执行漏测是最不应该的，有明确的用例，但没有认真执行导致漏测，作为测试，应该敲响警钟，执行用例再仔细，再认真一些。

三，其它问题引入

       有些问题可能是开发修改其它bug时引入的，也就是测试同学经常说的，之前是好的，后面改坏了。对于这种情况，测试同学在回归bug时，就需严格要求研发同学写明改动范围，bug原因，测试建议。特别是一些比较严重的bug，测试建议等描述不清晰时，还需要求研发进行修改。