2.7 价值验证和确认

在敏捷中，价值验证与确认需要频繁进行，我们常说“小洞不补，大洞吃苦”，就是希望通过各种手段及早发现问题，解决问题，防微杜渐。

在不同的敏捷实践中，都强调了及早进行价值验证与确认，如在XP（极限编程）中，从各维度提供了不同级别的反馈循环，如图2-20所示。

接下来，介绍几种不同的手段。

1.V模型

在传统的开发模型中，如瀑布模型，通常把软件测试作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时软件测试工作会占整个项目周期一半的时间，但是软件测试仍然被认为只是一个收尾工作，而不是主要的阶段。由于规定了它们自上而下、相互衔接的固定次序，早期的错误可能要等到测试阶段才能发现，所以会带来严重的后果。

V 模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开发过程（从分析、设计到测试）的关系，如图2-21所示。其中的一个关键点是并行，并行是V模型的核心。

其中，单元测试检测代码的开发是否符合详细设计的要求；集成测试检测此前测试过的各组成部分是否能完好地结合到一起；系统测试检测已集成在一起的产品是否符合系统规格说明书的要求；验收测试检测产品是否符合最终用户的需求。

V 模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，问题一直到后期的验收测试才被发现。因此，在敏捷模式下，通过迭代递增式交付将V模型落实到单个需求的交付上，尽量并行，从而实现对价值的快速测试与验证。

验证（Verification）与确认（Validation）是两个完全不一样的动作，二者的区别如表2-3所示。

2.验收标准

验收标准（Acceptance Criteria，AC）强调的是从用户的视角来看，有哪些场景、路径是需要测试覆盖的要点，经过这些“总结”性的要点，开发人员和测试人员就可以更好地理解这个需求，同时在写代码的时候可以有针对性地去写“if…else…”，这样也有利于对价值的验证与确认。

验收标准是站在用户的角度，对产品功能验收的要求描述。验收标准应该包含如下要素：

（1）端到端的用户正向场景。

（2）功能的逆向场景。

（3）用户故事对其他功能的影响。

（4）用户体验方面的要求。

（5）功能性和非功能性的测试要点。

（6）性能要求和指导方针。

（7）端到端的用户流。

（8）业务规则和约束。

3.就绪的定义与完成的定义

无论是迭代计划还是发布计划，敏捷团队需要明确迭代开始前的“就绪的定义”（Definition of Ready，DoR）及迭代结束时“完成的定义”（Definition of Done，DoD），如图2-22所示。

DoR 指的是在敏捷团队进行迭代开发之前，需要准备好的定义，以便迭代一开始团队就可以在没有依赖和障碍的前提下全力冲刺，高效交付高价值的潜在可发布的产品增量。

DoD 指的是在迭代结束的时候，团队已经完成的产品增量或者用户故事的含义。每个团队成员必须对完成工作意味着什么有相同的理解，以便确保透明化，同时这影响了工作的深入程度及工作量，适用于产品需求列表中的所有用户故事。

下面介绍针对未来1～2个迭代用户故事DoR的例子。

1）需求

（1）产品需求列表已经排序。

（2）用户故事按三段式描述。

（3）验收标准按场景、业务规则、成功路径或失败路径等测试要点编写。

2）交互

（1）业务流程图已完成。

（2）低保真线框图已完成。

（3）场景、业务流程逻辑清晰。

（4）视觉设计和切图已完成。

3）架构

（1）相关的架构已经确定。

（2）所需技术调研、研究、概念验证等已完成。

（3）相关业务用户故事所需的架构或框架的代码已完成。

4）外部依赖

相关的外部依赖已经跟依赖方达成一致。

下面介绍一个迭代结束时DoD的例子。

1）设计

设计评审完成。

2）代码

（1）每天下班前必须签入（Check In）当天编写的代码。

（2）当天的代码必须在当天或者第二天邀请同伴进行代码评审。

（3）代码重构完成。

（4）代码符合编码规范。

（5）代码已合并团队最新完成的代码并提交主干。

（6）静态代码扫描出的错误已经修复，新增代码扫描出的警告已经修复。

3）文档

（1）最终用户文档已更新。

（2）最新接口文档已经自动更新到Wiki中。

4）测试

（1）完成单元测试。

（2）单元测试自动化脚本已经接入持续集成服务器，并且每天至少执行2次。

（3）完成集成测试。

（4）无论是前后端的接口，还是与其他系统集成的接口，集成测试自动化脚本已经接入持续集成服务器，并且每天至少执行1次。

