【释义】

还是那句话，当我们通过常规的测试方法无法发现更多的问题时，我们就可以考虑一些非常规的测试方法来测试系统。

常见有直接修改数据库，错误的指令集合，强行的打断流程，强行的屏蔽环境等等。

【释义】

在测试过程中，我们使用金蝉脱壳的方法有：

当你发现一个问题时，发现这个问题有可能是多个因素影响的。那么我们就固定所有的影响因素，然后变化其中的一个，从而一步步的排除，发现真正的主导因素。

另外就是，我们的测试用例集其实是由多个组成部分的。那种把功能测试作为回归测试的用例是要不得的。

尤其是功能与其他功能相对独立时，我们在完成了功能测试之后，就不需要反复的进行全面回归，只需要把精力放到新功能的功能测试，然后对已有稳定的功能进行主要回归测试就行了，这样避免我们精力的浪费，而且集中在易发现问题的面上，更容易保证质量。

从锅底抽掉柴火。比喻从根本上解决问题。

很多人初次接触性能测试的时候，都很迷茫一件事，这么多性能参数，到底那个是我想要的呢。然后怎么才能获得性能指量图呢。

其实很简单，做性能测试的时候，如果你没有一个明确的目标，一般都是从这几个方面着手：CPU的消耗，Memory的消耗，I/O的消耗，数据库的时间消耗，功能点的reponse time，rate和handle period。

然后，经过几次load test，就能发现那些性能对象发生的变化趋势最明显，然后就集中消耗其中一个，就能获得性能测试的目的。

另外，这也是我们在发现bug时要做的，找到真正的原因所在，而不是随便报一个表象类的bug。报bug就要釜底抽薪，找到底层原因。

【释义】

作为测试人员，在测试过程中要抓住关键。不管是制定测试计划，还是执行测试计划，书写测试用例，评审测试用例，执行测试用例，在任何一个task中，都有一个key。你必须抓住这个关键，才能做到事半功倍。

很多人都很机械的去完成各个流程，大部分人都是事倍功半。原因不是不去抓关键，而是没有弄清什么是关键。主要原因是不是每个测试团队都把所有人引入到测试的所有工作中。很多测试团的的leader都喜欢自己做一些看起来像管理的task，认为这样才是体现了自己管理的角色。

其实，这跟中国的政治素养有关系，很多人喜欢当领导，喜欢跟下面的人拉开距离。其实是大错特错的。当整个团队融入到一体，team leader只是作为一个scrum master去组织大家，而不是lead大家时，团队才成为一个敏捷测试的团队的雏形。只有每个测试人员都融入到分辨团队的关键，抓住团队的关键，指定团队的关键，执行团队的关键之后，才能算的上是一个成功的team。

这也就是为什么国内很多测试团队都无法成功转型或者无法真正实现敏捷测试团队的原因。

以自己的粗浅的意见引出别人高明的见解。

这个计策在两方面体现。

一方面，我们在测试过程中，如何进行测试是一个个人的行为习惯。但是本人喜欢快速的将每一个功能点进行一次快速的检验，目的是最快的发现该功能区域问题的分布。

这样的意念就是由粗到细的进行测试流程递归。

往往那些团队采用先测优先级高的测试用例，再测优先级低的测试用例，也贴合这种思维方式。

另一方面，就是team之间的knowledge share

一个单独的测试个体，再如何发展也有局限性。只有多个测试人员之间，和开发之间，团队之间进行大量的沟通和分享，才能从个人到团队都进行提高。

很多测试人员都老死不相往来，不愿意进行交流，这样的对个人其实很不好。

要捉住他，故意先放开他。比喻为了进一步的控制，先故意放松一步。

这是一个有关测试效率的计策。

很多时候，我们都面临的时间压力带来的取舍。有些人喜欢发现一个问题以后，不停的围绕这个问题妄图发现更多的问题。这点不能说不好，但是有时候确实要根据具体的情况而定。

如果在时间很紧急，你发现的问题优先级又比较低时，完全可以提交一个bug之后，快速的移至下面的测试用例，从而满足进度的需求。

如果时间很紧急，你发现的问题优先级有比较高，完全可以提交一个bug，然后hold相关的所有测试用例，等待开发修复后再进行测试，从而避免重复测试。

此计运用这个道理，是说战场上若遇强敌，要善用谋，用假象使敌人离开驻地，诱他就我之范，丧失他的优势，使他处处皆难，寸步难行，由主动变被动，而我则出其不意而致胜。

