2016年5月28日，华为开发者汇南京站在安德门黑马路演中心圆满落幕。本次沙龙议题增加到六个，时间安排上也从之前的半天扩展到全天。讲师有来自华为、苏宁、途牛的多位好手，议题涵盖”通讯即服务“、”内源开发“、”探索性测试“、”容器技术”、“电商平台迁移”、“订单架构优化”。
经过中午的短暂休整，第三个议题——由华为测试专家叶飞池带来的《CloudCube探索测试实践》开始了。这个看似枯燥的议题居然成为当天最吸引女生的议题。叶飞池对大家分别阐述了剧本型测试和探索性测试的价值，并分享了几个有意思案例。
现场实录如下：
大家下午好，先介绍一下，我是2005年进入华为的，一直在做软件测试，对开发也不太懂，刚毕业的时候做了一下开发，主要是做软件测试的相关技术工作。我想问一下今天来到现场的朋友做测试的多吗，能不能举个手。也不是很多。我今天讲的是做的云产品CloudCube，是一个云平台，pass层的云平台，在上面做探索性的实践。
我想再提问一个问题，大家知道什么叫探索性测试，或者探索性测试和其他测试的区别吗?
提问：探索性测试好像没有固定的定位吧，以前我们传统测试是有一套。
嘉宾：对，也可以这么说。探索性测试是针对原来的剧本，原来的一套一套测试来说的，发现原来的测试，一些问题不好解决，这时候就引入探索性测试的说法，也是这几年在测试领域比较火的。探索性测试，之前剧本的测试里面我们跟着SE，或者跟着开发那边，一个需求，一个迭代，一步一步的来。以前的剧本测试还能够形成固定下来，很多模式都是定的情况，就可以比较好的一步一步的进行。但是现实的情况，我们现在的迭代越来越快，很多时候我们写的剧本测试会跟不上。
我之前是做测试团队的负责人，待了几年，也是新员工，大概是2013年的时候做了一个实践。今天时间很短，我讲的不是很全面，大家有问题可以随时提出来。今天就以四个维度来说一下，背景，策略，还有实施的效率。
开展的背景。以前是剧本测试，剧本测试依赖于前端相对比较稳定，我写完之后跟着前端需求进来，写完之后可以编下去。我之前实现的是云平台，很大的特点很多需求是不稳定的，甚至是全新的产品，包括现在大数据之类的产品，你甚至不知道它应该是怎么样的，包括前端的一些输入可能也随时变化，客户需求随时变化的。假如按照以前剧本测试的话，我们可能辛辛苦苦花一个礼拜写的设计方案，写的一个脚本，写完之后他需求变了，你又要变，这是极其浪费的。这是我要开展的最重要的背景。
还有一个目的，大家做测试的时候，特别是带测试团队的时候，你会发现我给员工测的时候，这一轮测这些，下一轮测这些，可能***轮发现问题之后，后面测的还是那些东西，感觉测不到，发现不了新的问题，你带测试团队的时候就很纠结。这时候我就想到，我们有没有一个方式改变这种状态，这是第二个原因。
第三个原因，我们在做测试的时候会一轮一轮的，一般也是安排一个(05：08)，在以前做的时候，我们自己想想吧，发散一下吧，发散一下自己看看能不能发现一些问题。一般也能发现一些问题，一般只有那些责任心比较强的同事，或者思路比较强的同事，他可能会发现有生路的问题，很多时候大家基本没有太多的产出，这是我之前带测试团队的经验。
基于这三个方面的背景，我们可能引入了一个探索性测试的实践。这是当初做探索性测试的流程，花一段时间做一个准备，什么叫探索性测试外界的专家，我也知道张波那边，很多业界的理论是有很多的，包括很多探索性测试的方法，相关的东西，进行系统性的培训。也结合我们团队人员的特点和产品的特点，来进行一些策略，包括确定探索测试的范围，这是***个步骤。
第二个步骤，探索测试之行，测试之行这里面强调测试的三个故事。在测试的过程中不断的去调整你的策略，不断的更新你的方法，类似于一个迭代过程，迭代的优化。
***是探索总结，能在我们部门的其他地方做些总结，做些方向，大家一起把这个做好。这是三个阶段。
下面就是几个关键的动作。***个关键的动作是我要确定初始的探索点，制定一个策略。探索点是什么呢，就是你要针对哪些范围进行探索性测试。为什么要做这个呢，因为我们产品很多，如果每个地方做，能力是不够的。二八原则，你要花多少精力解决20%的问题，80%的精力，要选择你认为风险比较大的地方进行探索点。
这是怎么一个分析法呢，也是分享一下，大家有不同意见可以随时提。在我们这边，***个我们是平台，从客户那边，或者如果是业务版面的话，也可以客户那边。像我们是平台我的客户就是我们的解决方案，从他那边收集他的一些问题，包括在版本上网的时候，三个版本的一些问题，确定质量风险比较高的一个特性，首先这是***个选择。
第二个选择就是对于older的问题进行更新分析，older的问题是华为的一个特色，我们提问题单词，测试的时候提一个older new就表示是我这个版本新的特性。older可能是三个版本，我上一次应该发现的而没有发现的，到这一轮才发现，定义一个older。定义有什么好处呢，可以针对我为什么遗漏了这个older的问题，所以这个也拿来进行内部高风险的分析。
第三个选择就是历史上版本的限制，包括明确写的他可能没做好的，或者有高风险的，调整版本的。基于这三个方面的话进行一个综合的评估，或者综合的一个选择，我哪些需要进行测试。一般就是很高风险的，可能会出问题的，进行探索性测试。
右边的图就是针对我们的产品，我负责的一个产品的测试，排了一个优先级。这是***个关键的动作。
第二个关键的动作。***个是选择范围，第二个是选择谁来做的问题。谁来做，***个步骤首先要有一个经验比较丰富的，测试领域比较丰富的人，首先要选择探索性的测试方法，探索性的测试方法在业界好几十种，今天也不细讲了，其实基本上大家都用到的，在业界进行一些总结，进行一些梳理输出的一个方法论，在外界都能搜到，感兴趣的可以下载，也可以找我交流。***个是对测试比较有深入研究的，或者有些经验的人，结合自己产品的特点，***步选取的内容来选择探索性测试的实践方法，这一步很关键，很重要。可能新员工一般是做不到的，要对产品理解，也要对测试的方法论理解，来选择确定一个方法。我记得当初我选择了大概是五个方法左右，针对我产品的一个选择，这是第二步。
第三步就是选择人员，当初我带人员的时候，团队都很新，我是做的比较久的，做了十多年。还有一两个大概有三年的工作经验，其他都是刚毕业一年的，还有一个是合作方过来的，也是刚过来的，也是一年之内的新员工。当初经过确定以后，还是选择有三年左右员工的，有一定测试的经验，有一定的逻辑思维，来进行测试。
这是第二个关键动作，怎么选择探索性测试方法和人员。当然我说的不一定对，当初我在华为内部讲这个东西的时候，不记得是哪个产品线测试的，也是做了14年了，他可能跟我想法不一样，他觉得新员工更适合做，这个也不一定。
还有一个关键工作是通过故事讲解或者是评测。大家都知道我们做测试的时候，测试报告由我们测试来出，大家要看到你的测试报告，觉得你的产品可用还是不可用，或者是哪些地方有问题。但是很多时候测试报告，我不知道大家是怎么样的，很多地方都是固化的模板，信息可能不是很多。我当时的做法是这个故事讲解，由测试人员，由特性测试负责人，或者测试的PL负责人，去跟利益相关方讲解我们产品是怎么样的，进行一个(13：11)，或者通过一个头脑风暴，邀请我们的SE，我们的开发，我们的业务客户，甚至现场给我们真正的客户，就是在外面要使用我们的，比如说运营商，说明相关的问题。
这里一个关键的地方，就是测试的三个故事，等一下可以打开看。为什么是最关键的，因为我2013年做了这个实践之后，后来我又换了一个部门，到了平台集成部门，我一直在推我的三个测试故事。我要求所有的测试人员必须能讲故事，我一直跟他们讲，测试的人员应该把自己比喻为一个销售员，你的产品就是经过测试人员去销售的，你要能把它什么地方能用，什么地方不能用，什么地方可能有问题，你要跟你的客户，跟你的利益相关人讲的非常清楚，这样才是一个合格的测试人员，这是我一直强调的。当然在2013年之后，我的测试团队里面强势运作的必须要搞一个测试故事的讲解，这个效果也是挺好的，能引导测试人员理解我的产品是什么。很多时候我们做测试管理的知道，你去问执行程度怎么样，执行完了没有，其实是没有太大的效果。他执行100%，或者他执行200%，代表什么呢，只能说(15：04)，他的问题发现了吗，或者他的问题在哪里，或者说产品的质量到底怎么样，通过执行比例是看不到的。所以我后来在团队里面强势要求三个故事。为什么三个故事讲的那么多，因为我觉得探索性测试，我的理解，或者在我团队的运用***的地方，或者最要关注的地方，就是测试三段故事，我要求测试所有人员必须能讲故事。一会大家可以打开三个故事的格式看一下。
后面的效果就不用太讲了，看看大家有什么问题，这是当初的一个比较。可以讲一点，探索性测试里面我当初发现，效率就不用看了。探索性测试有一个好处，我如果在团队里面给每个成员分解测试范围的时候，都是一个一个特性给他的，他测的时候问题大部分都是单个的。探索性测试是可以让人员能够以端到端的方式来史考，把它串起来，这时候他会发现不是他负责特性的一个问题。哪里有一个BP，29个问题里面有9个不是这个成员他负责的问题。这是一个好处。
提问：(16：55)，探索性测试跟固定测试加起来不是***吗，还有别的什么测试方法吗?
嘉宾：这里探索性测试是一个效率比，组合之后的效率比，24.017是后面的，就是我能力发现问题的效率比。
提问：那没办法了。
嘉宾：这个是说我们当时做的几个方法的总结，包括对面的探索性在应用产品里面的分析，包括测试模板的一些输出。简单讲一个，快进测试法，强调的是我的数据流在我整个系统里面流动的方向。说实话有这方面经验的人也不是让他测试就能发现问题，只是他能测试，我能有这个总结的方法引导他看到我的数据流在系统里面是怎么流动的，基于这个流动才能发现这个问题。其实这里的问题很典型，当初我们是IM，是一个客户的结权系统，在系统里面留了四五个模块，还蛮复杂的，类似于有点亚马逊里面的FM。测试了很多人，也没有发现问题，***用探索性测试方法，我就让他怎么思考这个流程，最终还是发现了这个比较深入的问题。
***一点，过程基本都讲了，不用过多的强调了，这是华为用于时间的模板写的，在座的华为的肯定知道，可以对外共享一些内容。
提问：问个问题，(19：20)互联网公司有一个特点，产品过程中不太了解他最终想要做成什么样的，或者是他虽然想要做成什么样，但是不太清楚中间有哪些东西，我们是探索性测试，再这样的一个过程中，它跟剧本型的，一般的测试怎么做一个区分，对于这种产品测试的PM应该怎么去把握这个策略。
嘉宾：尺度。
提问：对。
嘉宾：这个问题挺好，当初搞完探索性测试，在华为里面，包括业界，测试领域的张波不知道大家听说过没有，跟他也组织过讨论。如果以我的理解，原来以KPI考核或者要求情况下去看的话，我觉得这个比例可能还是在于我们怎么真正的把这个质量把握住。如果你认为这个特性测的不充分，或者是很高的风险，你就可以去选取，如果认为那个特性很一般，剧本的测试变化也比较少的，我认为剧本的测试就可以了。确实这个问题我不太很好说，这个当初也讨论很多次，这个东西我个人，刚刚是提到了为什么要有一个对产品策略熟悉的人来吧我，完全是有一个熟悉的人，或者多个熟悉的人一起讨论的。在这个团队里面，我认为这几个特性高风险的，我就选择探索性测试，其他的就是剧本测试，还要根据相关的特点。当然探索性测试和剧本测试不是完全对立的，很多时候我这轮做完探索性测试之后，探索出来的点就固化到了剧本测试里面去了，这是有一个来回交互的过程，并且每个都是一个迭代刷新的。
我觉得特别强调的是应该跟互联网的迭代模式一样，你不停的变化，不仅仅是根据产品的变化，还要根据你团队人的变化。举个例子，如果你发现这个经验，我这个开发人员很牛，他开发的东西问题不大，一般测也测不出问题，基本上你可以判断的，他做的东西我就不用太多的测，我简单的测就可以了。然后发现这个开发人员这个特性就是新员工做的，你就要加强了，要注意了，要不断的交流，甚至要跟他一起来做这个事情。
也是我的同事，不知道回答满不满意。
提问：满意。
提问：我也想问一个问题，刚刚看您介绍了三种测试方法，主要为快递测试法，我想问一下，相对于其他测试方法，那种方法的特点是什么，你们是根据什么东西，根据产品特性或者什么来选择的测试方法?
嘉宾：是的，测试方法快递法是一种，业界还有很多，有40多种，其实很多方法是应用老了，只不过我们没有命过名字，类似于快递法，就是数据流在流动，或者消息流在流动。你说的怎么结合，可能就是结合，比如我今后的产品是用户的认证系统，里面的模块有好几个，一般传递认证用户信息的话，很多用户的ID或者是密钥是一个传递的，这时候我们就想到从这个体系里面去确认这个信息流是怎么流动的，想到这个快递的测试方法。这个当然肯定要深入的去理解，40个方法到底是什么。可能我们之前测试的，慢慢的研究，有些思路在里面，但是实际那个方法论不见得是全的。这个方法在网上一般都有，都可以去交流。重要的是必须有一个对产品测试熟悉的人来进行一个选择，熟悉一个人，或者一个团队，不见得是一个人。
提问：我想问一个问题，跟传统的测试方法相比的话，探索性测试对人员能力的要求跟传统测试有什么不一样吗?就是技术、非技术的。
嘉宾：我觉得也没有太大的不一样，类似于怎么去选择人来做的时候，可能没有做过测试一两年的新员工，不太适合做这个。他可能是按剧本式的方式去测试，先培养他测试的能力，到了两年左右的时间，就完全可以适应做探索性测试了。探索性测试***调的是测试的思路和想法，就是发散性思维，天马行空的多想想。
提问：你这个探索性测试方法跟传统的测试方法，比如说我们的常理分析法是一致的?
嘉宾：这个方法论理论上是一致的，我只不过用探索性测试，我刚才说有40多种测试方法，大家可能都运用到，但是没有想到这是一个方法论。并且你在遇到问题的时候，可能没有想到用这个方法解决这个问题，你可能选择另外一个方法。这时候强调这个方法论的时候，可能更容易的发现问题。或者我理解你的问题，是不是我的剧本测试和探索性测试是对立的，其实应该是慢慢融合在里面的，才是最终的一个目标。
提问：第二个问题，这个测试你刚刚有讲过有测试报告，这个测试报告是一个模板，你这个探索性测试(26：55)。
嘉宾：就像我说的探索性测试，我把***的东西融到剧本里面去，***的报告出一份。但是探索性测试强调刚才说的三个故事，三个故事就是一个评估，不是那种说我执行了多少，用你执行的排比，不是那种执行。是指三个故事的评估，***个故事是产品故事，产品故事包括三条，什么情况下可以公布。第二条什么情况会失效。第三条什么情况可能会失效。我觉得这个产品不是测试人员能够基于这个故事告诉你的利益相关方，你的产品的质量是怎么样，基于这三条。比如我测试一个云平台，我一个应用的安装部署，我就把它在什么主网情况下安装是可以成功的，在什么主网情况下安装是可以失败的，在什么情况易满足的条件下可能会失败，这其实就是一种评估。不像我们测试报告里面，可能某一个发现局限比啊，发现问题的多少个啊，这种的评估。但是我自己个人认为，可能这个评估比那个更重要，比你完成了多少测试效率啊，发现多少问题，可能会更有效。
提问：我想问一下探索性测试跟传统测试***的区别在哪里?第二个探索性测试的引入对整个产品的测试，流程和效率上有没有一些质的变化?
嘉宾：***个问题基本的区别就是我这个测试是随着，甚至说那个东西过来之后，就是我的测试对象，我开发的版过来之后，我才会不断去测它。不像以前基本测试，我先准备好用例，准备好方案，我写脚本，一步一步的去搞。这个时候就是等它来了，我一边玩它，一边去想，这是***的区别。
第二个你刚才说的流程，我认为可能有一点点影响吧，也不能说是影响。其实你说的一个流程去看效率的话，我不知道你是怎么评估，我理解我评估的话，我一天多少个效率，多少个用例，或者我投入了多少人力，发现了多少问题。这个问题本身在流程也没有问题，但是我探索性测试应该是在这个基础上补充我流程测试可能存在的风险，来去优化它们。
提问：不好意思，我问一个问题。问一下到底怎么选择的问题，测试里面要不要讲开发人员的要求，这块从测试的角度，专家的角度讲一下。
嘉宾：对开发人员的要求。
提问：对，测试人员有没有开发方面的要求。第二个关于测试人员在整个产品设计的需求，过程之中应该参与进去没有，参加到哪一步?
嘉宾：***个问题，对测试人员开发代码能力的要求。我觉得这是分的，其实测试人员不是一个，不是一种，测试人人员有很多。像我理解的探索性测试适合于系统测试，不太适合于单元测试。这个问题可能要分几类，我认为系统的测试对代码的要求不强制，有的更好，但是系统化测试人员更强调他对产品的理解，对产品的理解更为重要。就是我怎么用的，客户怎么用的产品更重要，但是对单元测试人员，或者相对于下面一层的测试人员肯定要知道代码的。
提问：产品的开发过程中，需求的过程中参与到哪一步，测试人员怎么参与的。
嘉宾：可能还是测试人员的分类，我做系统测试多一些，我以我这边的实例来讲。我是这边团队的TSE，主要是做系统上面的测试，我可能参与就是跟着SE在前端需求上一起去做。华为这边有一个实例化需求，所谓实例化需求就是TSE，就是测试设计人员，叫TSE，不知道外面怎么叫，华为这么讲。和SE一起去分析这个需求，在SE输出这个需求文档的时候，你TSE要输出用例，输出验收用例，就是跟他一起分析这个需求，当然主要分析还是在SE那边，从TSE的角度主要是输出我的验收用例，验收场景。验收场景是要跟用户，跟提交需求人，跟SE达成一致的，主要就是这种参与。比如说STV测试的，就是跟着开发，跟着Store一起去开发，一起去写会好一点。
提问：再问一个问题，我觉得国内的好多地方测试人员跟开发人员占比比较小，这时候大家为了产品的质量肯定是要，测试力度肯定要大一点。这个时候开发人员也会充当测试人员的角色，我想问一下开发人员怎么转变一个角度测这个功能，如果是自己测自己的开发功能，会有很多找不到的地方，用什么样的管理方式，或者用什么样的思维方式做这个事情比较好一点?
嘉宾：我觉得一个结队的方式，所谓结队的方式，比如说开发这个特性，你可以跟开发人员结队，或者说在华为叫铁三角。所谓铁三角，一个开发，一个测试，一个SE，SE就是系统设计师，一起去做这个事情，就是互相协作做这个事情，这是一方面。第二个可能是交叉测试。
提问：我们做的比较多的就是交叉测试。
嘉宾：我觉得交叉测试也挺好，不同的人，换一下测试。还有一个我建议case，就是演示，头脑风暴，把大家召集在一起，去想一想，大家一起来想一想，这个效果很好。我可能每周都要求TSE跟别人(35：14)，里面会发现很多问题，并且营造(35：21)。比如我这边是平台，我的客户设计业务解决方案，到版本发布的时候才给他，发现一些问题，他可能会卡我的点，不让我过点，不让我发布。现在我们转变做法，每一个迭代都要找他一起来谈，也是学学互联网的思路，迭代式的给别人使用，让别人提早发现问题。
提问：谢谢。
提问：提个问题，您刚刚讲到现在的测试方法有剧本测试和探索性测试，具体的实施过程中，不同的单元测试，我考核测试人员很好考核，就看他有没有测。探索性测试，假如我没有在这个点，让手下人做，我怎么知道他究竟有没有进行探索性测试。我的意思是说，在白客测试也没有问题，黑客测试也没有问题，探索性测试也没有问题，有两种情况，一种情况是真的没有问题，第二种是真的有问题，他根本没有测试，在具体实施过程中怎么实施?
嘉宾：我的理解就是怎么评估测试人员。
提问：对。
嘉宾：你刚才说***种，看他测试的效率之类的东西，你觉得评估准确吗?
提问：我的意思还有一点，用这种方法在具体的实施过程中，怎样把这种方法落到实处。这种方法论肯定是你在开发过程中总结出来的方法，现在目前情况下还没有进入大规模的推广，在华为内部是这样的。如果说这种方法进行推广的话，在实施的过程中，现在人都特别浮躁，真要沉下心很仔细的按照探索性测试，一步一步的探索每个方面各种思维去想，我想有很多情况下，虽然告诉他了，但是他不一定按照你的方法来做。
嘉宾：我明白你的意思，怎么评估，探索性测试就是以三个故事来评估，他能不能给我讲清楚，什么地方可用。如果一个测试人员，他做的很深入的话，他讲的东西你一听就明白，他讲的头头是道，什么样的OK，什么样的不OK，讲的很清楚。如果一个人只是很浅的做，只是完成他的用例个数的话，比如原来我们评估他的测试效率，一天实现了多少用例，发生了多少问题。我觉得不一定的，零几年我受过一个主管的影响比较大，他给我讲一句话，测试是一个良心活，你看不出来，从他的数据来看很多时候是看不出来的，很多人一天可以发现十个问题，很多人一天就发现一个问题，但是这个问题的质量是怎么样的，一个问题的拆分是什么样的，一个问题可以拆分成十个问题给大家来提，绝对是可以的。从那个个数来评估，从那个效率来评估，我觉得只是作为一个参考，作为一个牵引的东西，不能作为主力的去评估。我觉得为主的评估，刚才举的那个例子，在我的认为中，我觉得一个测试人员就是一个销售员，你销售员能不能把这个产品讲的清楚，你讲得清楚我觉得你就是OK。当然还有一些额外的，产品出去之后的问题，包括外界也有一些数据，我认为是可以结合的。华为各个部门也是在推，包括我也是选择性的，不要强调探索性测试就是打破剧本测试，其实是一个融合，你如果作为革命者的时候，你的阻力很大，去挑战一个大的流程是很大的。我们怎么做，我们是作为一个补充，慢慢的潜移默化的做一些事情。我也比较崇拜华为里面一个叫张波的，做测试体系的人，他是测试里面我们叫他布道者，测试文化怎么推广出去。测试人员每个人都凭着自己的的良心去干活，而不是为了数据去干活。
三个故事大家感兴趣的可以再探讨，时间关系就讲到这里，谢谢。
