软件测试价值提升之路--第3部分“展露锋芒”-第7章“产品质量屏障”-读书笔记

传统的测试价值依然存在，这些价值已经被认为是测试 该做到的。这里讨论的价值点，有些是研发团队对测试的 期望，比如保障质量；有些在研发团队并没有固定的角色，但测试 有条件做好，比如产品交付。想要实现这些价值，测试不仅要做好自己的 本职，还需要把影响力 扩展到测试团队和测试活动以外，实现 额外的团队价值，就像袋中之麦 展露锋芒于外。

测试的额外价值在我们的产品团队中虽然有一些实践，但也并不十分成熟。这里写出来主要是帮助测试人确信：以 既有的能力和知识为基础，测试还可以在产品和服务中发挥 更多的价值。

这部分讨论的价值主要是两个方向：一个是 产品质量，另一个是 交付效率。这两个方向的价值实践在我们的产品中也相对比较成熟。

第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 测试充分快速地提升：新代码快速、充分验证</