不管是测试人员进入一个新的测试领域也好，测试方向也好，其实都不是你想象的那么可怕。一个测试人员的好坏，虽然跟测试经验有关联，但是更多的是你测试的sense。

你的优势就在于你在测试职业生涯中那些积攒的点点滴滴的心得，这些东西不管是在什么方面都是你的优势，甚至在你的生活中。

要认清自己的缺陷，也要牢记自己的优点。任何时候都要扬长避短，从自己最拿手的地方开始入手，一步步的融入到新的环境中。

而且，技术，工具这些不是决定一个人的能力的标准，只是那些短视的公司雇佣你的理由和薪水的依据。要知道，每个人最终都会找到自己适合的位置，不要去主动挑战困难，而是要利用自己的优势来减轻困难带来的压力。

【释义】

很多测试团队，在处于2-3年的稳定期之后，就难免出现人员混日子的情况。其实，对于测试人员自己来说这也不是一件什么好事。一旦项目结束，或者要离开公司，发现找下一个工作的面变的很窄。解决的方法其实很简单，就是多学。

不要觉得什么东西现在用不到，就不去学习。甚至觉得自己已经很好了，不需要再充电了。其实严格意义来说，就简单的测试用例的编写，在当前项目组也许已经满足需要，但是换个环境就未必够用。甚至换一个项目类型，测试用例的开发策略都有很大不同。

所以借尸还魂的意义，就在于作为一个测试人员，要有危机感，不断的学习新的技术，新的理念引入当前项目也好，能够提高个人技能的事情，永远不嫌多。

【释义】

应用这个手段的示例也很多。

在我们开发测试用例时，就需要反复的审核，从而使得测试用例更加贴近用户的实际情况，打草就是反复的审核，惊蛇就是将正确用户需求反映出来，从而在测试中发现有效的缺陷。

而稳定性测试和压力测试也是如此，在不断重复过程中，发现一些逻辑错误。比如前3次都正确的流程，很可能在第四次就出现问题。最典型的是pagination。很容易在页面过多时，出现问题。

而且，很多时候大家发现，测试用例写出来之后，依据测试用例去测试，很难发现问题，问题大部分都在测试用例之外发现的。这说明在测试用例评审是，没有严格的进行打草，导致很多草地被遗漏，蛇也就遗漏了。所以，测试用例评审，必须是一个严格的执行过程，否则测试用例的意义不在，时间也统统被浪费掉了。

在测试过程中，如何使用奇袭呢。在性能测试和安全测试中，经常会使用一些欺骗系统的手段来进行测试。

实际上在功能测试时，也可以。那些写伪代码的方法都很通俗了。改数据库也是很老套的使用了。那么在手工测试中，能否使用呢？

答案是肯定的，我们来举一个示例：

我们在开发测试用例时，每个人都负责自己的功能区域，往往在这些测试用例中，有很多overlap的场景，如果都在各自的测试中包含，很容易造成资源的浪费，而且很容易出现miss scenario的情况。

这时候利用暗渡陈仓的方法就是我们对那些数据依赖比较高的测试用例集中在初始功能模块的测试用例中书写。对于逻辑依赖比较高的测试用例，集中在结束功能模块用例中书写。

此句意为我方要善于捕捉时机，伺隙捣虚，变敌方小的疏漏而为我方小的得利。

我们在测试过程中都很清楚，计划是计划，很多时候计划无法正常的实现。所以，很多时候我们需要善用顺手牵羊这个计谋。

使用顺手牵羊，其实指的是我们需要不停的check schedule。在敏捷开发过程中，我们每天都有早会，根据一些现有的问题，我们去探索一下自己负责的区域是否也有类似的问题。

还有一种情况就是，我们有时候发现一个问题，这个问题同时导致了很多其他问题，这时候我们未必是话费很多精力去把所有的问题一一发现，而是需要等待开发解决这个问题之后，才去更深更广的测试，而不是去追求更多的伪bug数目。所以，凭借QA的bug数来评价一个QA的工作质量要不得，数量和质量，以及遗漏度 都是bug这一项的单一特性。一个QA的工作质量不是简单的看bug数就行的。

另外就是在团队的training上。我们QA一般都习惯了固定在一个区域进行测试，我们要鼓励大家进行更多的业务扩展的学习。有时候没有足够的时间来进行整体培训，通过一些overlap的测试用例进行新功能区域的学习，是一个很好利用顺手牵羊的示例。