（5）完成回归测试。

（6）完成平台测试。

（7）完成安全测试。

（8）完成性能测试。

（9）完成压力测试。

（10）完成用户验收测试。

5）缺陷

（1）已知缺陷为零。

（2）线上P0级缺陷（最高级别缺陷）为零。

6）验收

（1）产品负责人已经验收每一个完成的用户故事。

（2）产品负责人按照用户旅程验收用户体验。

4.评审

评审是指“向项目人员、管理人员、用户、客户或其他相关方介绍工作产品或一组工作产品以征求意见或批准的过程或会议”。评审可以作为软件开发、维护和获取活动的一部分进行。

V＆V（验证和确认）评审的主要目的是在软件生命周期的早期识别并消除软件工作产品的缺陷。

V＆V 评审的另一个目的是为工作产品满足需求和干系人的需要提供信心。评审可以用来验证需求列表是否恰当地抓住了干系人的需求。评审也可以用来验证所有的功能需求和质量属性已经在设计、代码和其他软件产品中充分实现，并被测试有效评估。

V＆V 评审也被用来检查工作产品是否符合标准。例如，可以对设计进行同行评审，以验证它是否符合建模标准和符号，或者对源代码模块进行评审，以验证它是否符合编码标准和命名规则。

一般来说，V＆V评审包括以下几种：

（1）检视。

（2）同行评审。

（3）团队评审。

（4）走读。

（5）结对编程。

（6）同行检查。

（7）特别检查。

5.原型走查

对于某些产品，在真正开始开发前，通常需要进行原型设计。为了保证原型设计本身是正确的，后续人员对于原型的理解是一致的，同时及早获取干系人的反馈，需要对原型进行走查，这里不再赘述。

6.测试驱动开发

测试驱动开发（Test-Driven Development，TDD）也称为测试先行编程（Test-First Programming），在改变任何产品代码之前先编写一个自动化单元测试代码，由于它要测试的产品功能代码还不存在，所以，会运行失败（红灯），然后编写产品功能代码使测试通过（绿灯），在单测保护下，再对代码进行重构，如图2-23所示。

7.验收测试驱动开发

ATDD（Acceptance Test-Driven Development，验收测试驱动开发）通过名字看，就知道和TDD有着某种神秘的联系。ATDD是TDD的延伸。

在传统做法中，要给系统添加新的特性，开发人员会按照文档开发、测试，最后交给测试人员测试和客户验收。ATDD 则有些不同：在编码前先明确新特性的验收标准（AC），在开发人员编写代码的同时，测试人员将验收标准转换成测试用例（最佳实践是自动化脚本），开发人员提测时，会自动运行自动化测试用例，当所有的验收条件都满足时（验收测试用例通过），即验证功能得到完整实现。

8.持续集成

持续集成这个词最早出现在20世纪90年代由Grady Booch编写的《关于面向对象程序分析与设计》一书中。持续集成真正作为一个实践开始被应用在软件开发过程中，是从Kent Beck提出极限编程（Extreme Programming，XP）方法开始的，Kent Beck在自己的书中描述了这个实践。关于持续集成这个方法论的相对完整的定义和描述，是从Martin Fowler在2000年左右写的一篇文章开始的，2006年，他又对持续集成做了进一步的阐述：

“持续集成是一种软件开发实践，团队成员频繁将他们的工作成果集成在一起，通常每人每天至少提交一次代码，这样每天就会有多次集成；每次提交后，自动触发运行一次包含自动化用例集合的构建任务，以便能尽早发现集成问题。”

——Martin Fowler，2006

为什么做持续集成呢？“集成”是一个动作，我们关注的是验证。可以通过机器完成（最佳实践），也可以通过人工完成。持续集成就是持续地验证正在开发过程中的软件系统是否能够正常工作、是否符合代码规范、是否满足客户需求，等等。通过持续验证和实时反馈，能够不断增强团队的信心，并且能够将信心传递给业务方或者客户。

9.探索性测试

探索性测试（Exploratory Testing）是由Cem Caner 首次提出的。2010年，James Whittaker的《探索性测试》一书在业内引起了广泛关注，这种测试方法将戴明博士提出的规划—执行—检查—行动发挥到极致。

“一种强调个人自由与责任的测试方法，让独立的测试者可以借由不断地学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善项目达到相辅相成的效果。”

——James Whittaker，2010

