10.1测试的
拓展价值
测试团队和测试工程师在日常生活中积累了丰富的产品、客户以及测试的知识及能力，以这些既有的能力和知识为基础，测试人员还可以才产品研发和服务中发挥更多的价值，这一部分介绍了常见的4类价值。
1、
全流程质量保障（效率）。在IPD流程下开展全程软件测试。做的是质量工作，受益的主要是效率。主要是通过提前测试，实现研发内部的效率改进。
2、
客户视角的质量评估（质量）。除了常规的测试，还用客户的方法发现缺陷，因此产品交付到客户手上缺陷减少，产品质量提升。工作的侧重点是让测试的数据和结论被客户认可和信任，倒逼研发重视测试的结果，所以，客户视角的测试是手段。目的是研发改进。
3、
代表客户测试（质量）。同样也是除了常规的测试，还用客户的方法发现缺陷，提升产品质量。工作的侧重点是利用需求的完整信息，开展基于需求的测试，发现特性到客户使用那里会遇到的缺陷，提前弥补漏洞，最终目的是缩短从需求提出到可以商用的周期，即缩短产品交付给客户使用的周期。
4、
产品交付专家（效率）。见招拆招，让产品交付活动（客户体验测试、现场演示、产品验收、客户培训）尽量不被阻塞，顺畅、高效地开展。
质量屏障与产品交付相关价值的关键技术
| 价值体现 | 核心工作 | 技术 | ||
| 产品质量屏障 | 全流程质量保障 | 将产品质量约束在可控的范围内，防止产品研发过程中、产品演进发展过程中质量逐步劣化 | 纠正信息传递失真，约束研发过程质量，识别和管理风险 |
全程软件测试：需求和设计评审；
尽早开展动态测试：按特性测试；
新代码快速、充分验证：快速测试；
老代码持续验证：自动化测试和持续集成；
|
| 产品质量屏障 | 系统的质量评估 | 使产品团队对产品质量有准确的认知，质量评估结论和客户对产品的质量感知一致 | 过程质量评估，产品质量评估，竞品分析 | 产品质量评估：客户信息库；模拟测试 |
| 产品交付先锋 | 代表客户测试 | 帮助研发团队做出有用的特性 | 需求5W1H分析，端到端应用场景测试 | 需求的5W1H模型，端到端应用场景测试设计 |
| 产品交付先锋 | 产品交付专家 | 主导完成产品交付相关活动，达成相关计划和目标 | 项目管理和流程制定，需求分析，问题定界和解决 | 交付活动的管理要求，流程基本要求，需求引导，问题定界、定位和解决 |
这里描述的每个价值点，除了测试能力需要提升，研发也需要在开发模式、需求质量、产品信息等方面做出相应的提升和调整，所以，这些不是单单依靠测试团队自身就能实现的价值，需要测试从问题出发，
推动研发团队一起行动，
共同做出改变。
10.2支持拓展价值实现的测试架构
测试架构的组件需要进行集成，满足研发提升质量和效率、降低成本的需要。集成的方案是多种多样的，取决于想要解决的问题、期望达成的目标、预计的工作场景。
10.2.1
基于需求测试的测试架构
测试架构支持的改进目标：需求实现的准确、完整，交付用户使用后的一段时间内，针对既有特性的改进、返工都很少。用户使用中发现的缺陷的数量和级别符合质量要求。
基于需求进行测试，需要测试架构具备以下特性：
1、需求
完整。除了需求本身的5W1H信息，需求的合同原文、应用场景、责任角色、组网、历史缺陷、技术风险等背景信息也要完整。
2、需求
透明传递。需求在产品内的实现方案、产品的实现方案和客户期望的应用场景之间的差一点，方案的使用约束，对原有特性或产品功能的改造点和影响面，这些在研发团队分析、设计、实现、验证等各个角色之间实现透明传递。测试围绕需求开展端到端应用场景测试、业务场景测试，以及其他功能和DFX测试。
3、需求
变更同步。测试可以通过产品信息管制平台，在第一时间获得需求和实现方案的变更信息。一方面更新相关的应用场景和业务场景测试模型，从而使测试用例和需求保持同步；另一方面通过设计方案、接口、数据对象或代码，找到受变更影响的其他特性的用例，使用两部分用例对变更后的需求及其影响进行验证。
4、
实例化需求。包含端到端应用场景基本用例的验收用例，成为与客户签订的正式需求的一部分，产品研发人员和客户通过验收用例评审对需求的应用实例达成一致。
5、
商用评估。特性完成开发后得到完整的验证，除了功能测试、性能和DFX测试外，还包括客户的体验测试、业务场景测试、应用场景测试。最终给出的产品是否上线商用的结论，包含，功能是否正确；性能、可靠性、可服务性指标；是否可运营、可管理、可维护；用户体验如何；经历安全攻击是否会造成用户经济损失或关键信息泄露等。
这是以需求为
核心的集成方案，主要是需求管理IT系统将需求的全部信息进行整合，这些信息包括以下内容：
1、需求的
分析、设计和开发，包括：说明书和设计文档、模型，需求实现的代码等，这些内容来自产品配置库。
2、需求的
测试，包括：需求的测试方案、模型、用例、用例执行结果等，这些内容来自于测试配置库；
3、需求的
背景，包括：应用场景、责任角色、业务问题、组网等，这些内容来自客户信息库。历史缺陷、同类需求等，这些内容来自测试资产库。合同原文、验收用例等，这些内容来自客户信息库。风险、客户问题，这些内容来自风险管理系统。
测试的各项活动中需要各种需求信息，例如：
需求和设计评审；测试分析和设计；测试执行和自动化；质量评估；
10.2.2
缺陷快速修复的测试架构
测试架构支持的改进目标：
缺陷修复高效、准确，缺陷一次性修复完成，修改代码不带来新问题。
经验数据显示，缺陷的定位修复差不多占研发工作量的一般，因此，
提升缺陷修复的效率和质量，是提升研发效率的手段之一。
缺陷快速修复，需要测试架构具备以下特性：
1、
快速定位信息完整。缺陷定位信息来自产品和测试工具，产品记录的定位信息包括代码运行轨迹、环境数据、用户数据、日志等。测试工具记录的信息包括追溯操作过程和操作数据，接口交互过程、用户数据变化过程等。这些信息按用例或者缺陷整合、关联，使缺陷定位有据可依，而不是靠代码调试和试错。
2、
高相关性测试用例挑选。存在缺陷的代码修改完成后，除了执行根据修改代码新设计的测试用例，还能够从测试用例集中自动挑选与修改代码
相关的用例，这样才比较全面地覆盖修改代码，及其运行上下文。
3、
测试环境快速获取。代码修改完成、用例准备就绪后，能够得到符合特性需要的测试环境，环境的配置、用户数据也按特性要求准备就绪。
4、
自动化测试。修改的代码合并到产品版本中后，需求及时评估缺陷带来的所有问题是否都已解决，修改代码对本特征或其他特征是否产生意外的影响，修改代码对产品的性能是否造成意外的影响。需要执行的测试用例少则十几或几十，多则上千，只有自动化测试才能在
规定的时间内完成验证。
为了
高效地修复缺陷，集成方案需求进行的IT系统和工具的集成，以支持以下开发和测试工作。
1、
缺陷定位。要求绝大部分缺陷不需要重现问题，只需要根据用例执行的过程记录就能完成缺陷的定位。集成工具需要具备以下功能：
测试用例管理和执行工具--将用例执行过程中产生的、由产品和测试工具记录的全部定位信息（如代码运行轨迹、用户数据，日志、操作过程、接口交互过程等），按用例集中存档，作为测试用例的执行过程记录。
编码和调试工具--利用测试用例的执行过程记录，重现操作过程和代码运行轨迹，为缺陷定位提供类似于代码调试的辅助手段。
2、
缺陷修复。要求代码修改完成后，快速挑选相关用例、搭建测试环境、完成测试执行，尽可能迅速地验证缺陷是否正确修复。集成工具需要具备以下功能：
测试用例管理和执行工具--完成相关用例的自动挑选。测试用例与代码关联、测试用例与缺陷关联、测试用例和特性或需求关联等。
环境管理工具--实现按特性提供环境，环境的搭建、配置、数据准备等工作自动完成。
编码和调试工具--在测试用例执行过程中，可同步跟踪代码运行过程。
3、
提交代码。要求开发工程师提交代码入库时，触发提交构建（仅执行与提交代码强相关的测试用例，提交构建应该在最多半个小时内返回结果），确认修改的代码不会引起构建失败。集成工具需要具备的以下功能：
构建和持续集成工具--支持各种类型的构建（提交构建、每日构建、发布构建），不同类型的构建有各自的步骤和测试用例的范围，使各种构建都满足相应的时间要求。
4、
缺陷回归测试。缺陷回归测试时，需要针对修改后的特性设计新的测试用例，以评估新方案是否正确；需要回归上次执行失败的用例，以评估缺陷带来的所有问题是否都已解决；需要回归本特性和其他相关特性的基本功能测试用例，以评估修改代码对本特性或相关特性是否产生意外的影响；需要回归本特性相关的DFX测试用例，以评估修改代码是否对DFX属性产生意外的影响。通过这些验证后，缺陷才能够正常关闭。
缺陷快速修复，在分层开发的解决方案中特别具有挑战。特性经常会由于新增需求或修改缺陷发生变更。变更发生时，除了需要根据变更内容来设计和修改测试用例，还需要确认变更是否产生了不该有的影响，这就涉及如何挑选老用例进行回归测试的问题。
挑选老用例的技术，除了常见的头脑风暴法，目前已知的技术包括：
1、
利用系统剖析图管理特性关联关系，当特性变更时，将关联特性的测试用例也挑选出来进行回归测试。
2、
建立用例和代码的映射关系，当特性变更导致新增或修改代码时，将执行这些代码的用例挑选出来进行回归测试。
3、
建立用例和接口的映射关系，当特性变更导致特性的对外接口发生结构、参数、时序等方面的变化时，将执行这些接口调试代码的用例挑选出来进行回归测试。
除了头脑风暴法，其它的方法都可以实现自动化的用例挑选。
10.2.3
测试架构的目标工作场景
测试架构可预见的目标是，支持测试实现：版本快速稳定、质量随时可视。
版本快速稳定，完成的工作成果几乎没有返工现象，经过不超过3轮的测试，产品和解决方案的新老特性都能够达到发布所要求的DFX指标、覆盖率、遗留缺陷等质量要求。
质量随时可视，从项目启动开始，持续统计、分析和发布与项目质量、产品质量有关的数据，使研发团队基于数据开展相应的管理工作。对内将质量、进度和风险持续约束在可控范围内，对外持续建立客户对产品的信心。
版本快速稳定，是测试在
质量和效率方面的业务能力的集中体现。质量随时可视，是测试在
质量和测试过程方面的管理能力的集中体现。
首先，分析版本快速稳定所需的测试能力。
影响版本快速稳定的
主要问题有：
1、
需求分析。需求分析太简单；需求变更后对应工作未同步变更。
2、
开发者测试。新功能开发或缺陷修改后，存在开发测试的困难，导致覆盖率低；老代码缺少质量守护机制。
3、
缺陷修复。缺陷定位依赖黑盒测试验证，整体效率低；代码修改后验证不足。
4、
测试策略。缺陷的发现过于依赖系统测试，研发整体效率不高，风险聚焦在研发后端；性能、业务场景和应用场景等测试开始的太迟，一些需要变更设计方案才能解决的问题，在测试后期才发现；解决方案的基本功能问题对集成方案影响重大，但相应的测试是在原子版本系统测试后才开始，一旦发现缺陷，则会对原子版本和解决方案版本设计造成巨大挑战，严重拖延发布计划。
5、
迭代测试。新特性未能尽早自动化、DFX测试自动化率低，每轮迭代只针对新增代码进行功能测试，覆盖不足，大量缺陷遗留到发布前的系统测试才发现。迭代测试发现的缺陷有限，开发团队没有每轮迭代清除全部缺陷的动力，带病迭代的现象很普遍，敏捷开发并没有带来质量和效率的提升。
6、
系统测试。测试得到的质量结论和客户使用感知到的产品质量偏差较大。一些看来是基本功能的问题被遗留到客户使用才发现。性能、可靠性、安全性等测试手段不完备，部分测试手段不能模拟真实应用的情况，导致得到的测试结论错误，缺陷被遗漏。
7、
商用评估。产品的质量评估缺乏“测试是否充分”的客观依据，结论的可信度存在问题。
影响版本快速稳定的问题及其解决方法
|
活动
|
问题
|
需要构建的测试能力
|
| 需求分析 | 需求内容不完整；需求传递不透明，变更不同步； | 代表客户测试；基于需求的测试； |
| 开发者测试 | 测试内容少，覆盖率低 | |
| 缺陷修复 | 缺陷修复效率低；缺陷修改后开发者验证不充分； | 缺陷快速修复 |
| 测试策略 | 研发前端发现缺陷少；性能、场景测试开始得太迟；解决方案测试开展得太迟； | 前端测试；需求验证提前；高度协同的测试策略； |
| 迭代测试 | 自动化实现太迟；带病迭代； | 提升自动化能力；提升每日构建的测试覆盖率； |
| 系统测试 | 测试的质量结论和客户感知不一致；DFX测试手段仿真不够； | 提升测试仿真度 |
| 商用评估 | 测试充分性无法衡量 |
为涉及的内容如下：
1、
测试充分性无法衡量；
2、
开发者测试覆盖率低；
3、
高度协同的测试策略；
版本快速稳定是测试业务能力的集中体现，拦截缺陷、提供数据、过程可控也同样是基础。
其次，分析质量随时可视所需的测试能力。
质量随时可视有两层含义：
质量可视；随时可视；
质量标志性的数据包含两个方面：一个是是
度量数据；一个是
需求特别关注的风险。
比较先锋的思路是，通过大数据分析建立质量、进度、成本之间的关联关系。该思路目前还处于理论研究阶段，缺乏成功实践。
质量的度量离不开
缺陷数据。
质量的标志性数据的另一个方面--
风险，包括风险的识别和跟踪。
质量数据随时可视，需要有质量管理IT系统的支持。要做到度量数据持续且无人工介入的采集，研发过程管理的IT化程度、集成度必须很高。
质量管理系统发布的数据，在产品开发的早期以风险跟踪数据为主；过程中加入计划、工作量、覆盖、缺陷数据；到项目的后期则是以缺陷解决、客户问题跟踪、风险闭环、指标的实测情况为主。
10.2.4
测试架构的建立
测试目标工作场景的测试架构是一个
庞大的工程，和任何工程一样，测试架构也是从基础开始
逐渐积累出来的。测试在实现自身价值、解决自身问题的过程中逐步形成了具有产品领域、业务领域特色的概念体系，积累了测试架构的基础组件和集成方案。
测试架构的集成方案，就是将各个
孤立的工具和信息集成到面向任务、入口统一、数据源一致的系统之中，实现信息充分共享，并且能高效、便捷地应用。
基础组件的集成也有以下共性的
技术问题。
1、
信息内容结构化。测试架构的基础组件中，相当大的部分是各类文档内容。有些内容是结构化的，大部分是非结构化的，甚至有时候还出现内容混杂的情况。对信息内容进行结构化处理的目的，是为了提高信息查询和使用的效率。
2、
信息关联。通常情况下，为信息增加属性，通过属性建立关联关系，这种方式具有更好的适用性和灵活性。建立信息之间的关系关系，通常需要开发相应的工具，以实现关联关系的建立、管理和使用，但建立关联关系时，最重要的工作绝不是工具的开发。
3、在完成信息内容的结构化，在各组件管理的信息之间建立了
关联关系后，可以采用
成熟的集成架构。
我们的测试团队对测试架构的理解还在更新中，可以这么认为：当测试的外延扩大的时候，测试架构也会有相应的变化；当测试有新的课题需要客服的时候，测试架构也会有调整的需要。质量相关的改进，通常需要信息整合：效率相关的改进，通常需要工具集成。
10.3价值拓展的辅助工具
10.3.1
用TPI NEXT模型确定需要开展的工作
TPI和TMAP是测试业界认可程度很高的一组模型。TPI用于评估，发现测试活动中需要改进的域和需要开展的工作，这个模型包含了测试业界被广泛认可的最佳实践。TMAP用于指导如何开展具体的工作，包括所需的技术、工具、模板、检查表、指导书等。
10.3.2
用商业模式画布进行项目策划
测试工程师需要像思考一项事业那样，从人、财、物等角度去
谋划。
在项目策划阶段，需要解决画布上的这些问题。
1、
客户细分。
2、
价值主张。
3、
渠道通路。
4、
客户关系。
5、
核心资源。包括技术能力、项目和设备、兴趣、素质、人际关系。
6、
关键业务。
7、
重要伙伴。
10.3.3
设定合理目标，管理预期
做测试技术改进的目标和计划，比做产品测试计划难多了。
测试能力提升、测试价值实现是一个
漫长的实践过程，这中间没有门槛低、实施快、效果佳的捷径可走。测试的价值越大、越明显，实现起来必然也越复杂，所需的资源、时间、技术很可能远比最初预计的多得多。
作为测试主管，需要通过各种渠道，让测试内部和研发团队对测试团队的技术能力提升有
合理的预期。为了避免测试团队被产品测试和技术提升这两座大山压垮，管理预期是测试主管必须亲自负责的核心工作之一。