比喻外表和气而内心阴险。

在测试过程中，使用笑里藏刀的主要有以下几种情况：

1. 在稳定性测试时，进行一些破坏稳定性的操作

2. 在压力测试时，定期的定量的发送一些错误的请求，来衡量系统的处理能力

3. 安全测试中，发送一些带壳的请求，杀毒软件的测试，这是一个重点。

一般来说，笑里藏刀的主要作用就是对系统进行一些在预先设定的错误处理之外的错误请求。或者主动攻击。

此指敌方内部矛盾激化，以致公开地表现出多方面秩序混乱、倾轧。

隔岸观火的应用也是很典型的。

一种就是我们在手工测试过程中，直接修改数据库，植入一批错误的数据，从而判断系统的处理能力。

另外一种就是在性能测试中，不断的对某些冲突的资源占用过程进行增量，从而获得性能评价。

甚至从广义的说，stress test 就是一个隔岸观火的最大用处。我们通过压垮系统之后，从而使得系统出现错误频出的状态，然后我们分析这些混乱的原因，从而进行性能的调优。

【释义】

在自动化测试过程中，有时候我们需要测试的模块需要一些未开发完毕的模块的支持，所以需要我们static的提供一些方法或者数据。这种书写测试用的假模块是开发常用的方法。很典型的无中生有的计策应用。

实际上，我们在手工测试中，也可以使用这种计谋，最常见的就是是我们需要一个测试数据时，无法直接获得，那么我们就可以在数据库中直接添加我们的需要的数据。

扩展来看，这种方法在build tesing中最有效。我们现在都是自动code build 然后自动部署，自动测试，并发送一份报告，包含的是一些major path的测试用例的测试结果。从而使得我们对该版本的code有个直接的印象，从而判断是否引入我们的测试环境中。

在这个过程中使用无中生有的方法就是我们会有一个测试数据集存在于一个数据库备份中。当新的build部署完毕后，restore这个backup的db，能够迅速有效的进行测试，而不浪费时间在数据准备上。

总之，这是个应用很广泛的计谋。

此计是运用“坤下兑上”之卦象的象理，喻“敌志乱萃”而造成了错失丛杂、危机四伏的处境，我则要抓住敌人这不能自控的混乱之势，机动灵活地运用时东时西，似打似离，不攻而示它以攻，欲攻而又示之以不攻等战术，进一步造成敌人的错觉，出其不意地一举夺胜。

一般常规的测试数据设计，都是从黑盒角度进行考虑，也就是正向数据集和反向数据集。这样的话，正向数据集是保证的正确的流程和功能。反向数据集是保证了数据验证策略的完整性。

但是，如果仅仅这样，只能说我们还是从正面的效应去考虑产品的特性。

而声东击西，就是要我们不仅仅从应用层去设计测试数据，还要从逻辑层甚至驱动层去设计测试数据。我们不是单单的验证一头一尾的数据完整性，我们还要去主动验证中间数据的有效性。通过直接修改数据来实现这一个效果。

另外，声东击西在性能测试里面也是一个广泛的应用，我们在无法直接测试一个性能点时，通过对他直接影响或者间接影响的功能点进行测试，从而侧面了解该功能点的性能。

最常见的一个示例就是我们无法验证一个用户密码验证过程的性能，但是我们通过大量的有效登录和无效请求的混合用户登录集合，我们能间接的获得验证的效率和瓶颈。

【释义】

趁火打劫基本上大家都已经或多或少的用过了。

在测试过程时，我们经常能发现一个bug之后，然后在周围发现很多bug。这些bug有些是因为原生bug引起的，有些是因为修复bug导致的新bug。

所以趁火打劫的测试思想就是，一旦你发现了一个bug，就要着重的在bug的直接影响功能区域，间接影响功能区域进行更deep的挖掘性测试，从而能够更加有效的获得产品的缺陷。

只有通过趁火打劫，我们才能更加深层次的挖掘出真正的缺陷，如果仅仅是发现一个bug，根据其表象提交之后就置之不理，反正会在后期的过程中出现更大的隐藏缺陷，从而导致整体进度的延迟。

所以，趁火打劫是手段，目的是那些中间过程，临时数据集，被间接调用，或者底层代码的缺陷。

【释义】

