bug遗漏，我想这个是很多公司很多人头痛的一个问题。众所周知，bug是不可能被完全消灭的，当然也就意味着在发布前不能被全部找出来。于是乎当项目发布后，或多或少都会出现bug遗漏的现象，即使发布初期没有发现，随着时间的流逝，一些隐藏的bug也会慢慢浮现出来。那么对于遗漏的bug，我们该怎么去做？
古时云：亡羊补牢，为时未晚也。对于遗漏的bug，我们应该去透彻的分析它产生的原因，然后吸取教训，防止再次出现。这样遗漏bug的数量就会越来越少，趋于0。那么怎样的分析才是透彻的呢？我发表一下自己的观点。
根据我的经验，总结下来有以下几点，首先从根源上说，需求的问题。需求是一切的根本，我们所做的一切都是在需求的基础上进行的，那么需求会不会有问题？当然有啦，否则要需求评审干嘛，每次需求评审，或多或少都能发现一些需求的问题，在还没有开始编码之前就把需求的bug找出来，这个是最理想的状态。显然这个不现实，但是能多发现一个不合理的地方，那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug，这个是要求比较高的，需要对业务的熟悉以及对相似产品的认识。需求关把好了，那么就算踏出了成功的第一步。
其次，要尽早与开发人员进行测试设计评审，统一对需求的认识（开发测试人员都可能存在对需求的认识不正确）。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。
接下来，就是用例设计了，这方面体现了一个测试人员的真实地能力。考虑的面要广，包括:使用不同的测试方案，不同的测试数据的类型（要齐全），正常流与异常流等来覆盖所有的需求。
然后就开始执行测试，要全面地执行测试用例，并且在测试过程中不断的添加遗漏的用例。在时间允许下，尽可能的执行。
回归阶段，除了要回归前面发现的bug，还要重视回归那些bug相关的模块，这个教训是很多的，所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug，继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码，知道改动的地方会被哪些模块调用或者会引起哪些变化，因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下，这种bug的遗漏会减少很多。
发布前期，应该在保证所有的bug都fixed的前提下，把所有用例都回归一下，以免遗漏。
最后终于发布了，发布好就可去FB了，^o^。不要在开心的情况下放松神经，所谓行百里，半九十，不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。
当然最好做自动化脚本，方便以后的回归。这就是我想说的，大家有意见可以跟着，共同进步。
软件测试干了几年，项目一个接着一个，一路从一个坑跳入另一个坑，有些是开发问题，一些是测试本人问题，大家在测试过程中踩过哪些坑尼？
1.自以为了解业务逻辑，实际浮于表面
这是个深坑，产品迭代跟的久了，功能上闭着眼睛都能说清楚就自以为很了解，实际上连该功能使用的协议，调用的接口都不知道，所以看到问题都是表面的问题。
你只看到了两个操作的入口不一样，提示信息不一样，你就以为是两个问题，而这两个问题都是调同一个接口引起的，但你分析不出来。。
这样导致的问题有：
①修改bug后对影响范围评估不够
②提相同的bug，碰上特别注重bug数量的开发，真是揪心。。
我们公司对于bug定期要做bug根因分析，这在一定程度上也是帮助测试更深入的了解产品，因为每次bug单上开发写的产生原因和解决方案，真是言简意赅。。
2.思维定死，不会向前多走一步
比如同一个账号添加之后删除再添加，同一份文档导入之后导出再导入，密码修改成功之后再修改，等等，向前多走一步，就可能有意外收获。
3.忽略偶现的问题
测试要记住：所有偶现的问题，都只是没有找到必现的规律！
不要以为偶现的问题，没有出现，就不提出来，等上线后用户发现这个问题，你再说曾经遇到过，只是没有提出来，那测试不背锅还有谁背？？
提出问题但不解决，测试就可以甩锅给产品，给开发，完美！（这个真是从踩过的坑里得出血淋淋的教训）
这里有个好的习惯：遇到问题先截图！！！先录视频！！！再分析原因，再提交给开发，最怕偶现的问题口说无凭，又没有证据证明，开发说你逗我呢？？？
4.避免随机测试
避免没有用例而进行的随机测试，虽然随机测试能发现一些问题，但是它的特点是我们测试人员想到什么就测试什么，这样就会导致有些功能点重复测试，而有的业务流程却没有覆盖到，出现漏测，一旦上线后出现Bug，就不好说了。
5.Bug的复现步骤描述必须要详细
这个其实算不上坑，只是个人总结。之前提交过一个Bug，Bug描述非常简单，在后期给开发复现的时候，费了很大的劲儿，如果我们能在Bug描述中，准确描述Bug的复现步骤，就可以明显缩短开发分析问题、定位问题的时间。
6.不要 “动” 之前的业务逻辑，因为会 “牵一发而动全身”
要 “遵守” 之前的业务逻辑，现有的业务逻辑尽量不要和之前的冲突，为啥呢？
因为啊，一旦按照现在业务逻辑的话，就得把之前的改了，改之前的业务逻辑会非常的复杂，不仅开发需要改代码，而且我们测试要重新再测，所以，不要动之前的业务逻辑。