测试人员的极致追求是零BUG。怎么才能零BUG呢？我们可以从以下几个方面去操作：
1、研读业务需求和参考竞品需求
需求评审阶段，产品经理、开发、测试、DBA在开评审会之前，一般都会收到一份需求文档或原型图。
在评审会之前，我们测试员一定要好好的研读需求或参考竞品，做好标记，把理解不明确，产生歧义的，或者不完整的内容，在产品经理组织会议来讲解需求时，针对不懂的地方进行提问并认真记录。
2、用例质量把控
用例的质量，对被测对象深入分析，功能进行细分，需求覆盖所有测试点，补充异常的测试点，复杂模块进行评审。
充分理解技术实现原理，架构及对平台的依赖等。深入理解用户群，分析用户使用各种场景，完全从用户角度出发，来设计测试用例，同时对用户体验做出一定的判断。
设计测试用例的优先级，利用专业测试工具，将测试用例按优先级来筛选，可以通过不同颜色来标识相应的优先级，不管是评审还是执行，都可以按这样的方法来进行检查。不管是冒烟测试用例还是功能测试用例，都能节省大量时间。
测试点粒度的把控--从粗到细，利用工具辅助，第一遍需求采集时，从大的方面整理出测试需求框架；第二遍需求采集时，开始细分到每个测试点；细化测试点时，可以应用以前写得好的公共测试用例。
测试用例及时更新，从整个测试流程来看，不管是需求分析阶段，开发阶段还是测试执行阶段，都可能出现需求变更，这时对于我们前期整理出来的测试点就需要及时的同步更新。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
3、用例评审很关键
用例评审的时候测试人员结合用例对需求进行讲解，把对需求的理解讲一遍，然后说明自己的测试用例里覆盖了哪些内容，产品人员和开发人员会针对性指出是否有遗漏场景。这样可以减少遗漏场景。
4、有必要交叉测试或是内部验收测试
每个人的思维不一样，考虑问题和站的角度不一样，那么测试的手段也会有一些差别，如果条件和时间允许，可以与同一项目组的其他同事交换模块相互再测试。
5、有效的回归测试
在进行本次主业务测试的同时，也要根据业务对以前业务的影响进行梳理，只要有影响都要再全量回归才会放心。当然为了效率，评估后没有受影响的地方是可以不要回归测试的。
(以上所有图片来源于网络，若侵权请联系删之)
6、遗留bug风险分析
在上线前的测试报告中，一定会有遗留bug风险分析，主要说明哪些BUG是未解决的，此次迭代这些BUG不上线有没有什么风险。有没有其他的规避方案，与产品、开发、测试经理商量。
7、漏测之后查找原因很重要
对待漏测我们首先应该看问题是不是在测试环境上也存在，再看流程问题还是技术问题?多做总结同样的坑避一次就够了，漏测是不可能绝对避免的，我们能做的只能是尽量减少漏测现象，漏测现象会随着工作经验增加而逐渐减少。所有想学习测试的小伙伴们，现在是一个非常好的时机.
下面是配套学习资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
软件测试面试小程序
被百万人刷爆的软件测试题库！！！谁用谁知道！！！全网最全面试刷题小程序，手机就可以刷题，地铁上公交上，卷起来！
涵盖以下这些面试题板块：
1、软件测试基础理论 ，2、web,app，接口功能测试 ，3、网络 ，4、数据库 ，5、linux
6、web,app，接口自动化 ，7、性能测试 ，8、编程基础，9、hr面试题 ，10、开放性测试题，11、安全测试，12、计算机基础
资料获取方式 ：
