传统的测试价值依然存在，这些价值已经被认为是测试
该做到的。这里讨论的价值点，有些是研发团队对测试的
期望，比如保障质量；有些在研发团队并没有固定的角色，但测试
有条件做好，比如产品交付。想要实现这些价值，测试不仅要做好自己的
本职，还需要把影响力
扩展到测试团队和测试活动以外，实现
额外的团队价值，就像袋中之麦
展露锋芒于外。
测试的额外价值在我们的产品团队中虽然有一些实践，但也并不十分成熟。这里写出来主要是帮助测试人确信：以
既有的能力和知识为基础，测试还可以在产品和服务中发挥
更多的价值。
这部分讨论的价值主要是两个方向：一个是
产品质量，另一个是
交付效率。这两个方向的价值实践在我们的产品中也相对比较成熟。
第7章 产品质量屏障
测试必须在产品的
质量控制中起到
举足轻重的作用，否则，实在想不出为什么研发团队要付出这么高的成本维持一个测试团队。
测试对于质量的价值有两方面：
一方面测试可以构筑一条“
河道”，随时将产品质量
约束在可控范围内，防止在产品研发过程中和产品演进发展过程中，质量逐步劣化。
另一方面测试可以打造一面镜子，系统、客观地
评估产品的质量，使产品团队对产品质量有
准确的认识。
7.1
全流程质量保障
测试活动的目的，在最早期是证明软件可以工作，后来发展成为发现缺陷，现在
普遍认为测试的目的是
参与质量管理，实现缺陷预防。
以质量管理和缺陷预防为目的的测试，在研发的每个环节都有验证和质量反馈的工作，因此测试的工作是分布在
整个产品研发过程中的，这就是
全流程质量保障。
【
价值体现】
随时将产品质量约束在可控范围内，防止产品研发过程中质量逐步劣化。
可以解决的典型问题如：邻近交付期限时缺陷居高不下、风险在项目后期集中爆发、研发各环节的进步偏差逐步增大、项目交付的特性不满足客户需求等。
【
工作的作用】
在研发的每个环节都开展验证，笼统地说是提前发现了缺陷，具体地说有以下几方面作用：
1、约束研发过程质量。一方面测试人员作为参与者之一，对研发过程的交付文档件进行评审发现缺陷，防止不满足要求的文档流入下一个研发环节。另一方面，对处于研发过程中的产品进行测试，验证质量、暴露问题，避免研发团队对产品质量的误判。这是全流程质量保障的基础工作，测试的角色是研发的主力防守队员。
2、识别和纠正信息传递失真。测试作为开发的对手方，通过验证活动发现设计、实现与需求不一致的问题，达到在研发过程在纠正信息传递失真的目的。这是全流程质量保障的核心工作之一，也是测试在质量管理中独特的作用。
3、识别和管理风险。一方面，风险是测试的依据之一，在产品的分析和设计阶段，测试需要发起风险评估，并持续跟进。另一方面，风险是测试的结论之一，测试完成后哪些风险已经关闭，哪些风险依然存在，这些风险会造成怎样的后果，一旦风险变成问题应该如何处置等，这些需要作为测试的结论写入测试报告。风险的识别与管理，需要作为主要线索之一，贯穿整个项目的测试活动。
【
方法和工具简述】
全流程质量保障，意味着测试人员会深度参与产品研发的全部环节。
为了约束研发过程质量，需要在研发过程在持续进行
静态和动态的测试。静态测试主要是针对分析和设计文档的评审；持续的进行动态测试，意味着开发新实现的需求，测试能及时验证，确认新需求已经正确实现，同时原有特性不受影响。
为了识别和纠正信息传递失真，需要在研发过程开展针对需求的静态和动态的测试。
为了识别和管理风险，需要在分析、设计、测试的各项活动中进行风险的评估、验证和闭环。
综上所述，为了实现全流程质量保障，需要做到全程软件测试，新代码快速充分验证，老代码持续验证，尽早开展需求验证。
7.1.1测试尽早开展：
全程软件测试
全程软件测试是按照软件开发的W流程模型，在软件项目的一开始即开始测试的各项工作。全程软件测试的主要作用：纠正信息传递失真，约束研发过程质量。W模型保留了V模型原有的测试与开发的对应活动。
在W模型中，开发和测试两条线均贯穿整个研发过程。研发每个阶段都既有开发活动也有测试活动，开发完成的交付件是测试的输入，同时，测试也在验证开发本阶段交付件，及其与上阶段的交付件、与需求的一致性。
全程软件测试的一个很重要的改变，是在研发的分析、设计、开发过程中同步开展静态测试，并同步进行相应的测试准备工作。
我们绝大部分研发项目都实施了全程软件测试，在实施中最
典型的问题是：
1、参与需求和设计评审，但
无法提出有价值的问题，仅仅只是提前熟悉了需求和方案，没有起到约束质量的作用。
2、需要和设计文档与最后完成的软件成品有很大差异，据此完成的测试用例、自动化方案需要进行大的
调整才能使用，造成
工作浪费。
【问题1】即参与需求和设计评审无法提出有价值的问题
真正产生价值的需求和设计评审，至少需要详细研读文档3遍，第一遍排除理解偏差；第二遍后印证，串联流程和数据模型，纠正逻辑错误、流程断点、设计要素缺失；第三遍代入既有业务流程、审计和维护流程、条件约束等上下文，分析业务流和数据流的变化，发现需求和设计对客户需求的偏离、应用场景的缺失。
我们的测试工程师在需求和设计评审中，大部分都做到了第一步，所以给人的感觉是测试评审只能发现文字错误。想要发现更高层次的问题，需要对产品的架构、设计、接口、相关协议和规范、开发语言等有相当的了解，对产品已有的特性、使用情况、质量情况有深入的掌握，对用户工作场景比较熟悉。最后还需要识别出风险高的特性重点参与评审，帮助识别风险点、控制质量。
对需求和设计文档的再次研读，可以结合特性功能测试设计进行，在对特性处理流程、流程出入口、处理的数据对象进行各种正常、异常的分析时，通常可以很自然地发现逻辑上的错误、分支或参数的缺失等问题。
想要对需求和设计提出建设性的问题，则需要结合特性的业务场景和应用场景测试设计，从特性的业务流程、运营、维护、管理的角度分析，才有可能发现需求的错误、遗漏或存疑。
对于需求和设计，有些研发团队还采用“特性串讲”的方式进行评审，由测试或者其他角色的评审人将他从文档中获得的特征信息进行重新组织和陈述。这种方式除了可以快速准确地对需求和设计达成一致，也可以较快地发现理解、逻辑方面的问题，如果串讲人能够将特性代入应用场景，甚至可以较快地挖掘需求和场景的问题。
【问题2】即需求和设计变更造成测试工作量的浪费
一方面，通过产品信息管制平台实现变更信息的及时、准确传递；
另一方面，为了避免测试分析和设计工作的浪费，建议在需求和设计阶段只完成对应测试文档的核心分析工作。测试文档补充细节，最终完成时间，比对应的需求和设计文档落后一个环节。
现在有些项目采用MBT方式展开测试，在这些项目中，测试和开发的工作基本上可以同步启动，同时开展，当然测试工作的技术时间通常还是在开发工作完成之后。
7.1.2
测试尽早展开：尽早开展需求验证
尽早展开需求验证。针对需求和场景的动态测试、客户对产品的体验、性能测试，在开发过程中进行，而不是等到项目的最后阶段集中测试。
尽早开展需求验证的作用主要是纠正信息传递失真。关于基本业务流程的重要问题尽可能早地被发现和解决，使整个研发过程都在逼近“做正确的事”。
理想的特性划分是低耦合高内聚的。但是在全部开发完成之前，测试工程师拿到的特性通常是这样的：只有后台逻辑，没有前台页面；只有业务流程，实际处理逻辑不完整；只有主流程，没有分支和异常处理；只有业务处理流程，没有配套的数据管理流程；只有流程片段，没有业务流程的完整框架。
糟糕的是，采用迭代开发模式的本意是希望在研发过程中持续地暴露问题，但实际情况是，过程中只暴露了设计上的分支遗漏、异常处理不严谨这种问题。真正导致需要实现有偏差、性能达不到要求的问题，还是在最后的阶段才被发现，而产品团队修改这些问题往往“伤筋动骨”，毫无意外，测试人员又会被问到：这种问题为什么不能早点发现？
因此，迭代模式下的测试团队必须解决这个问题：由于特性划分不大容易达到理想状态，测试也就不可能仅仅通过组织、流程上的调整，就顺利地实现对迭代的充分测试。
想要从瀑布模式转变为真正的迭代模式，在迭代过程中进行需求和场景的测试或演示，邀请用户初步体验，以纠正信息传递的偏差，必须搭建一个“过墙梯”。这个“过墙梯”就是较强的工具开发能力，通过快速开发“
临时组件”，
越过在迭代中进行业务场景、应用场景、体验、性能测试的
障碍。
7.1.3
测试充分快速地提升：新代码快速、充分验证
测试的充分性随着开发的进展快速提升，至少要能够跟上特性开发的进度。
产品的“充分”测试，不仅仅需要对新开发的代码进行测试，达到要求的覆盖率，也需要对既有的老代码进行测试。
新代码快速、充分验证是指，对特性的开发和修改，能够第一时间得到比较充分的、针对代码和设计层面的验证。新特性一旦完成，对于的测试用例和自动化工作、测试环境和数据也能就绪；特性的修改和完善一旦完成，原有的特性用例和自动化脚本也同步完成更新。
新代码快速、充分验证的主要作用是，约束研发过程质量，识别和管理风险，新特性符合质量要求，这是产品质量维持稳定的基础。
新代码快速、充分验证在实施中，需要解决两个问题：
1、用例和自动化脚本与特征代码同时就绪、同步更新。
2、特性开发完成后，特性的功能、业务场景，以及性能等测试能够在较短时间内完成，特性的绝大部分缺陷能够在迭代测试中发现和修改。
问题1，我们采取了三种办法：
1、简化用例，延迟自动化实现。在特性开发过程中完成测试方案和用例，用例简化到只有标题、主要验证目的和关键数据。待特性开发完成后，基本功能稳定后再实现自动化用例。
2、story开发测试文档合并。特性的设计和测试文档在同一篇文档中，这篇文档包括特性的设计方案，以及测试时需要覆盖的内容。特性不再有详细的用例文档，文本用例和自动化用例合并，在自动化平台上管理。
3、MBT。理想的情况是：开发和测试工程师共同完成特性的需求和设计模型后，后续的开发和测试都基于这些模型。在特性的设计和开发阶段，测试根据需求和设计方案建立模型并和特性实现方案保持同步修改，在特性开发完成后，经过最后的调试，就可以批量生成测试用例及其自动化脚本。这是目前实践过的、兼顾质量和效率的、最好的方法，但工具和技术仍需继续完善。
| 主要作用 | 问题 | |
| 简化用例 | 控制反复修改测试方案和用例的工作量 | 只是减少了测试工作量的浪费，对新代码快速、充分验证没有实质上的作用 |
| 合并文档 | 促成开发测试在设计上的合作 | 测试的工作量绝大部分积压在开发工作完成之后，在迭代的时间窗内，很难完成比较充分的测试 |
| MBT | 提升开发阶段测试工作的成效 |
实施门槛较高
留给模型和自动化用例的调试时间有限，一旦模型调试无法按时完成，新代码测试将面临无用例可用的问题
|
问题2，即特性测试执行提速。
迭代开发中进行设计验证，需要解决的技术问题包括：
环境快速获取。实现标准环境的自动化搭建。开发环境管理工具实现环境的统一管理、申请、准备、回收。
缺陷辅助定位。数据分析显示，
处理缺陷，包括缺陷的确认、重现、定位、修改、验证，大约占软件开发和测试阶段
工作量的一半。就是说测试执行过程中，大约
有一半时间是在重复操作确认问题，
协助开发工程师重现和定位问题，回归测试
确认缺陷修改正确。通过
缺陷辅助定位工具，可以
提高这部分工作的
效率。在一个用例不通过的时候，工具会自动采集缺陷所需的信息，通过这些信息，可以在无需重现、无需跟踪执行的情况下定位大部分问题。当然，实现这个目的，仅仅有工具是不够的，这需要产品人员增强日志功能。
未覆盖代码风险分析。需要在时间窗之内发现测试设计的疏漏。“未覆盖代码风险分析”是发现测试设计疏漏方法，也是评估质量和风险的比较有效的办法。代码覆盖率对于质量评估来说是很粗略的方法，但是这是目前能用到的、唯一能够满足效率要求的办法。
目前也没有发现简便、可靠的提高测试执行的效率的方法。事实上，测试执行上的真正挑战是自动化方案如何适应迭代的需要。
设计验证和需求验证，都是在迭代周期内完成新特性的测试。
7.1.4
测试充分性快速提升：老代码持续验证
老代码持续验证是指，对已经完成测试的特性，在后续的迭代开发中仍持续进行验证，确保后续的开发不对这个特性造成意外的影响。
老代码持续验证的目的是，约束研发过程质量，识别和管理风险。这是确保不发生特性丢失和意外变更、质量劣化的重要手段。
产品的特性不断增加，靠手工测试是无法实现对老代码的持续验证的，因此老代码持续验证，核心能力是新产生的测试用例需要在第一时间实现自动化，对自动化能力有以下要求：
1、
自动化覆盖率高。特性的功能、业务场景以及性能等都能够实现自动化测试，这样对老代码的质量守护才比较完整。
2、
自动化用例实现效率高。新自动化用例实现和调试的效率不低于手工测试的效率，这样自动化实现才能跟上迭代开发的节奏。
3、
自动化与CI集成。调试通过的自动化用例可以直接用于CI，CI运行几乎不需要人工干预，CI中的测试用例100%通过，已成为开发提交新代码的必要条件。更理想的情况是，新特性的基本功能测试用例在编码过程中就投入使用，这样可以起到控制新开发代码质量的目的，同时提升开发进行基本验证的效率。
总的来说，对自动化能力的要求是：功能、业务场景自动化测试用例实现的效率和手工测试效率基本持平，而且一旦调试通过，就可以用于CI，成为持续集成验证用例的一部分。这对自动化方案是很高的要求。
我们的测试团队曾经实践过多种自动化方案，其中有代表性的方案有以下几个。
1、
robot早期录制回放。
2、
TCL和TTCN编写用例。
3、
数据驱动。将测试用例的操作过程和测试数据分离，操作过程用程序实现，用例简化为一条结构化数据。是TDD（测试驱动开发）的常用方式。
4、
关键字驱动（AW）。将测试用例的操作过程和测试数据分离，并将操作过程分步骤、分层抽象成为AW，自动化用例使用AW搭建。AW是目前产品实现自动化测试的主流方案。
5、
基于模型的测试（MBT）。在AW基础上，用建模的方法进行测试设计，测试用例和自动化脚本基于模型生成。对于业务流程变化导致的用例大面积修改，可以通过调整模型实现；对于单个操作、单个功能变化导致的用例大面积修改，可以通过调整AW实现。目前主要在一些面对多个客户、每个客户要求的特性类似但又有明显区别的产品中，MBT取得了较好的效果。
AW是目前主流的自动化测试方案，而MBT四未来的主推方案。我们的MBT方案是建立在AW自动化框架和测试设计四步走基础之上的。
测试设计四步法：1、根据需求和设计进行测试建模；2、根据模型、使用测试设计方法产生抽象用例；3、根据数据覆盖原则，为抽象用例填充测试数据，形成可执行用例；4、根据经验补充其他用例。
MBT是近年来逐步成熟起来的测试技术，简单介绍下其工作原理。
总的来说，MBT就是以
需求为主要输入，并结合测试经验进行
建模形成测试模型。在模型中根据测试策略确定覆盖的重点后，
生产测试用例。在模型中根据自动化的需要进行配置和适配后，生产测试用例的自动化脚本。当需求和设计发生
变更时，只需要
调整测试模型的相应部分，就可以
全面更新测试用例及其自动化脚本。
MBT的核心是测试模型。为了满足测试设计的需要，测试模型需要具备的要素如下：
| 测试模型要素 | 测试设计内容 |
| 流程图、状态迁移图 | 业务场景、测试设计因子及其对场景的影响 |
| 数据结构 | 接口、数据库表 |
| 算法选择及其配置 | 测试策略 |
| 流程图、状态机图中动作与AW映射 | 自动化方案设计 |
MBT将测试分析和设计的内容形式化为方便机器理解的图、表，这样就可以让机器根据模型自动生成用例和脚本。MBT不仅仅是自动化技术，更带来了测试模型上的变化，这种变化至少可以达到以下这些业务改进目标：
1、使测试快速响应变化。传统上，测试是先设计方案，再编写用例，最后再实现自动化脚本，一旦需求或设计的变化发生在用例编写后，就需要大面积地修改用例甚至脚本，也迫使测试工程师不敢太早启动测试用例设计和自动化工作。MBT模式下，测试只关注建模，用例和脚本都是自动化生产的，任何时候需求或者设计发生变化，都只需要维护模型，因此可以快速响应变化。
2、提升测试设计的可继承性。传统上，继承用例主要是成果的继承，不是经验和能力的继承。MBT模式下继承的是模型、图形、表格形式的模型比文本形式的用例更直观、易理解，更容易读懂模型中包含的特性全貌、测试分析和设计的思路等信息，在特性新增或修改功能时，测试工程师愿意花少量时间读懂并修改特性原有的模型，而不是对特性重新建模。继承模型是成果的继承，也是设计思路和经验的继承。
3、更有效地参与前端的研发活动。传统上，测试参与研发前端的需求review，大部分停留在理解阶段。MBT模式下，测试分析可以从需求分析开始，一直持续到编码完成，需求变更给设计、开发、测试带来的变更工作量基本上是一样的。测试人员参与研发前端的需求review，更有可能进入到质疑、建设阶段。
实现自动化需要决定的不仅仅是技术方案，还需要用一个自动化整体策略回答以下问题：
1、是否需要实现自动化。
2、选择自动化方案。
3、从哪个接口做自动化。
选择了实现自动化测试的特性范围，确定了自动化的方案和接口，对自动化工具的功能需求基本上就可以明确了。自动化设计和实现方案在满足这些功能需求之后，为了使得工具真正在CI中使用，还需要解决两个问题：
1、适应环境变化。在环境、配置、数据变化时，保持自动化用例稳定执行，通过率正常。
2、分布式执行。自动化用例集能够分布式、并行执行。主要是有些场景对用例执行时间有要求。
解决适应环境变化、分布式执行的问题，主要从3个方面入手。
1、全局参数和测试数据规划。良好的参数和测试数据规划，能够将用例和环境之间、用例与用例之间隔离开来，这样自动化用例就可以顺利从一个环境迁移到另一个环境，从串行调整为并行执行。具体要求是：全局参数规划（原则上，测试用例中需要使用到的，所有的环境、产品、特性的配置数据，都应该设计为全局参数，这样，自动化用例从调试和测试的环境迁移到CI环境时，就不容易出现意外的执行不通过的问题）；测试数据规划（自动化用例中使用到的角色、用户、业务等的相关数据，都应该进行命名或区段的规划；将某一个区段的数据用于某个特性的测试等，这样，在用例执行的时候，就不容易出现因修改同一条数据而导致的并发冲突）；
2、AW设计实现。要使自动化用例实现高效率和稳定执行，最重要的是AW抽象程度合适、参数设计合理、设计和实现严谨。AW的设计主要是一句测试执行时有哪些操作，此外需要注意的问题：有固定顺序的操作序列尽可能封装在一个AW中，一个AW中尽量实现固定的操作序列；如果AW的参数很多，或者使用结构体类型作为参数，则应该有简化AW的方式；AW不能阻塞自动化工具的运行。
3、自动化规范。为了使得自动化用例在CI中正常执行，用例的实现必须遵循一些规则。大部分规则与自动化工具和AW的实现有关，除此之外，通常还有以下规则：全局参数、测试数据的使用规则；用例隔离规则，这是要求一个自动化用例的执行和其他用例完全无关。
7.1.5
效率和进度的风险是引入质量保障活动的切入点
首先讨论目标的设定
保障质量是研发团队对测试的
期望，但全流程质量保障要求在研发
各环节，即开发、测试、设计，都要密切配合，只靠测试自己不可能做好。
可能问题：
邻近交付期限时缺陷居高不下，原因通常是缺陷修改总是带来新缺陷；
风险在项目后期集中爆发，原因通常是缺少某些分支场景和影响因素的设计，维护、管理上的能力考虑不足，或者质量属性考虑不足；
研发各环节的进度偏差增大，原因通常是已经完成的特性缺陷不收敛，需求和设计变更频繁；
客户验收周期长，甚至需要反复验收，原因通常是项目交付的特性不满足客户需求等。
可见，想要全流程质量保障真正发挥作用，解决软件研发的问题，仅仅依靠测试团队自己是不可能做到的，必须有研发各角色的
共同参与，实施
跨团队的改进。
在开展方法和技术实践之前，先谋划项目的
运作方式，以解决“
痛点”为目标，从而获得需要的
支持。从我们的测试团队实施全流程质量保障的经验看，当一个团队想要实施全流程质量保障时，通常面临的最大问题
不是质量，
而是进度和效率。因此，用进度和效率作为切入点，使用进度和效率相关的数据作为改进
目标，会比较容易获得所需要的
资源和支持。
其次讨论演进策略的制定
全流程质量保障需要测试在组织、技术、人员方面做比较多的工作，实施过程耗时比较
长，需要选择
演进的策略。
通常软件项目都是带着
风险进行的。在这样的背景下，落实全流程质量保障有两种模式：
1、“自然生长”模式。不建议一开始就全面开展正规的全程软件测试。可以首先落实以下工作：尽早开展需求验证；新代码快速、充分验证；老代码持续验证。这些措施可以帮助尽早暴露风险并解决，以这些风险为起点，再逐步推进全程软件测试中关于评审、测试的那些措施。这样做的好处是，把一个系统的工作拆分成了若干阶段，每个阶段首先明确要解决的问题，目标和周期都比较明确。
2、“削足适履”模式。华为的典故，老板认为管理改进可以先生搬硬套，再逐步消化。我们的实施路数如下：
先按照标准的W模型（IPD流程）实施全程软件测试的各项活动，再进行改进。
无论是自然生长还是削足适履，在全流程质量保障能力建立的过程中，都需要进行一些剪裁，确定先做什么，后做什么。裁剪活动的选择必须考虑收益和条件的平衡。
选择能力建设的内容，需要从问题的影响和技术成熟度综合考虑：
有条件做好且相应的问题影响很严重的，当然是首先去解决的，但是对于成熟的团队，这种情况很少（改进的
浅水区）。
问题影响比较明显但条件不具备，可以作为专门项目，联合利益相干人共同解决，最典型的是诸如需求稳定性、验收通过率这样的问题，对很多团队来说都是顽疾，也最值得多角色组成联合团队解决（改进的
攻坚区）。
有技术条件做好但相应的问题影响不大的，建议重点考虑相关技术是否可以用于其他场景，产生其他的附加值，从而帮助解决重要问题。测试最常见的、值得进一步挖掘价值的是工具和自动化（真正应该
重点考虑的区域）。
既没有条件做，也没有必要做，当然就可以放心裁剪了。
总之，测试在全流程质量保障上的价值，并非是纯粹关于质量的，而是高效地获得更好的产品质量。
7.1.6全流程质量保障的能力模型
全程软件测试是全流程质量保障的
目标方案。
这个目标方案帮助测试工程师
思考，如何
有效地将测试的负载分散到研发的
各个环节，如何使研发过程不断释放风险，从而避免全部风险都堆积到产品发布之前。
实现全流程质量保障所需的能力，基础是拦截缺陷、测试过程可控方面的测试能力，以及按特性开发的研发能力。在具备了基础的测试能力之后，结合软件工程、产品方面的相关知识，在测试分析和设计、工具和自动化方面做深、做强。最终做到在整个研发过程中，随时将产品质量约束在可控范围内，防止出现质量劣化。
全流程质量保障的关键测试能力要求
| 测试分析和设计 | 工具和自动化 | 产品 | 软件工程 | |
| 全程软件测试 | 熟练应用测试分析、设计、建模方法 | 熟悉产品的架构、设计、质量、用户场景。丰富的产品领域知识 | ||
| 尽早开展需求验证 | 非常强的工具开发能力 | 按特性进行研发的计划和管理 | ||
| 新代码快速、充分验证 | 对特性需求进行测试建模 | 很强的工具开发能力，环境管理能力 | 熟悉产品的架构、设计、质量、用户场景（识别变更风险） | |
| 老代码持续验证 | 自动化方案成熟，能高效实现测试用例自动化。CI成熟应用，自动化用例随时可加入CI | CI通过是开发提交新代码的必要条件 |
7.2
客户视角的质量评估
需要有基于需求的测试，并且在这些测试中尽可能模拟客户使用产品的各种条件，使得测试结论和客户评价接近或一致，这就是客户视角的质量评估。
【
价值体现】
客户视角的质量评价的价值在于：使产品团队对产品质量有准确的认知。
【
核心工作】
测试需要进行研发过程和产品质量两方面的评估，客户视角的质量评估也同样包含这两个方面：
1、过程质量评估。通过研发过程数据，预测交付进度偏差、产品交付给客户后的遗漏问题数量等。评估的主要作用是，帮助研发团队做出相应地人员和时间安排。
2、产品质量评估。通过测试执行结果给出产品质量评价、产品指标实测结果。这是客户视角质量评估的主要内容。
除了对产品进行质量评估，有时还会进行竞品分析。
【
方法和工具简述】
全流程质量保障是一个
正向的手段，那么客户视角的质量评估是一个
逆向的手段。
客户视角的质量评估与提供数据的质量评估，二者的区别在于，常规的质量评估，是依据特性的设计方案、研发的计划，判断这些数据是否符合要求，数据的使用完全是研发内部的事情。客户视角的质量评估，把重点放在让
测试的数据和结论被客户认可和信任，然后再
自外向内通过测试结果影响项目走向、帮助完善交付方案。
需要注意的是，对项目型的产品，客户视角的质量评估是可以拓展的价值之一。
7.2.1
客户视角的过程质量评估
总体上包括：
计划执行、缺陷、工作量、覆盖相关等的数据。
目前这些数据主要用来提示过程风险，想要通过这些数据来进行客户视角的过程质量评估：预测产品到了客户那里还会有多少缺陷，质量表现会怎么样，项目进度会有多大程度的延期。这方面目前有学术方面的研究，工程方面没有见到使用范围比较广的方法和成功实践。
7.2.2
客户视角的产品质量评估
产品质量评估有一个很常见的问题，就是
评估结果和产品使用后的真实表现不一致。
在我的经验中，性能、可服务性、易用性方面出现指标的测试结果和真实表现不一致，这是比较常见的。功能性方面的主要问题，是不满足客户的应用场景或业务场景的需要。
测试结果和产品使用后的真实表现不一致，通常是由于测试对客户的网络、设备配置、业务流程、使用场景、使用习惯等不熟悉，导致测试的环境、操作方法、测量方法、判断标准和产品的真实使用有较大差别。
推荐的做法是在测试设计和执行时，将客户信息作为输入信息之一。
客户信息库至少包括以下内容：
环境相关的。物理和逻辑组网；各网元的设备型号和配置；包含第三方产品的逻辑组网；安全防护方案等。
核心概念。业务、运营、维护和管理方面功能、术语的概念及其定义、特殊含义。
业务及体验相关的。业务团队的组织架构、现有业务流程和操作员的橘色及其职责，操作员的IT知识背景，与主要特性关联的业务流程，运营、维护和管理操作的应用场景等。
性能相关的。容量和数据模型，忙闲时段，理论压力峰值，忙时的压力模型，主要业务在现有系统的性能指标等。
可靠性和可服务性相关的。主要运营、维护和管理作业流程及其操作时间和耗时；忙时主要业务流程及各自比例；常见故障演练的模拟方法；现有的故障处理流程等。
验收用例和工具。验收测试用例和测试结果；性能、功能测试相关工具。
主要路标版本的历史数据。产品质量指标的测试结果和真实使用结果；客户验收、使用中发现的缺陷等。
这些客户信息将帮助测试工程师实现：搭建与产品生产环境接近或一致的测试环境，设计、执行与用户实际使用相一致的测试用例，最终得到可信的质量评估结论。
测试设计、指标设计：输入多样化。
很多时候，哪怕严格验证了合同中的每一条需求、每一个指标，验收的时候还是会被抱怨出现了功能不满足要求、性能不行之类的问题。
主要是因为，在客户的团队中，分析需求和拟定合同的人，和验收、使用产品的人分属不同的团队。导致测试所依据的合同中常常出现下列问题：
1、有些现有功能的使用信息是不完整的（约束条件、操作入口、上下文、操作结果等）。
2、有些现有业务的指标信息是不完整的（比如性能测试时，通常只有TPS、用户容量、同时在线用户数等核心指标，但操作耗时、响应时间、同步时延等隐性要求则没有明确）。
因此，在测试设计中，
不仅要依据产品的合同、需求和设计，还需要考虑和客户现有的业务场景、衡量指标接轨，如果确实需求改变客户现有的习惯，则需要借鉴业务的通行做法。
性能指标和用户信息库的对应如下：
| 性能指标 | 测试设计依据 | 客户信息库对应信息 |
| 容量 | 需求、合同 | 容量 |
| 业务流程及对应的TPS | 需求、合同 | 理论压力峰值，忙时各业务性能占比 |
| 在线用户数 | 根据TPS计算 | |
| 用户数据模型 | 需求、合同，客户信息库 | 用户数据特征或模型 |
| 压力模型 | 客户信息库 | 忙时压力模型 |
| 吞吐量 | 根据TPS计算 | |
| 成功率 | 经验 | |
| 平均操作耗时 | 经验、客户信息库 | 主要业务在现有系统的性能指标 |
| 平均响应延时 | 经验、客户信息库 | 主要业务在现有系统的性能指标 |
| 数据同步延时 | 经验 | |
| 测试持续时间 | 客户信息库 | 忙、闲、高峰时段 |
| 系统资源（如CPU、内存、带宽）占用 | 经验 |
在进行性能测试之前，最好通过业务需求调研、业务流程调研、客户沟通、提前体验等各种活动，得到这些数据的目标值或者客户系统的当前值。如果部分数据产品交付还没有得到确认，就需要参考业务或其他项目的经验数据。
除了主要业务流程外，安装、统计报表、跟踪、审计等运营、维护和管理操作的性能也要给予足够的重视。这些操作的性能缺陷一般有两方面影响：一是操作本身耗时太长，结果不能及时送达至决策者；二是影响主要业务的性能，导致业务系统性能急剧降低。因此，这些操作一旦有性能缺陷，就非常容易被感知、被放大。
相比DFX测试，功能测试的信息补齐更困难。推荐的做法是建立产品验收测试用例基线，每个验收测试用例都包含操作过程、约束条件、各种操作入口、详细操作结果等信息。
对于不同类型的需求，补齐需求信息的方法也不同：基本型需求，不同客户之间差异不大，只有少数细节存在差异，可以和性能指标一样，需求调研的时候尽可能确认这些信息；期望性需求、兴奋性需求，不同客户之间差异点很多，有些甚至操作过程都不一样，测试基线能解决的问题很有限，尽早开展体验测试、特性演示等活动，或者规划beat测试是更值得尝试的方法。
测试环境：尽可能模拟
只有思科不计成本建立了针对大客户的完全镜像环境。
一般情况下，测试都只能在模拟环境中进行。对模拟环境的基本要求是，保持和客户的完全镜像环境。
除了逻辑组网一致，模拟环境的设计还需要考虑如下问题：
1、业务节点的集群规模。大型系统中，处理主要业务的网元，通常采用集群方式来实现负载的分担和性能的平滑扩容。
2、产品运行环境配置。产品运行环境指产品使用的硬件、操作系统、数据库、第三方服务等。
3、第三方产品的仿真。客户网络中通常存在由多个供应商提供的产品，产品各自实现不同的功能，通过接口进行数据交换或业务关联。
除此之外，为了顺利的展开测试执行，测试还需要具备很好的环境设备操作能力，尤其是对于解决法案干测试团队，至少需要具备以下能力：
1、熟悉解决方案中所有的设备和组网方案的配置方法，能够按照设计要求搭建和调试测试环境。
2、熟悉解决方案用户的典型端到端使用流程，熟悉所有设备和接口上跟踪业务流程、核查业务数据、获取业务状态的方法，能够在问题发生时的第一时间排除故障或界定归属。
3、具备对解决方案进行功能、性能、可靠性等质量属性进行验证、调试、配置优化的能力。
用例执行、指标测量：高度仿真
功能测试中，最好在正式测试之前或者测试完成后，用真实的设备，对主要的业务、运营、维护和管理操作的基本功能进行业务场景、应用场景的验证，确认前后台之间、特性之间能够正常配合。
客户视角的功能验证，还可以通过产品或特性的体验、演示、产品beta测试来进行。在这些测试活动中，测试工程师不是用例的主要执行者，主要职责是确定测试范围、设计业务场景或应用场景的测试用例、活动组织、旁观记录、结果分析。
性能测试中，遇到的研发测试结果与客户验收结果不一致的问题，通常是由于测试的业务流程、背景容量、数据模型等不同导致的。因此，性能测试中关注的重点主要是：加载需要的容量和压力，采集业务处理的主要性能数据。此外，客户验收和使用中常常会在一些细节上发现问题，如：
1、压力模型、测试持续时间。
2、业务处理性能数据。关注的重点通常是处理能力、容量、响应延时等，容易忽略一些比较“次要”的问题，如：
数据同步延时。需要掌握数据同步延时的实测值，之后一方面需要确认延时是否满足设计规格；另一方面需要对相关的验收测试用例做备注，说明检查数据一致性操作需要等多长时间以后再做。
临时数据规模。测试过程中需要把临时数据规模纳入监测范围，防止临时数据规模不断膨胀的缺陷。
3、系统资源占用情况。有经验的客户通常都会关注这些数据。
4、客户端、服务端采集的数据，与用户数据、业务处理数据、统计、报表的一致性。客户的经营团队会比较关注数据的一致性。
可服务性、可靠性测试执行时，遇到的研发测试结果与客户验收结果不一致的问题，通常是由于环境、操作方法、观察点不同导致的，客户进行可服务性、可靠性测试常常和研发测试有明显不同，主要表现在以下3个方面：在正常压力、容量下执行测试；可靠性测试的故障构造尽可能真实；以业务性能表现作为用例是否通过的标准。
易用性。对易用性的评估并没有完整、客观的方法，除了任务完成率、页面数、求助次数等数据外，易用性或体验的测试更多还是靠人对同类或相关产品的使用经验。因此，产品测试团队并非体验测试执行的最佳人选，客户、用户、产品经理、需求工程师、研发团队以外的人可能是最好的人选。产品测试团队在体验测试中更多的是策划测试活动、设计体验任务、提供环境保障、观察和记录数据。
测试工具，测试使用的工具与客户使用的不要存在原理上的不同。
测试可以主动和客户沟通测试方法、测试工具的原理，将研发内部测试的工具变成验收交付时的工具。
想要知道客户对产品质量怎样评价的，有两个途径：
一个途径是在正式交付前就让客户接触产品，直接得到客户的评价，这就是体验测试、特性演示，或者beta测试的目的。
另一个途径是提高测试的仿真程度，使测试得出的结论与客户评价接近或一致。通过得到与客户评价一致的评估结论，使测试取信于研发团队、取信于客户。
7.2.3
竞品分析
竞品分析会较多采用探索测试的方法，分析过程如下：
1、
探索范围确定。
2、
功能差异分析。
3、
DFX对比分析。
竞品测试的目的在于，找到自研产品和竞品的
差异，进而影响项目走向，帮助
完善产品。差异属于不同类型的特性或需求，处理方式也不一样。
基本型需求（产品必须有的属性或功能）；
期望型需求（客户期望但不是必须的产品属性或服务行为）；
兴奋性需求（完全出乎意料的产品属性或服务行为，使用户产生惊喜）；
竞品分析的主要目的是用于项目决策，因此通常发生在大的路标测试的需求分析阶段。
7.2.4
客户信息获取的渠道
产品开发：开发过程中可以通过业务流程调研、开发过程中的客户沟通、提前体验等各种活动来获取信息。
验收和生命周期管理：一方面，在研发过程中，客户对产品了解、对产品上线后如何更好地使用考虑并不多，因此研发过程中确认的客户信息，在产品验收上线后仍可能发生较大变化。另一方面，在研发过程中，很多信息客户也无法给出准确的现状数据。
总之，客户信息是在产品开发、验收、生命周期的各个环节逐步获取的，我们的测试团队目前比较重视从验收活动、产品上线运行的统计信息、客户问题分析中获得信息，主要原因是这种方式可操作性好一些。
7.2.5
客户视角质量评估的能力模型
需要测试具备的能力有：
产品质量评估。
客户信息库。
业务场景和应用场景测试设计。
仿真或模拟测试。
沟通能力。
领域知识。
对于功能体验的主观评价方面的问题，最可靠的方法，还是让用户尽早接触产品，之外还有两种值得借鉴的方法：
1、通过节目DEMO快捷开发工具实现这一目的。2、通过在内部或商用的云测试平台上发布测试任务实现这一目的。
7.3小结
动态测试是测试工程师最重要的武器，研发过程中，对产品质量的任何分析、推导都比不上实事有说服力。因此，测试的价值拓展，首先介绍的是与动态测试的相关的两类：
1、
全程质量保障上的绝大部分实践，都是将各种测试活动
前移，让研发各角色更早地看到实事，更好地根据实事情可进行研发质量管理。
2、
客户视角质量评估的本质是提高测试执行的
仿真程度，从而得到与客户感知
一致的结论。
对于客户视角的质量评估，建立
客户信息库是主要的技术手段，建立完善产品的
指标集是主要的基础能力。相比之下，后者还更重要一些。