如何成长为一名业界高手？

我是一名独立顾问，很多人都表示羡慕，当然我对自己的这份工作也颇为满意：有客户需要培训或咨询时，我就奔赴客户现场，传播测试知识，coaching 测试技能，与客户共同面对工作中五花八门的测试难题，对我来说，这是挑战，也是乐趣；没有客户召唤时（一年中的大部分光景），我就自得其乐，学我想学，做我想做，对属于我的这些自由时光，我不喜欢用“计划”禁锢住自己，更多的时候是率性而为，晨起睁开眼睛，我的“内心”就迫不及待地跑过来，主动向我汇报这一天她想做什么，而我也总是能迅速捕捉她的想法，于是我们俩个一拍即合，再推窗望望天，“嗯，不错，老天也很给力”，遂收拾妥当，换上运动装，拿起背包，包里一定要放进我最喜爱的笔和笔记本，一日的徒步加读书的自由行活动就开始了……

羡慕之余，也有人请教我如何才能成长为一名测试专家？如何能成为一名测试顾问？这个问题我也思考过，就我个人的成长经历而言，简单点说，只五个字：“唯更努力尔”！要是复杂一点说，那就是：“你需要长期地、保持高度学习热情地、去探究一个个遇到的问题”。这样的例子在我 16 年的测试生涯中可以信手拈来举出很多，不过受篇幅所限，今天就只讲一个例子：关于测试分析的。《海盗派测试分析：MFQ&PPDCS》这本书不过是沿着测试分析这个点一路探究下来顺带产生的一个结果而已。

2008 年 1 月，我有幸参加了 Torbjörn Ryber 的一个 2 天版的测试设计课程。在此之前，我对测试设计的认识仅仅是停留在7年测试工作经验积累的层面，从未刻意地练习过。我在学生时代积累的好习惯：只要上课，就要认真听讲，积极思考，主动问问题。这个习惯，让我在 Ryber 的课堂上表现突出，记得 Ryber 带来 2 本他的著作《Essential Software Test Design》，用于奖励优秀学员，其中一本就送给了我。从此，这本书开启了我研究测试分析的新时代。

我知道这两个问题都太大，得一步步来解决。正所谓“知己知彼，百战不殆”，首当其冲的是要掌握 Ryber 的测试设计理念。好在我手头已经有了 Ryber 的书，所以就开始了“更努力地阅读和练习”这个阶段：这本书我从头到尾仔细翻阅了两遍，并且认真地将书中的练习逐一做过。

随着学习的深入，越发感觉到分析建模的重要性（这些已存在很多年的测试设计技术都是可以帮助我们更好地建模的有效手段），这与我们通常所说的测试设计是不一样的，而平常大部分人都没有将测试分析与测试设计区分开来。于是上网查找测试分析与测试设计的关系，终于找到一、两篇类似观点的文章，这更加证实了我的观点。那么，我们工作中在测试设计环节暴露的各种问题又与测试分析有多大关系呢？我想是时候对测试设计的问题现状做个全面的调查了。

最有效的找到答案的方式就是亲自上手实践。我选取了一个已经结束测试的项目特性，然后假设我负责这个特性的测试分析，该如何开展？

我找来所有能找到的各类文档，开始学习了解这个特性，包括需求文档、高层设计文档、底层设计文档、协议规范等，将整个特性分成四个可以单独对其测试的部分（后来被我称为单功能的 M），针对每个部分分析建模得到一些测试场景，在此期间我还想到很多更复杂的一些测试场景（就是后来被我称为功能交互的F和非功能质量属性的 Q），也顺便记录下来。我没有急着继续设计测试用例、也没有开展测试执行，而是拿着我设计的测试场景和项目已经完成的所有测试场景去比对，结果令我大吃一惊！