在测试过程中，以逸待劳是对测试计划的一个有力的支撑。

我们在指定测试计划时，就需要根据具体的测试范围，测试资源，测试进度表等进行高效率的设定。

那些需要重点测试， 那些需要回归，那些需要特殊的工具，那些需要特殊的数据集，那些需要特殊的测试环境，测试对象的前后依赖性，开发的进度等等都是影响我们制定测试计划的各种重要因素。

通过测试计划的制定，我们能够在开发阶段有条不紊的进行测试的准备，从而达到并发的执行效率，而不是传统测试中，只有一个简单的时间线，所有的测试都是在要执行之前，才进行更详细的分析。

而以逸待劳就是敏捷测试的另一个优点，在你根据user story进行测试场景的设计时，就已经按照执行时如何更加有效的利用资源进行设计了，而不是传统的那种只是针对use case中包含的单一功能区域进行场景设计。

以逸待劳的核心就是提前准备而不是需要时才动手。基本上减去了测试人员在测试用例开发完毕后等待代码前这段无所事事的idle time。

【释义】

敌人的情况已经明了，友方的态度尚未确定。利用友方的力量去消灭敌人，自己不需要付出什么力量

如何才能降低测试成本呢，这是每个测试管理者最大的问题。在传统测试过程中，一般是开发将代码开发完毕后，移交给测试人员进行测试。一般开发人员会进行单元测试和集成测试。

然而，在现在敏捷开发的过程中，开发人员也必须进行一些功能测试，尤其是自动化测试的大量引入，很多人都觉得开发人员必将取代测试人员的角色，从而使得测试人员这个角色逐渐的消亡。

其实这是一个很片面的想法。在敏捷开发过程中，测试角色不是被削弱或者是被取代，而是更加的被强化，测试驱动开发测试敏捷开发的真髓。

在测试驱动开发的敏捷开发过程中，测试人员和开发人员同时对user story进行分析，开发人员根据其进行代码实现，而测试人员是通过书写相关的测试场景来验证开发人员实现的质量。

也就是说，测试人员不再是去根据需求和设计文档在后期进行代码实现度的验证，而是转变为依据或者是贴合最终用户来控制开发的方向和质量。

验证标准也从了是否完成了预期的设计变成了是否满足了用户的需求。

所以，借刀杀人已经成为普遍的开发策略。核心的想法就是，开发人员在做完常规的单元测试和模块测试之后，必须依据测试用例对代码进行功能测试，只有那些完成了p1&p2测试用例的代码，才会提交给测试人员进行测试。

这样的好处是：

1.在开发阶段就能评审代码是否符合用户需求，这是敏捷的灵魂。

2.在测试阶段减少大量因为P1&P2导致的等待时间和重复测试率。

3.开发测试的用例可以是手工测试用例或者自动化测试脚本，这样的话加强了测试人员和开发人员的交互，不再是单纯的质量保证，而是主动质量控制。

所以，借刀杀人的最大核心就是，那些测试用例需要开发人员来执行。这就是测试用例要分层的原因所在，只有分层的测试用例，才能很简单的提取一个测试集合用来执行借刀杀人这个计谋。

【释义】

进攻兵力集中、实力强大的敌军，不如使强大的敌军分散减弱了再攻击。攻击敌军的强盛部位，不如攻击敌军的薄弱部份来得有效。

围魏救赵其实说起来很简单，大部分人也都试用过。那就是把要测试的对象不断的拆分，一直到最simple的程度。从而避免因为测试一个过于复杂的对象导致bug的遗漏。

这个过程其实就是一个break down的过程。简而言之，就是对一个对象的测试用例进行分层的过程。

我们在测试用例开发过程中，一定要引入分层的概念，这样的好处不但利于我们在各个测试阶段simple的工作从而准确定位bug，而且有利于我们在需求更新时，更加快捷有效的更新我们的测试用例。

一般测试用例分层的策略就是：

1.UI层，只考虑GUI的范畴。

2.Field层，考虑的是各个element本身自有的属性逻辑。

3.Functional层，考虑的是单个或者多个element的实现的业务逻辑流和或者功能。

4.Business Rule，考虑的是上下文，和直接间接被影响的功能区域。

5.安全测试，考虑的是相关的安全策略。

总之，所谓的围魏救赵，目的就是通过将测试对象细化，降低测试的复杂度，有利于我们通过一点来击破整个屏蔽，减少测试的成本。