在很多产品研发团队中，当有
产品演示、
验收这些和交付有关的活动时，测试工程师都是
核心主力，把测试人员作为主要的任务执行者是很自然的选择。
在我们的测试团队中，大部分的测试工程师都参加过各种形式的产品交付工作，但是通过产品交付活动
崭露头角的，都因其在这些活动中展现出来了测试执行以外的能力，比较典型的大约有两类：
1、结合自己行业、业务、客户的理解，在
演示、验收、体验测试、beta测试、客户问题分析等产品交付相关活动中，通过和客户的沟通不断
完善需求信息，并用这些信息开展基于需求的测试，先于客户
发现需求设计、实现的问题，帮助研发团队
缩短从需求提出到商用的周期。
2、结合良好的
沟通能力、管理能力、问题处理能力，在演示和验收等产品交付活动中占据了
主导地位，并在活动结束后主动
总结，把产品交付的各项工作加以
规范，把后续项目的产品交付活动引向
正轨。
8.1
代表客户测试
在我的经验里，影响产品的竞争力、定价、市场定位的全新开发的主要特性，通常要到第三个版本才能上线稳定运行。
在第一个版本里，客户可能会发现业务流程
不满足需要，存在新特性与既有的业务有
矛盾、
不符合一贯的经营逻辑、流程
缺少重要的功能环节、
缺乏配套的运营方案等问题，导致特性
无法使用和运营。
在第二个版本里，特性的主流程
基本符合要求，可以
小范围试用，使用中可能会发现新特性
缺乏主要的处理分支、
某些条件无法正常使用、
某些角色无法获取操作入口、处理流程存在前后
矛盾等影响大范围
推广使用的问题。
在第三个版本里，绝大部分的需求问题解决
完毕，满足客户的业务场景
需求，特性可以
大范围推广使用。
特性的第一个版本是
投石问路，进入第二个版本，完成特性需求的
正式开发，特性的第二个版本仍需要经过若干版本不断地调整需求、修改问题，最终到第三个版本才能达到正式上线
应用的条件。而
代表客户测试的目的，就是缩短这个进程。
【价值体现】
帮助改善需求质量、提前暴露需求问题，缩短从需求提出到商用的周期。
可以解决的典型问题如：交付给客户的新特征因缺乏必要的配套功能而无法正常使用；交付的特性不符合客户的需要；版本交付给客户后伴随着大量变更需求等。
测试人员需要利用自己对产品
业务领域的理解，在需求评审中、在基于需求的测试中，
先于客户发现需求的问题，帮助研发团队尽快做出“
有用”的特性。
【核心工作】
代笔客户测试，最核心的就是基于需求测试。
1、
改善需求质量。利用需求内容模型（5W1H）促进需求内容完整性的提升，利用测试对产品、业务的理解，通过静态测试发现需求中的遗漏、矛盾、错误，从而改善需求，即测试设计输入的质量。
2、
基于需求测试。根据需求进行单个操作、业务场景和应用场景的测试。
【方法和工具简述】
不同类型的需求，其需求分析质量是不一样的。
对于
基本型需求或者效仿竞品的需求，在需求分析时可以将竞品或客户现有的手工操作流程作为形象的、可操作的参照
对象，并非完全抽象分析。因此客户和需求工程师对特性的顶层设计基本上是
完整的、准确的，可以保证特性是
有用的，缺陷主要出现在细节的
遗漏或者实现过程中的
偏差需求。
对于
期望型需求和
兴奋型需求，客户希望解决的是他们
面临的新问题，客户和需求工程师对特性的顶层设计基本依赖抽象的分析和推演，想要使顶层需求完整、准确就非常
困难了，研发团队根据纸面上写下来的需求进行开发和测试，就难免做出“
没用”的特性。
项目活动：需求分析-迭代开发（设计、编码、测试）-验收
测试活动：需求评审-体验、演示、（基于需求的）系统测试--
主要方法：评审三部曲/需求内容5W1H模型--业务场景测试设计/应用场景测试设计/仿真或模拟测试执行
参考信息：知识库（客户信息库、测试资产库、产品配置库等）
本节介绍的是用于期望型需求、兴奋型需求验证的方法。
8.1.1需求5W1H分析
需求的5W1H内容包括：
业务需求（why）。客户想要解决什么问题，达成什么目的。这是客户提出需求的根本原因。
用户需求（who,where,when,what）。由什么角色（who），在什么条件下（when），在哪个功能入口（where），使用什么功能的什么操作（what）来达成业务目的。
软件需求（how）。如何实现用户需求，这是软件需求规格说明书的主要内容。
现实项目中，测试获得的需求通常只包含what（通过合同或用户需求文档）和how（软件需求文档、设计文档），通过特性的演示、体验测试活动和建立客户信息库，能够将who、where、when的信息补充完整。但是，对于期望型和兴奋型需求而言，
最重要的是why，只有围绕why来测试和评估，才能真正发现用户需求和软件需求
遗漏以及
错误的问题。
在需求调研时，业务需求通常并没有被清晰陈述。由于功能需求背后的商业目的或管理目的，一般是通过和需求工程师或客户的深入沟通才能获得，因此测试工程师首先要了解产品
应用行业和客户的
组织结构以及职能，以获得和需求工程师或客户平等对话的资本。
测试工程师进行需求分析整理的主要目的，是更有效地发现需求的遗漏、不一致或偏差等方面的缺陷，而不是需求本身的挖掘和分析。
对5W1H信息齐备的需求，测试可以对需求进行静态测试、动态测试，并在测试结束后根据需求进行特性的质量评估。
为了使需求的质量满足业务场景、应用场景测试的需要，需求的5W1H信息应该完整。
8.1.2端到端应用场景测试
产品需求分为软件需求、用户需求和业务需求，相应的，基于需求的测试也分为三种：
1、
基于规格的测试。即基于
软件需求进行测试。测试对象是
单个操作。测试的目的是验证在各种条件、输入组合情况下，操作的结果是否和需求描述的一致。
2、
业务场景测试。基于
用户需求进行测试。测试对象是完成一次
业务处理的一组操作。测试的目的是验证在各种条件、输入的组合情况下，业务处理流程和操作结果是否和需求描述一致。
3、
应用场景测试。基于
业务需求进行测试。测试对象是针对
一个商业或管理目标完成的业务处理、运营、管理等一组操作。测试的目的是验证操作的过程、操作结果之间的逻辑关系和需求描述的一致。
基于规格的测试：软件需求（如何实现）；how；
业务场景测试：用户需求（谁，完成什么任务）；who、what（功能需求）、where-when（上下文）；
应用场景测试：业务需求（解决什么问题，达成什么目的）；why；
单个操作、业务场景的测试由于依据比较
明确，在现有的常规系统测试中已经能够
完成。应用场景测试虽然也是依据合同或用户需求，但需要把
分散在各个特性中的需求
整合成一个有明确业务目的的和含义的完整场景，测试重点是产品的
特性组合，难度相对
比较大，大部分项目的常规系统测试
尚未包含这部分内容。
应用场景测试常用的分析和设计方法如下：
| 分析方法 | 设计方法 | |
| 工作流 | 用户的业务请求在产品内的传递及处理过程，包括每个环节涉及的角色、触发的动作、使用的临时和永久数据对象、对数据对象的操作 | 流程图的：语句覆盖、分支覆盖、路径覆盖 |
| 任务对象状态迁移 | 实现业务流程控制的程序对象从创建到销毁的状态迁移图 | 状态迁移图的：迁移覆盖、迁移对覆盖 |
| 数据对象状态迁移 | 业务流程涉及的主要数据对象从创建到销毁的状态迁移过程 | |
| 数据CRUD | 业务流程涉及的主要数据对象的CRUD（创建、修改、使用、删除）矩阵 | 功能交互 |
任务对象状态迁移和工作流都是对
业务处理过程进行建模；数据CRUD和数据对象状态迁移都是对
数据对象进行建模。
在应用场景的测试设计中，可以
先采用数据CRUD分析找到需要进行组合测试的特性，
然后再对这些特性共同操作的业务、任务对象或数据对象进行流程图或状态图的
分析，
最后根据分析结果进行测试用例的
设计。
和其它的测试活动一样，业务场景和应用场景测试也是为了发现缺陷，得到测试数据，也需要在测试完成后，根据测试结果评估产品质量。
发现缺陷。从我们产品的项目交付经验看，开展端到端的场景测试除了确认业务需求是否满足，还能够发现需求的完整性、一致性的缺陷。
1、功能性方面的典型缺陷，如：业务流程；运营、维护、管理；
2、一致性方面的典型缺陷，如：数据对象；角色；概念和术语；
3、性能稳定性方面的典型缺陷，如：数据对象；状态机；
特性质量评估。根据静态测试（需求评审）和动态测试（业务场景和应用场景测试）的结果，可以得到以下评估结果：
1、缺陷遗漏。
2、商用目标达成。
8.1.3测试保障质量的三个层次
代表客户测试，是在测试“拦截缺陷”这一价值的基础上的提升，除了具备“拦截缺陷”中提到的能力，还需要掌握如下能力：
业务场景、应用场景测试。
需求分析。需求5W1H分析的基本过程、方法和技巧。
领域知识。
产品知识。了解产品架构，熟悉已有特性的使用方法、约束和限制，了解特性测试和应用的历史问题。
沟通能力。
质量保障的3个层次是：
使质量符合
设计要求。这是最基础的质量保障价值。
使质量符合
客户要求。其价值是提升基本型需求的研发质量。客户视角发现问题。
使质量符合
客户期望。其价值是提升期望型、兴奋型需求的研发质量。发现与客户期望的偏差。
8.2产品交互专家
对于项目型的产品，新特性在最终交付给客户使用前，会有一系列产品交付的相关活动，包括：研发过程中的客户体验测试、现场演示、产品验收、产品上线、客户培训等。其中，体验测试、现场演示、产品验收很多时候都是由研发人员负责实施的。
演示和体验活动一方面是使客户建立对质量和进度的信心；另一方面是与客户进一步就需求达成一致。这些活动所用的产品版本很可能尚处于开发阶段，流程分支、相应的数据管理功能都不具备，主流程可能还有缺陷。产品交付专家需要在这样的条件下，
绕过所有的问题和陷阱，
确保业务演示和体验顺畅、完整，达成预期的目标。
验收活动所用的产品版本一般是
正式发布的版本，但这并不代表验收过程会一帆风顺。验收过程中一方面会发现
新的缺陷；另一方面客户会根据新的业务流程提出
新的需求。产品交付专家就需要在这个时候，迅速
甄别客户提出的是需求还是缺陷，并分别进行妥善处理，确保验收活动按计划达成目标。
想要准确地甄别和处理问题，产品交付专家需要
深入熟悉产品特性，对特性的使用方法、约束和限制、存在的陷阱都很熟悉，遇到环境或产品问题能够快速定位、解决或规避。测试工程师作为产品的第一个用户，在产品测试过程中有条件掌握这些知识和技能，因此，通常都是交付活动的主要执行者。
【价值体现】
产品交付专家
主导完成产品交付相关活动，按计划达成活动目标。
解决的典型问题如：演示阻塞或中断；未及时解决或厘清责任，使得计划延迟；过程和任务管理混乱，问题和风险未有效跟踪；未有效引导新增需求，造成后续项目增加不必要的需求分析和澄清等。
产品交付专家是项目型产品的测试团队的重要价值之一，这一价值是测试工程师解决问题能力的体现，是
乱世里出的英雄。
【核心工作】
产品交付活动是管理和技术并重的。和其他的研发活动的管理工作一样，产品交付活动也包含范围、进度、预算、质量、人力、问题和风险的管理和沟通。技术方面，有与其他测试活动一样的活动，如设计用例、搭建环境、执行用例、评估结果；也有需求沟通方面的活动。
在测试相关活动中，测试设计主要的业务场景、应用场景的测试用例设计；环境搭建和用例执行主要是仿真或模拟测试。由于这些测试执行中会遇到环境或产品问题，因此需要产品交付专家额外具备
问题定界和解决的能力。
在产品交付活动中，客户看到的不再是抽象的、纸面上的需求，而是具体的、可以交互的特性，这时客户对于需求肯定会有更多的想法。因此，产品交付专家不可避免地需要承担部分的需求采集和澄清工作。
管理方面，除了需要把活动本身管理好，作为一个有持续改进意识的产品交付专家，可以在活动结束后采取以下行的：
1、
主动总结过程中的问题和经验，把产品交付的各项工作加以
规范，填补这方面流程和规范的空白，把后续项目的产品交付活动引向
正轨。
2、对活动中
暴露的过程和产品问题进行回溯和分析，找到导致这些问题的产品研发过程或产品本身的
根因，并推动研发团队重视问题、实施
改进。
综上所述，产品交付专家除了能够做好测试工作、管好产品交付活动本身，还需要承担需求采集的部分工作，有比较全面的问题定界和解决问题的能力，最好还能够制定过程管理和活动实施的相关规范，推进研发持续改进。
【方法和工具简述】
当产品不满足客户对功能和质量的要求的时候，有两个解决思路--
减少问题和降低问题影响。
当产品在交付时或应用后，由客户发现了较多缺陷，解决的思路有两种。一种思路是在研发阶段尽可能拦截这些缺陷。可以通过流程改进，把原来集中到研发最后阶段做的事情提前，把客户问题变成研发中间发现的问题（测试尽早开展），也可以让测试人员使用客户的方法评估产品，使得在研发过程中就能够纠正问题（代表客户测试）。这一类方法都是使问题提前暴露，在产品交付使用的时候问题已经得到解决。这是“
治本”的思路，需要多次循环、不断积累，因而落实起来必定漫长。
产品到了交付环节还是有一些问题没有解决，测试人员作为活动的负责人，需要及时地就问题进行解决，一方面使得活动有序开展，让客户的问题不至于影响开发进程；一方面使客户对产品按计划、按要求交付保持信心。这是“
治标”的思路，需要活动负责人有很强的个人技术和管理综合能力。
8.2.1问题定界和解决
问题的
快速定界、定位和解决是对活动负责人和任务执行者的主要挑战之一。
首先是问题定界，即：在体验测试、现场演示、客户培训活动中，需要确定
出问题的子系统、模块；在验收和上线测试中，最重要的是在客户的环境中，快速厘清
问题归属，找到责任解决问题的产品。
问题定界
之后，如果是产品的问题，执行者需要在尽可能短的时间定位并解决问题。问题的定位一般是通过业务流程跟踪、业务日志分析或者调试实现的。定位以后的问题解决，有几种方式：
解决；
临时解决；
规避解决；
在实际工作中，问题的定界、定位和解决不仅需要测试工程师熟悉产品本身，还需要熟悉环境中的物理设备、操作系统、数据库、其他第三方产品的操作。
此外，问题的定界、定位不仅是对测试工程师技术能力的考验，更是对产品可测试性能力的考验。
与问题的定界、定位有关的可测试性能力常用的有：
跟踪能力（产品具备对业务流程的操作序列、数据路操作、内外部接口等的跟踪能力）。
过程记录（产品能够提供业务处理过程的详细记录）。
快速地将问题定位并解决，这是产品交付活动需要测试工程师的主要原因之一，但是并不是所有的测试工程师多一定能养成这个能力。
产品交付专家可以考虑以交付活动中的问题为契机，推动产品可测试性提升。
8.2.2需求采集和澄清
在这些活动的进行过程中，客户会冒出很多想法，他们也不会因为面对的是测试工程师就不提出这些想法，而且，根据“首问负责”的原则，客户也希望测试工程师第一时间给出反馈，或者在确认之后给出答复。
客户提出的新想法会有几种结论：
新需求。业务需求是明确的，产品侧在现有框架下能够实现绝大部分的主要功能需求，值得进一步进行需求调研和分析。
需要引导的需求。业务需求是明确的，但是功能需求需要加以引导，找到客户和研发团队都能接受的业务需求实现方案。
已经实现的需求。这类想法不是有效需求，需要测试工程师做好解释澄清工作。
不切实际的需求。这类想法并不成熟，无法转换为可实施的业务需求和功能需求。
非需求。这类想法是对特性已有业务场景的功能、体验、安全性等改进意见，严格来说并非需求。
产品交付专家首先是产品业务测试专才或者跨产品业务测试专才，研发团队如果缺乏这类人才，负责活动中用例执行的测试工程师不熟悉交付活动涉及的每个特性、每个业务场景和项目的原始需求，就不可能甄别客户的想法应该怎么处理，也就不可能进行需求的初步采集和澄清工作。
除此之外，产品交付专家需要有良好的沟通能力，有不同项目的交付经验，掌握基本的需求采集和澄清的技巧。
8.2.3项目管理和流程制定
产品交付相关的各个活动，其管理
难度是不同的。
体验测试、现场演示、客户培训等活动的特点是：
周期短；
人力少；
计划：只需要安排业务流
程设计、测试执行的
时间计划，落实
环境保障、
故障迅速排查的责任
组织或个人；
范围：一般是
全新的，或者与之前区别
较大的有限几个业务流程，用于
确认相关业务场景和功能需求；环境：一般是
研发环境，或专门交付
活动的环境；风险：事先
预演，一般风险
小；
因此，这类产品交付活动
作为一个任务管理即可。
产品验收和产品上线等活动的特点是：
周期较长；
人力较多；
计划：除了测试本身之
外，还需要
计划和跟踪设备、产品准备情况，根据测试计划和进度
协调客户、研发团队和第三方厂商及时投入人力；
范围：测试内容包括产品的
全部业务流程、运营、维护、管理操作，以及主要的
DFX能力，用于
确认产品已经按照需求开发完成，质量符合合同约定；
环境：在
客户场地、新建或利用现有的生产环境；
风险：
过程中会有一些产品问题需要
记录、跟踪和闭环，也会有
环境、人员、时间等风险需求跟踪、管理；
由于活动进程长，涉及角色多，影响进度和质量的要素复杂，所以需要具备
一定的项目管理能力才能胜任。
范围管理上：必须及时引导客户把需求交给需求工程师，并继续聚焦测试活动。
时间和成本上：时间和成本管理都围绕测试任务的
安排。核心的任务包括：全部业务流程、运营、维护、管理操作，以及主要的DFX能力的测试设计、评审和执行。其他强相关的任务包括：设计到位和检测、环境安装和调试、报告的编写、评审和审核。这些任务的
耗时和先后
顺序，决定了活动总的周期、需要的角色及其参与时间。
质量管理上：主要是
缺陷管理，包括缺陷的报告、跟踪、验证，以及事后的分析改进。这些活动一般不需要制定质量计划。
沟通管理上：非常重要，其中最重要的是
例行报告。这个周期性的报告，一方面是通报产品质量和活动的进度受控，以建立各方的信心；另一方面是及时求助，以获得各方在投入上的支持。
除了周期性的报告，还要为缺陷、测试用例执行记录和结果等信息建立固定的传输渠道，保证参与活动的基层人员和管理者都能够及时获取详细信息。
测试人员需要熟悉流程的基本要素和制定要求，但并不需要为交付活动定义严密的、重量级的流程。
产品验收和上线的了流程定义和活动指导，一般只能解决
本环节管理方面的问题，大部分问题需要通过研发过程中的产品、研发能力和流程的改进才能
彻底解决。
8.2.4产品交付专家的能力模型
产品交付专家首先是产品业务测试专才或者跨产品业务测试专才--
对内熟悉产品的已有特性及其业务场景、原始需求，以及配置和使用方法、约束、限制、遗留缺陷；
对外熟悉产品应用的行业和客户。有丰富的产品测试
经验，测试过大部分主要的产品特性，也能完成主要测试类型执行和问题分析。
业务测试专才在主导完成产品交付相关活动时，需要实现按
进度计划达成业务
目标，这需要具备以下能力：
具备一定的
项目管理能力；掌握
基本的需求采集技巧；掌握环
境和业务问题的定界、定位和解决方法。
8.3小结
测试工程师由于自身工作性质的原因，具备了产品演示、验收这些和交付相关的活动所需的技能，也常常在这些活动中承担主要工作，因此，
测试价值拓展的第二部分，介绍的内容都与这些活动相关：
代表客户测试的本质是基于需求的测试，测试有必要了解
完整的需求应该包含那些信息，在参与项目交付的各项活动中，有意识地将需求信息尽可能
还原，然后再
辅以场景测试的方法，
实现代表客户对产品进行基于需求的测试，
提前发现产品应用中的
问题，
减少交付活动遇到的
障碍。
产品交付专家是在危机处理中脱颖而出的英雄，在日常工作中遇到各种突发问题时，主动承担责任，妥善解决问题，这样比较有利于锻炼综合能力，在危机出现时抓住机会。