所谓的测试效率就是测试产出和测试时间之比，假设测试产出是一个定值，那要提高测试效率，就是要缩短测试时间
那要怎么オ能减少测试时间呢？
一般项目前期bug都是较多的，而且极为不稳定的，如果有多个较严重的bug，可以拒绝继续测试。一方面继续测试也没有意义，因为阻塞测试的地方会有很多，也无法测试全面：另方面即便继续测试出很多bug，也可能是由于那些bug引起的，倒不如等这些修复之后再继续测试。这样对于前期来说可以节约不少测试时间，把做无效测试的时间留出来想想如何优化测试顺序。
要做到这点的前提是要对整个项目的架构、相互之间的联系等要十分了解，这样可以避免很多看似不同的测试点，但实际只是一个测试点，仅是外面包装的不同而已。于是当这一个测试点有bug，那些其他看似不同的测试点其实也不用测试了，肯定也是有问题的，那提bug的时候可以列出核心问题所在，并将其他涉及的点列出来，等验证的时候再把那些点都再验证一遍。这样等于少做了很多测试，只是在验证的同时把测试再覆盖全
对于测试来说肯定需要测试很多轮，每一个测试版本作为一个测试轮
第一轮:只测试大致功能，不需要细测，列出主要bug。
第二轮:验证第一轮bug，然后全面细测，列出所有能发现的bug
第三轮到第x轮:验证上一轮的bug。
最后一轮:验证全部bug，并全面细测。
优化测试顺序有时同样可以节省测试的人员的时间，比如注册、登录两个功能，可以先测试异常注册、在测试正常注册、紧接着测试异常登录、最后正常登录，这样可以节省一些重复的步骤
以上讲了如何通过技巧减少测试时间，但还有一道绕不过去的坎就是定位bug，这其实是非常花费时间的。也许有很多人不以为然，觉得无非就是发现bug后提交bug管理系统，描述操作步骤，预期结果和实际结果哪里不一致，然后继续测试。并不是说这样做不对，只是说这样做不够好，看似节约了测试时间，实则对于项目的进度没有起到应有的推动作用。
接着我就来具体分析一下吧。
如果是一个多人开发的系统，不能明确定位到这个bug是谁造成的，容易提交给错误的开发人员，于是bug会像皮球一样被开发踢来踢去，耽误开发解决bug的时间。即便提交给对的开发，开发也未必能查到bug产生的原因和代码有问题的地方，因此不一定能修复bug，往往修改了自己认为可能有问题的地方，然后测试发现还有问题，继续发回给开发，开发维续查，来来回回耽误解决bug的时间。再退一步来说，如果开发水平很高，没有1和2的问题，测试也很容易提交重复的bug，因为可能很多bug都是由于一个地方引起的，只是表现出的问题不一样，但本质却是一样的，这样也是耽误了测试时间。
当bug出现时，一般分大致3种情况
1、数据库层面：可能少某个字段，或者字段值为空等，这些可能在设计数据库时就埋下了错误的种子，导致程序调用数据库错误的数据产生bug，这一类问题不算普通，但也是最容易忽视的一种情况，有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。
2.网络层面：通常这种都是网络情况较差的时候产生的，比如手机的移动网络信号不好又或者是公司网络不稳定，导致js/css未加载完全或者请求超时等，这种问题其实非程序bug造成的，可以不用提交bug，也不用让开发毫无头绪地去查代码的问题。当然如果可以的话，也可以当优化建议提给开发，让他优化代码，比如压缩js，増加超时时间，超时后的重试机制。
3、代码层面：普通的bug基本都是代码有问题造成的，排除掉1和2剩下的就可以确定是程序bug了。对于了解网络构的人来说，其实程序也分前端和后端的，一般界面显示有问题直接可以判断是前端的问题，比如系统兼容性、浏览器兼容性。
而对于数据或者逻辑上的问题，则需要通过抓包工具来进行分析。
(1)请求未返回数据，可能是 client请求数据错误，也可能是 server端处理数据错误。
(2)请求返回错误的数据，那就是 server端处理数据错误。
(3)请求返回正确的数据，那就是前端处理 server 端返回数据有错误。
定位bug就像这样抽丝剥茧一层层排除，从面把最后剩下的可能性给找出来，说难其实也不难，但需要有足够的逻辑思维能力来推断，也需要足够的耐心去寻找bug的根源。有些人觉得，定位修复bug是开发做的事情。测试去干不是浪费时间吗?不要觉得这是浪费时间，把精力花在有用的点上总比花在和开发无意义地拉扯上好。而且定位出问题所在不但可以对开发更有说服力，也方便开发解决问题，开发能解决问题对于测试来说也能减少重复的没效果的验证过程从宏观的角度来看，这也是节约测试时间的一种方式。
除了定位bug外，还有一项耗时耗力的工作就是重现bug。有些bug隐藏得很深，它可能是无意的特殊操作或者几个特殊情况组合在一起产生的。所以这类bug不便于重现，这点尤其困扰着测试人员
1、回想过程：这是最重要的一点，当无法重现的bug产生时，必然是因为某种特殊因产生的，而很大可能因是某些特殊操作，用了某些特殊账号/数据，又成者当时的测试环境异常(测试环境在重启，网络状况不好等)，于是需要细回想bug产生前的所有细节，然后通过猜测的原因去不断地尝试测试、一个个排除种种可能的原因，最后的范同就会来越小，直到找到原因重现
2、群策群力：并不是所有人都能记住测试过程，也不是所有人都能把原因猜对，这时候需要团队的力量。可以将bug的结果发给其他测试同事，看看他们有没有遇到过这种情况，如果遇到过可以相互交流一下、然后取一些共回点进行分析和测试，那就有很大概率能找到问题所在并重现。如果没有遇到过、也可以让他们留心一下，万一遇到的话可以保留bug现场，并取共同点分析来重现
3、暂时放下：如果以上2种情况没有办法重现，那至少说明这个bug并不严重，从产生的概率来说很低，影响的范围就会很有限，不具备优先解决的条件。这时候可以提了这个bug，但不需要再多花时间去重现，可以继续其他测试工作，有时候测试中或者相似的测试中就会重現。有时候“有心栽花花不开，无心插柳柳成荫”，也许在其他测试中或者相似测试中就会重现，那时候就很容易能重现例如，由于程序之间有若干复杂的调用方式，看似a模块出的问题，其实是调用b模块的接口，b模块的接口数据又依于c模块的数据，所以可能问题在模块c之中，而局限a模块很难找到bug的直正原因，从而无法重现bug
4、开发协助：这点对开发的要求比较高，是仅仅对于有条件的测试人员可以使用的办法，让开发协助定位问题、然后和测试一起分析原因，通过对程序打断点或者增加日志的方式和测试配合排除和定位问题，这样的好处在于将定位重现bug与修复bug放到了一起，也通免了通过bug系统对bug进行来回状态改变、减少了沟通成本，提高了效率。现bug的方法还有很多，测试行业是一个经验累积的行业，更多的方法都是在实践中不断地累积而成的。当你遇到足够多的问题并了解到问题所在，对于之后的bug分析自然也会更准确，“前事之失，后事之师”一点也没错，所以很多事情没有绝对的捷径，别人的经验只能让自己别走错方向，剩下的还是要靠自己探索和发现
总结了一些测试平时用到的技能和方法，推荐本书《测试之道》
原文：https://www.cnblogs.com/xuejin-learning/p/11384600.html