【转】软件测试的三十六计（2）

　　【释义】

　　这是说在军事谋略上，如果暂时要以某种损失、失利为代价才能最终取胜，指挥者应当机立断，作出某些局部、或暂时的牺牲，去保全或者争取全局的、整体性的胜利。这是运用我国古代阴阳学说的阴阳相生相克、相互转化的道理而制定的军事谋略。

　　这又是一个如何进行整体测试计划的计谋。我们在测试过程中，往往测试资源和测试时间达不到我们要求。那么我们就徐哟啊进行一些取舍。

　　一些常见的运用方法就是：

　　1、去除低优先级的测试用例

　　2、移除优先级较低的user story

　　3、推迟一些复杂测试环境的测试场景，在某个阶段进行集中测试

　　4、降低测试用例的通过条件

　　5、降低user story的通过条件

　　6、允许一定的bug level或者特定的bug存在进入下一个sprint

　 　总之，李代桃僵的核心就是要取舍，如何能保证最大利益的取舍。不是所有的东西都要做到完美无缺才行，带bug release也是很常见的事。关键测试要保障这些bug不会break 流程，功能或者business rule，而且要给出work around的方法。这些东西都要包含在release notes和用户手册中。

　　第十二计-顺手牵羊

　　【释义】

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

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

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

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

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

　　第十三计-打草惊蛇

　　【释义】

　　句意为反复叩实查究，而后采取相应的行动，实际是发现隐藏之敌的重要手段。

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

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

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

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

　第十四计-借尸还魂

　　【释义】

　　此言兵法，是说兵家要善于抓住一切机会，甚至是看去无什用处的东西，努力争取主动，壮大自己，即时利用而转不利为有利，乃至转败为胜。

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

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

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

　　第十五计-调虎离山

　　【释义】

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

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

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

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

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

　　第十六计-欲擒故纵

　　【释义】

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

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

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

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

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

　　第十七计-抛砖引玉

　　【释义】

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

　　这个计策在两方面体现。

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

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

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

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

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

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

　　第十八计-擒贼先擒王

　　【释义】

　　作战要先擒拿主要敌手。比喻做事要抓关键。

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

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

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

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

　　第十九计-釜底抽薪

　　【释义】

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

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

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

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

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

　　第二十计-混水摸鱼

　　【释义】

　　此计运用此象理，是说打仗时要得于抓住敌方的可乘之隙，而我借机行事，使乱顺我之意，我便乱中取利。

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

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

　　第二十一计-金蝉脱壳

　　【释义】

　　其意是我暗中谨慎地实行主力转移，稳住敌人，我则乘敌不惊疑之际脱离险境，就可安然躲过战乱之危。

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

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

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

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

　第十八计-擒贼先擒王

　　【释义】

　　作战要先擒拿主要敌手。比喻做事要抓关键。

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

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

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

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

　　第十九计-釜底抽薪

　　【释义】

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

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

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

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

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

　　第二十计-混水摸鱼

　　【释义】

　　此计运用此象理，是说打仗时要得于抓住敌方的可乘之隙，而我借机行事，使乱顺我之意，我便乱中取利。

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

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

　　第二十一计-金蝉脱壳

　　【释义】

　　其意是我暗中谨慎地实行主力转移，稳住敌人，我则乘敌不惊疑之际脱离险境，就可安然躲过战乱之危。

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

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

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

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

　第二十二计-关门捉贼

　　【释义】

　　此计引此卦辞，是说对小股敌人要即时围困消灭，而不利于去急追或者远袭。

　　在测试用例开发阶段，就是要细分。

　　在测试阶段，就是要集中解决问题。

　　在性能测试里，就是按着预先设定的性能指标去评审性能。

　　在负载测试里，就是按照原先设定测试压力去搜集测试指标数据。

　　在压力测试里，就是过压以后，去搜集关心的系统能力状况。

　　总之，就是集中精力干一件事，不要掺和在一起。

　　第二十三计-远交近攻

　　【释义】

　　此计运用“上火下泽”相互离违的道理，说明采取“远交近攻”的不同做法，使敌相互矛盾、离违，而我正好各个击破。

　　这个的含义就是，我们要合理的利用数据和测试方法，对系统进行探索式测试。

　　除了产生数据冲突发现更多的流程上的缺陷外。系统的探索性测试就是该计策的充分利用。

　　探索测试，顾名思义就是根据已有的测试经验，根据已有的测试数据报告，根据已有的bug分析，进行主动的测试。目的是尽早尽快的发现问题。

　　一般来说，发现问题的功能区域比没有发现问题的功能区域掩藏的bug更多。所以主动去那些频繁发现问题的区域进行测试，能够减少测试消耗。

　　而且，远交近攻的策略对最近发行bug比较多的区域进行更详细的测试和对很久之前发生过bug的区域进行粗略测试是一个很好的指导。

　　第二十四计-假道伐虢

　　【释义】

　　以借路为名，实际上要侵占该国

　　看起来似乎跟测试无关，其实举个简单的例子就明白了。

　　当你作为一个团队的管理者时，你要面临的一个阵痛就是一旦有人离开，谁来代替他的位置来保障质量。

　　常用的方法就是让每个人都以作为另外一人的backup的名义，去参与测试用例的开发过程。实际上每个人都至少是另外2，3个人的backup。这样一旦一个人走了以后，剩下的人在短期内也能足够的覆盖该人的功能区域，从而给新人培训带来更多的时间。

　　敏捷开发的pair coding和轮换制度，其实也是这种意境。因为一个合格的团队，不会依赖人任何一个team member。

　　第二十五计-偷梁换柱

　　【释义】

　　比喻暗中玩弄手法，以假代真。

　　这个计策在一个拥有QA share resource的情况下很常用。尤其在外包公司中，有一个团队用于senior和junior的人员是最正常的。而客户一般都想要senior的人来提供服务，但是对于公司来说，这样挣钱太少。

　　所以一般来说，都是senior的测试人员顶一个名字，参与user story的书写，测试用例的开发和评审阶段，甚至一部分high level的测试用例的执行过程。而剩下的测试用例是由shadow的人员去执行。

　　这样既保证了质量，又保证了数量。很常见的团队管理方式。关键的如何去切分每个QA的task来满足这种轮换型的时间片工作方式。