探索性测试强调测试设计和测试执行的同时性，这一点与传统的软件测试过程的“先计划，再分析，后设计，最后执行”是有一定的区别的。它的本质是测试策略，边学习、边设计、边测试、边思考。换句话说，探索性测试是测试人员自发进行的测试工作，在执行测试的同时根据所获得的信息来设计测试策略的方法。探索性测试强调要根据当前的实际情况来选择最合适的测试技术进行测试。测试人员使用探索性测试从客户的角度评估软件的实际工作方式。探索性测试更注重的是“思考”和“学习”，不断发现新的问题。一般来说，在时间相对较紧张且测试对象说明不完善（我们常说的敏捷开发模式）的情况下，探索性测试可以起到突出的作用。

10.可用性测试

1984年，美国财务软件公司Intuit Inc.在其个人财务管理软件Quicken的开发过程中引入了可用性测试的环节。Suzanne E.Taylor在其2003年的业界畅销书 Inside Intuit 中提到：

“在第一次进行可用性测试后，该做法成为行业惯例，LeFevre 从街上召集了一些人来同时试用 Quicken 进行测试，每次测试之后程序设计师都能够对软件加以改进。”

——Suzanne E.Taylor，2003

Intuit Inc.的创立者之一也曾经表示：

“我们在1984年做了可用性测试，比其他人早了5年的时间。进行可用性测试和在已售人群中进行可用性测试是不大一样的，而且例行公事地去进行和把它作为核心设计流程中的一环也是很不一样的。”

——Scott Cook

经过20多年的发展和应用，可用性测试已经成为产品（服务）设计开发和改进维护各阶段必不可少的重要环节。可用性测试的价值在于初期及早地发现产品（服务）中可能会存在的问题，在开发或投产之前提供改进方案，从而节约设计开发成本。当产品（服务）的销售疲软或使用过程中出现问题却无法及时精确地找到问题关键时，可用性测试可以在很大程度上提高解决问题的效率。通过可用性测试不但可以获知用户对产品（服务）的认可程度，还可以获知一些隐含的用户行为规律。

可用性测试通常让用户真正地使用软件系统，由测试人员对测试过程进行观察、记录和测量。这种方法可以准确地记录用户的使用表现，反映用户的需求。用户测试可分为实验室测试和现场测试。实验室测试是在可用性测试实验室中进行的，而现场测试是由可用性测试人员到用户的实际使用现场进行观察和测试。

11.演示与验收

在每个迭代结束前，除了团队全员，还可以邀请所有的干系人，针对刚刚完成的需求进行一次现场演示，听取反馈与修正意见，同时由产品负责人进行验收。

在迭代执行过程中，有时为了缩短验证反馈时间，开发人员可以在任何时间向产品负责人发起一次演示（有团队也称其为Show Case），让产品负责人进行验收；如果发现有问题，则可以及时修正，不用等到最后的迭代演示。

12.用户验收测试

用户验收测试（User Acceptance Test，UAT）也称为用户可接受测试，是系统开发生命周期方法论的一个阶段，这时相关的用户根据测试计划和结果对系统进行测试和接收。用户验收测试让系统用户决定是否接收系统，是一项确定产品是否能够满足契约或用户所规定需求的测试。

13.灰度发布

灰度发布（又名金丝雀发布）是指在一种产品正式发布之前，让一小部分人开始用新版本，另一部分人继续使用旧版本，因为样本可控，所以在发生问题时，影响范围小，这样就可以有针对性地发现问题、解决问题（这也是灰度发布最主要的作用所在）。如果新版本没有什么问题，就可以把所有用户转移到新版本上来。这是测试右移的一种理念，利用真实用户辅助验证功能，在互联网公司中应用广泛。

14.A/B测试

A/B 测试是一种比较单一变量的两个版本的方法，通常通过测试受试者对版本A和版本B的反应，确定其中哪个版本更有效。

A/B 测试的核心在于“对比验证，择优使用”。例如，在网页设计中，通常有两个版本 A和B，A是现有设计（称为控制组），B是一个新的设计。让访问者随机访问不同的版本，看看这两个版本在你感兴趣的指标上的表现情况（这些指标一般有转换率、销售额、跳出率等）。最后，根据这些指标选出那个表现比较好的版本。

A/B测试也是互联网公司常用的一种价值验证方法。 mXGMqSPmswvXGs0rDO/NfvPuZIr63Fmpupy4ndNg/RQ54Ms0wZo0eI4g7BzsODhH