这次实验给我以足够的信心，至少对第一个问题有了更深入的认识，答案是肯定的，我们应该在实际工作中运用测试设计技术来进行分析建模。紧接着针对第二个问题：如何更有效地应用这些技术来开展测试分析？虽然上述的实验是成功了，可是我有多大程度上能够确保下次仍然可以有效地开展测试分析？我是否可以提炼出一些规律性的东西，以便于向更多人传递？换言之，测试分析的能力可以怎样来提升呢？看来实验还得继续。

这次实验给我以足够的信心，至少对第一个问题有了更深入的认识，答案是肯定的，我们应该在实际工作中运用测试设计技术来进行分析建模。紧接着针对第二个问题：如何更有效地应用这些技术来开展测试分析？虽然上述的实验是成功了，可是我有多大程度上能够确保下次仍然可以有效地开展测试分析？我是否可以提炼出一些规律性的东西，以便于向更多人传递？换言之，测试分析的能力可以怎样来提升呢？看来实验还得继续。

我开始选取更多项目中真实的特性练习测试分析，有时针对一个被测单功能，我会使用多种测试设计技术来建模，然后比较他们的差别。我发现现有的测试书籍或文章都是在讲述一个个已有的测试设计技术：是什么、怎么用、配有一些简单的练习。这太理想化了，实际项目中，测试人员所面临的问题要复杂的多，于是我思考的问题也越来越多了：针对同一个单功能，是否存在一个更合适的 Model 开展测试分析呢？是什么因素决定选取哪个 Model 更合适呢？这里面是否存在着什么普遍性的规律可循呢？

几个月的摸索后，一种规律性的东西渐渐浮出水面：我发现，仔细观察的话，被测对象都是有一定主导特征的，而测试设计技术也各有其优势特征，一对齿轮啮合的场景就浮现在我脑中，只要这两个特征相吻合，齿轮不就可以正确啮合了吗？这就是后来提出的 PPDCS 的思想。

MFQ&PPDCS 的思想成型后，我开始在国内外的各种会议上分享，也组织一些培训。我想收集大家的反馈，不断优化它。不过几年的时间下来，收效甚微。我发现绝大部分听我分享的人都没有做到这份“更努力”：课上鲜有人“更努力地思考和提问”、课后鲜有人“更努力地阅读和练习”、更别提事后的“更努力地收集和整理”以及“更努力地尝试和分析”了。

不过，我还是发现了这个 MFQ&PPDCS 框架所缺失的一块：我找不到一个合适的方法教会别人如何将一个复杂的特性划分为多个可以独立开展测试分析的单功能。如果给我一个测试特性，我会轻松地划分出多个单功能来；但是如果问我“根据什么原则划分的？”我会觉得没有什么原则，就是根据经验。这显然不是令人满意的答案（注：熟悉敏捷的朋友可能要说，可以参考划分 Story 的思路啊，其实 Story 和单功能二者的目的不一样，一个是为了开发而划分、一个是为了测试而划分，思路只能作为借鉴，不能等同起来的）。

2013 年 1 月，我报名了 James Bach 的线上课程 RTI Online，James 谈到的 Heuristic Testing Strategy Model 以及 Product Coverage Outline 等概念给我以不小的启发，我预感到对这些概念的深入理解和刻意练习应该会有助于我找到一套如何有效划分单功能的方法。

2015 年开始陆续做了很多的测试咨询（主要是 coaching），当我 coach 一个 tester 时，我们一起完成一个真实的特性的测试分析工作。我立即发现，我的工作思路与所有与我结对的 tester 的思路存在着一个很大的不同：我总是先问出各种各样的问题来收集信息，而他们一上来就想立马开始测试设计。我意识到，我收集信息的目的就是为了后续划分单功能做准备的，我不会急于开展测试设计，而是从 High Level 到 Low Level 的层层细化开展测试分析，最后才开始测试设计。于是，我给这种事先问出很多问题的做法起了两个名字：Know Your Mission 和 Testing Coverage Outline，并把它们也融入 MFQ&PPDCS 这个框架体系中，这样我就可以有章法地 Coach 别人如何一步步地分析一个复杂的事物，如何有效地划分出单功能了。