第一计-瞒天过海
【释义】
防备得周全时，更容易麻痹大意；习以为常的事，也常会失去警戒。秘密常潜藏在公开的事物里，并非存在于公开暴露的事物之外。公开暴露的事物发展到极端，就形成了最隐秘的潜藏状态。
在我们测试过程中，漫天过海是很常用的一种计谋。
很多错误，往往都是隐含在我们已经习惯了正确的区域，这也是为什么，我们在不停的在做让人觉得很枯燥无味和产出比很低的回归测试的原因。
很多测试团队，都是习惯了使用已经存在的功能测试用例来进行回归测试，导致很多bug在被僵化的测试过程所遗漏。所以，进行更加有效的回归测试必须要去探索那些我们遗漏的阴影区域。而如何去探索这些区域呢，一般可以考虑的方法有如下几个：
1、在功能测试完毕后，对bug进行分析，得出bug的分布图和原因。然后在没有发现bug，但是被主要bug趋势范围影响到的功能区域，加强回归测试的深度。
2、在回归测试完毕后，对功能区域进行评价，对于发现问题较多的功能区域进行更加宽泛的广度优先的二次回归。
3、定期的评审回归测试用例，对测试集合进行调整，不要只针对新功能直接影响的，而是那些在底层更迭模块所影响的应用层进行更多的关注。
另外一个大范围使用瞒天过海的测试范畴就是安全性测试。
在安全性测试中，我们大部分的方法就是设置一个虚假的信息，企图访问系统，从而给系统带来损害。
比如我们使用jmeter去获得一个特定角色的访问过程，该角色的权限为低级。我们在测试时，人为的修改该角色的权限，通过jmeter发起请求，看是否能够成功的骗过登录策略进入系统。
还有就是我们认为的修改数据库中的某条数据，然后进行下束流程，看系统是否在流程进行过程中对数据完整性进行有效的校验。
总之，瞒天过海在测试领域里，就是要验证那些隐藏的流程和数据处理过程。这些流程和过程在我们用户前端是被屏蔽或者隐藏掉的。虽然正向的和反向的操作都不会出现问题。但是，除了正向和反向的操作这些已经被开发刻意处理过的范围之外，仍然会潜藏一些常规方法无法探知的缺陷。这些缺陷只有通过非常规的测试手段，主动的攻击才会被表露出来，从而获得更深层次的质量保障。
第二计-围魏救赵
【释义】
进攻兵力集中、实力强大的敌军，不如使强大的敌军分散减弱了再攻击。攻击敌军的强盛部位，不如攻击敌军的薄弱部份来得有效。
围魏救赵其实说起来很简单，大部分人也都试用过。那就是把要测试的对象不断的拆分，一直到最simple的程度。从而避免因为测试一个过于复杂的对象导致bug的遗漏。
这个过程其实就是一个break down的过程。简而言之，就是对一个对象的测试用例进行分层的过程。
我们在测试用例开发过程中，一定要引入分层的概念，这样的好处不但利于我们在各个测试阶段simple的工作从而准确定位bug，而且有利于我们在需求更新时，更加快捷有效的更新我们的测试用例。
一般测试用例分层的策略就是：
1、UI层，只考虑GUI的范畴。
2、Field层，考虑的是各个element本身自有的属性逻辑。
3、Functional层，考虑的是单个或者多个element的实现的业务逻辑流和或者功能。
4、Business Rule，考虑的是上下文，和直接间接被影响的功能区域。
5、安全测试，考虑的是相关的安全策略。
总之，所谓的围魏救赵，目的就是通过将测试对象细化，降低测试的复杂度，有利于我们通过一点来击破整个屏蔽，减少测试的成本。
第三计-借刀杀人
【释义】
敌人的情况已经明了，友方的态度尚未确定。利用友方的力量去消灭敌人，自己不需要付出什么力量
如何才能降低测试成本呢，这是每个测试管理者最大的问题。在传统测试过程中，一般是开发将代码开发完毕后，移交给测试人员进行测试。一般开发人员会进行单元测试和集成测试。
然而，在现在敏捷开发的过程中，开发人员也必须进行一些功能测试，尤其是自动化测试的大量引入，很多人都觉得开发人员必将取代测试人员的角色，从而使得测试人员这个角色逐渐的消亡。
其实这是一个很片面的想法。在敏捷开发过程中，测试角色不是被削弱或者是被取代，而是更加的被强化，测试驱动开发测试敏捷开发的真髓。
在测试驱动开发的敏捷开发过程中，测试人员和开发人员同时对user story进行分析，开发人员根据其进行代码实现，而测试人员是通过书写相关的测试场景来验证开发人员实现的质量。
也就是说，测试人员不再是去根据需求和设计文档在后期进行代码实现度的验证，而是转变为依据或者是贴合最终用户来控制开发的方向和质量。
验证标准也从了是否完成了预期的设计变成了是否满足了用户的需求。
所以，借刀杀人已经成为普遍的开发策略。核心的想法就是，开发人员在做完常规的单元测试和模块测试之后，必须依据测试用例对代码进行功能测试，只有那些完成了p1&p2测试用例的代码，才会提交给测试人员进行测试。
这样的好处是：
1、在开发阶段就能评审代码是否符合用户需求，这是敏捷的灵魂。
2、在测试阶段减少大量因为P1&P2导致的等待时间和重复测试率。
3、开发测试的用例可以是手工测试用例或者自动化测试脚本，这样的话加强了测试人员和开发人员的交互，不再是单纯的质量保证，而是主动质量控制。
所以，借刀杀人的最大核心就是，那些测试用例需要开发人员来执行。这就是测试用例要分层的原因所在，只有分层的测试用例，才能很简单的提取一个测试集合用来执行借刀杀人这个计谋。
第四计-以逸待劳
【释义】
意谓困敌可用积极防御，逐渐消耗敌人的有生力量，使之由强变弱，而我因势利导又可使自己变被动为主动，不一定要用直接进攻的方法，同样可以制胜。
在测试过程中，以逸待劳是对测试计划的一个有力的支撑。
我们在指定测试计划时，就需要根据具体的测试范围，测试资源，测试进度表等进行高效率的设定。
那些需要重点测试， 那些需要回归，那些需要特殊的工具，那些需要特殊的数据集，那些需要特殊的测试环境，测试对象的前后依赖性，开发的进度等等都是影响我们制定测试计划的各种重要因素。
通过测试计划的制定，我们能够在开发阶段有条不紊的进行测试的准备，从而达到并发的执行效率，而不是传统测试中，只有一个简单的时间线，所有的测试都是在要执行之前，才进行更详细的分析。
而以逸待劳就是敏捷测试的另一个优点，在你根据user story进行测试场景的设计时，就已经按照执行时如何更加有效的利用资源进行设计了，而不是传统的那种只是针对use case中包含的单一功能区域进行场景设计。
以逸待劳的核心就是提前准备而不是需要时才动手。基本上减去了测试人员在测试用例开发完毕后等待代码前这段无所事事的idle time。
第五计-趁火打劫
【释义】
本指趁人家失火的时候去抢东西。现比喻乘人之危，捞一把。
趁火打劫基本上大家都已经或多或少的用过了。
在测试过程时，我们经常能发现一个bug之后，然后在周围发现很多bug。这些bug有些是因为原生bug引起的，有些是因为修复bug导致的新bug。
所以趁火打劫的测试思想就是，一旦你发现了一个bug，就要着重的在bug的直接影响功能区域，间接影响功能区域进行更deep的挖掘性测试，从而能够更加有效的获得产品的缺陷。
只有通过趁火打劫，我们才能更加深层次的挖掘出真正的缺陷，如果仅仅是发现一个bug，根据其表象提交之后就置之不理，反正会在后期的过程中出现更大的隐藏缺陷，从而导致整体进度的延迟。
所以，趁火打劫是手段，目的是那些中间过程，临时数据集，被间接调用，或者底层代码的缺陷。
第六计-声东击西
【释义】
此计是运用“坤下兑上”之卦象的象理，喻“敌志乱萃”而造成了错失丛杂、危机四伏的处境，我则要抓住敌人这不能自控的混乱之势，机动灵活地运用时东时西，似打似离，不攻而示它以攻，欲攻而又示之以不攻等战术，进一步造成敌人的错觉，出其不意地一举夺胜。
一般常规的测试数据设计，都是从黑盒角度进行考虑，也就是正向数据集和反向数据集。这样的话，正向数据集是保证的正确的流程和功能。反向数据集是保证了数据验证策略的完整性。
但是，如果仅仅这样，只能说我们还是从正面的效应去考虑产品的特性。
而声东击西，就是要我们不仅仅从应用层去设计测试数据，还要从逻辑层甚至驱动层去设计测试数据。我们不是单单的验证一头一尾的数据完整性，我们还要去主动验证中间数据的有效性。通过直接修改数据来实现这一个效果。
另外，声东击西在性能测试里面也是一个广泛的应用，我们在无法直接测试一个性能点时，通过对他直接影响或者间接影响的功能点进行测试，从而侧面了解该功能点的性能。
最常见的一个示例就是我们无法验证一个用户密码验证过程的性能，但是我们通过大量的有效登录和无效请求的混合用户登录集合，我们能间接的获得验证的效率和瓶颈。
第七计-无中生有
【释义】
运用假象欺骗对方，但并非一假到底，而是让对方把受骗的假象当成真象。
在自动化测试过程中，有时候我们需要测试的模块需要一些未开发完毕的模块的支持，所以需要我们static的提供一些方法或者数据。这种书写测试用的假模块是开发常用的方法。很典型的无中生有的计策应用。
实际上，我们在手工测试中，也可以使用这种计谋，最常见的就是是我们需要一个测试数据时，无法直接获得，那么我们就可以在数据库中直接添加我们的需要的数据。
扩展来看，这种方法在build tesing中最有效。我们现在都是自动code build 然后自动部署，自动测试，并发送一份报告，包含的是一些major path的测试用例的测试结果。从而使得我们对该版本的code有个直接的印象，从而判断是否引入我们的测试环境中。
在这个过程中使用无中生有的方法就是我们会有一个测试数据集存在于一个数据库备份中。当新的build部署完毕后，restore这个backup的db，能够迅速有效的进行测试，而不浪费时间在数据准备上。
总之，这是个应用很广泛的计谋。
第八计-暗度陈仓
【释义】
此计是利用敌人被我“示之以动”的迷惑手段所蒙蔽，而我即乘虚而入，以达军事上的出奇制胜。
在测试过程中，如何使用奇袭呢。在性能测试和安全测试中，经常会使用一些欺骗系统的手段来进行测试。
实际上在功能测试时，也可以。那些写伪代码的方法都很通俗了。改数据库也是很老套的使用了。那么在手工测试中，能否使用呢？
答案是肯定的，我们来举一个示例：
我们在开发测试用例时，每个人都负责自己的功能区域，往往在这些测试用例中，有很多overlap的场景，如果都在各自的测试中包含，很容易造成资源的浪费，而且很容易出现miss scenario的情况。
这时候利用暗渡陈仓的方法就是我们对那些数据依赖比较高的测试用例集中在初始功能模块的测试用例中书写。对于逻辑依赖比较高的测试用例，集中在结束功能模块用例中书写。
第九计-隔岸观火
【释义】
此指敌方内部矛盾激化，以致公开地表现出多方面秩序混乱、倾轧。
隔岸观火的应用也是很典型的。
一种就是我们在手工测试过程中，直接修改数据库，植入一批错误的数据，从而判断系统的处理能力。
另外一种就是在性能测试中，不断的对某些冲突的资源占用过程进行增量，从而获得性能评价。
甚至从广义的说，stress test 就是一个隔岸观火的最大用处。我们通过压垮系统之后，从而使得系统出现错误频出的状态，然后我们分析这些混乱的原因，从而进行性能的调优。
第十计-笑里藏刀
【释义】
比喻外表和气而内心阴险。
在测试过程中，使用笑里藏刀的主要有以下几种情况：
1、在稳定性测试时，进行一些破坏稳定性的操作
2、在压力测试时，定期的定量的发送一些错误的请求，来衡量系统的处理能力
3、安全测试中，发送一些带壳的请求，杀毒软件的测试，这是一个重点。
一般来说，笑里藏刀的主要作用就是对系统进行一些在预先设定的错误处理之外的错误请求。或者主动攻击。
版权声明：本文出自 gigobin 的51Testing软件测试博客：http://www.51testing.com/?26810
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。