写在前面

在准备测试开发新人手册之前，采访了一些刚入职的小伙伴：你入职后最大的困惑是什么，想看到什么样的新人手册？有位同学的回答很能体现大家的心路历程，入职后每天都给自己灵魂三问：我是谁？（我的工作角色是做什么的），我在哪儿？（测试开发在大团队中的位置），我该做什么？（如何开展工作）。这版新人手册希望能回答到这些问题，让新人同学能寻找到答案，快速融入。

测试开发新人手册分为3部分。

1、基础篇 – 如何开始你的第一个测试项目

2、进阶篇 – 做专业的测试

3、思考篇 – 稳定性保障&测试技术创新

1. 基础篇 – 如何开始你的第一个测试项目

1.1 我是谁？- 认识你的角色

测试开发工程师，可以从两方面理解：思想和方法。测试最重要的是思想，技术是实现方法。作为测试开发工程师则需要具备测试的思想善用技术手段完成质量保障工作。我们可以通过接下来的介绍帮助大家再深入理解什么是质量，什么是测试？如何用技术手段实现测试？

1.1.1什么是质量？

质量的定义因领域不同定义有很多说法，软件领域的质量是指在特定的使用条件下产品满足明示的和隐含的需求所明确具备能力的全部固有特性（内在特性），体现了产品满足产品要求的程度（外部表现），是产品的质量属性。

从概念分析对应到我们实际的测试工作，包括的三个要素：产品（我们的被测对象）、特性集合（需要采用哪些测试类型）、需求（覆盖的测试场景）。

1.1.2 什么是测试？

一个经典的问题：做测试的目的是什么？为了发现问题？为了质量？还是为了业务价值保障？这是个大家需要经常问自己的问题，我们技术质量做的一切活动目的，一定是为了保障业务交付。测试要打造发现问题的能力，同样也需要有打造高稳定性的能力。需要对每次发现的问题都剖析如何能避免问题再次发生或更早阶段识别，同时对遗漏的问题都深入思考剖析为什么没能提前发现。围绕这样的目的作为我们工作的方向。

1.1.3 准备工作环境 – 工欲善其事，必先利其器

1.1.3.1 不同工作环境介绍

环境是测试工作中非常消耗时间且难以管理的部分，环境区分的目的和方式，一定程度也体现了大家目前的测试流程和规范，接下来我们会介绍环境是如何分层，如何管理，如何准入准出。

【第一步：理解环境】

实际上，环境的名称只是一种形式，关键在于不同的环境之间存在一些代码、数据、服务之间的差异。以接入的数据源来说，项目/日常环境的数据库与预发/生产环境的数据库肯定不一样，这样测试使用的数据就不会污染线上数据；预发环境/灰度环境会与生产环境共用一套数据库，以便在预发环境下测试新的功能也能较真实地反映线上的情况。还有一些差异在于使用者的不同，比如预发和灰度环境都使用的是生产环境的一套数据库，但灰度环境的使用者是一小部分的外部用户（客户），而预发环境的使用者一般都是内部人员（开发/测试）。

【养成测试发布好习惯】

优秀的我有着

优秀的习惯

未经过项目环境测试的变更我绝不直接部署日常

未经过日常测试通过的变更我绝不直接上预发

未经过本地/项目环境编译启动成功的变更我绝不直接部署日常和预发

【第二步，各个环境区分】

• 项目环境

项目环境也可理解为开发环境和联调环境，顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上编码，和其他代码是完全分离的。多项目环境可以关联在一起形成项目制的开发和资源联调。项目环境数据库和日常环境是一套。

• 日常环境

日常环境是主要测试环境，开发完成自测通过后提交代码，日常环境会（merge）所有提交到日常的分支，融合的时候可能会存在冲突，有冲突就需要排除冲突。测试同学主要的工作环境为日常环境。

• 预发环境

预发环境和日常环境一样是把其他开发同学部署到日常机器上的代码和你要发布到日常的代码融合起来（merge）一起测试。但预发环境区别于日常环境最大的点是，预发环境和生产环境是同一套数据库。而且相对日常，预发的数据更加接近真实的线上数据。预发环境和生产环境的访问域不同。所以预发环境更多使用在验收测试和最后发布前的checklist观察，不作为测试的主要环境。

• 灰度环境

灰度环境其实就是小范围的生产环境，是一套有隔离策略的生产环境分组。是通过真实流量结合环境策略能够在全量发布前再进行一轮验证，因为都是真实流量，灰度如果出现问题，影响的已经是真实用户，但因流量带来的损失可控。（爱玩游戏的同学可以把它理解为游戏内侧、体验服等）

• 生产环境

即线上环境，在权限和发布管理上非常严格。包括DB的写操作都需要多级审批流，发布变更也有严格的窗口管控，在流程上也要求了变更必须经过日常 – 预发 – 灰度之后才允许合并到线上。

• 自定义环境

1.2 我在哪儿？- 修炼测试基本功

熟悉了环境，做好了工作准备，可以开始第一个项目了吗？如果你已经了解软件质量属性，也掌握了常用的测试方法，熟悉测试流程，那么恭喜你，可以开始你的测试工作了，如果还没有，下面的章节可以找到答案。

1.2.1 认识软件质量

1.2.1.1 软件产品质量属性

这一章会从软件质量的基本概念出发，以标准化（ISO/IEC25010）的软件定义，介绍软件产品质量模型和使用质量模型。里面的内容都可以在《GBT25000.10-2016系统与软件工程系统与软件质量要求和评价(SQuaRE)第10部分系统与软件质量模型》中找到详细解释，这里主要列出我们测试工作中常用且必须关注的质量特性以及实际场景中如何运用。

系统/软件产品质量属性有8个特性:功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性。其中功能性，性能效率，可靠性、易用性（人工差错防御）是我们着重需要关注的质量特性，也是导致线上90%故障的主要因素。

产品质量特性说明和理解：

• 功能性 – 在指定条件下使用时,产品或系统提供满足明确和隐含要求的功能的程度。包括功能完备性、功能正确性、功能适合性、功能性的依从性。

从定义上来理解，功能性并不止满足“明确”的要求，还有很多“隐含”的质量特性。我们在做功能测试的时候，“明确” “隐含”需求一起覆盖才是完整的测试场景。我们在工作中如何能前置让隐含的需求明确，是质量同学的一项重要能力，这个过程包括在需求前期跟PD的明确，比如需求文档里描述了想要实现的功能，但没有写明对性能和用户体验的要求，测试同学就是需要在评审阶段就对焦明确，这样在TC设计，测试策略以及后面业务方验收测试中才能充分被覆盖到。还是一个基本原则，问题越前置被识别并解决，是成本最低的做法。

• 性能效率 – 性能效率的评估与在指定条件下所使用的资源量有关。包括时间特性、资源利用率、容量、性能效率的依从性。

实际工作中，我们基础架构的弹性能力，常态化压测能力、大促的全链路压测等都是这一质量属性的测试体现。后面在测试进阶能力中，会有专门篇幅介绍性能测试和全链路压测的内容。

• 可靠性 – 系统、产品或组件在指定条件下、指定时间内执行指定功能的程度。包括成熟性、可用性、容错性、易恢复性、可靠性的依从性。

质量同学在评估方案时经常会出现这样的灵魂拷问：怎样设计测试场景保障线上不出问题、如何设计架构让主流程不受阻塞、强弱依赖如何解耦、准备怎样的预案让问题发生时也能快速恢复等，都是对可靠性质量属性的测试实践，可靠性也是我们在设计评审中需要着重关注的特性。

• 易用性 – 在指定的使用周境中,产品或系统在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度。包括可辨识性、易学性、易操作性、人工差错防御性、易访问性、易用性的依从性。

易用性的另一个描述就是功能级别的用户体验（下一章会介绍使用级别的用户体验），我们新零售技术质量的愿景就是“做用户体验的捍卫者”，因此易用性是测试过程中很重要的一个覆盖范围。易用性里核心需关注的是人工差错防御，我们有很多故障或线上问题都来自于人工操作或配置类错误，这都是人工差错防御范围。

• 兼容性 – 在共享相同的硬件或软件环境的条件下,产品、系统或组件能够与其他产品、系统或组件交换信息,和/或执行其所需的功能的程度。

包括共存性、互操作性、兼容性的依从性。兼容性测试在移动应用测试和跨平台组件应用上需着重评估。

• 信息安全性 – 产品或系统保护信息和数据的程度,以使用户、其他产品或系统具有与其授权类型和授权级别一致的数据访问度。包括保密性、完整性、抗抵赖性、可核查性、真实性、信息安全的依从性。

这部分质量属性直接对应安全性测试，已经是测试领域里独立的一个重要方向。后面的进阶篇会有详细介绍。

• 可维护性 – 产品或系统能够被预期的维护人员修改的有效性和效率的程度。包括模块化、可重用性、易分析性、易修改性、易测试性、维护性依从性。可维护性更多体现在对设计方案的评估过程中。
• 可移植性 – 系统、产品或组件能够从一种硬件、软件、或者其他运行(或使用)环境迁移到另一种环境的有效性和效率的程度。包括适应性、易安装性、易替换性、可移植性的依从性。迁移类项目和版本升级类变更需评估。

1.2.1.2 产品使用质量属性

使用质量属性是从用户使用体验的角度进行定义，质量同学作为用户体验的捍卫者，除了产品质量，使用质量也需要关注。它描述了产品(系统或软件产品)对利益相关方造成的影响。它是由软件、硬件和运行环境的质量,以及用户、任务和社会环境的特性所决定的。所有这些因素均有利于系统的使用质量。

产品使用质量属性说明：

• 有效性：用户实现指定目标的准确性和完备性。
• 效率：与用户实现目标的准确性和完备性相关的资源消耗。
• 满意度：产品或系统在指定的使用周境中使用时,用户的要求被满足的程度。包括有用性：用户对实用目标的实现感到满意的程度,包括使用的结果和使用后产生的后果；可信性：用户或者其他利益相关方对产品或系统将如预期地运行有信心的程度；愉悦性：用户因个人要求被满足而获得愉悦感的程度；舒适性：用户生理上感到舒适的程度。
• 抗风险：包括经济风险缓解性：在预期的使用周境中,产品或系统在经济现状、高效运行、商业财产、信誉或其他资源方面缓解潜在风险的程度；健康和安全风险缓解性：在预期的使用周境中,产品或系统缓解人员潜在风险的程度；环境风险缓解性：在预期的使用周境中,产品或系统在财产或环境方面缓解潜在风险程度。
• 周境覆盖：在指定的使用周境和超出最初设定需求的周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。包括周境完备性：在所有指定的使用周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度；灵活性：在超出最初设定需求的周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。

1.2.2 认识软件测试

对软件质量思考的不同角度，形成了不同的测试类型，不同类型对应不同的测试方法，而不同的测试方法针对不同的质量特性。要修炼更深更广的测试覆盖度，需要了解更多的测试方法用于设计测试用例。这类方法的介绍书籍非常多，下图是一个质量特性对应测试方法的展示。实际项目中测试时间和资源往往有限，测试工程师就需要不断的思高效的质量保障手段。下图很多方法都已能通过工具或技术手段来完成，比如异常测试，故障输入，幂等，灰度验证等等。因此质量特性对应的方法更多只是一个范围的参考，给测试同学一个基本原则，如何保障好这个特性，需要我们不断的思考测试技术的突破来实现。

1.2.2.1 测试类型

根据测试方法不同的类型

• 黑盒测试 – 也称功能测试或基于需求的测试，测试设计时把被测对象当成一个黑盒子，不关心盒子的内部结构，主要通过输入/输出数据驱动功能用例。这类测试中理论上的充分测试标准就是“穷举输入”，而穷举肯定是不可能的，因此我们还需要其他的测试类型进行补充。
• 白盒测试 – 也称为逻辑驱动测试，针对性较强，需要对代码逻辑有了解。理论上的充分测试是所有的条件、语句、路径组合都被覆盖，对技术和成本都有一定要求。
• 灰盒测试 – 介于白盒与黑盒之间的测试方式，根据实际测试场景、资源、复杂度等情况进行结合，也是目前我们使用最多的测试类型。

每种测试类型都对应很多测试分析方法，后面进阶篇也会针对各种测试方向进行深入介绍，这里不对基本概念和原理多做赘述。

1.2.2.2 软件测试的基本原则

基本功修炼的最后，我们可以归纳出一系列重要的测试指导原则，可作为我们日常工作的提醒。原则大部分看上去显而易见，浅显易懂。但往往故障都发生在这些常见的场景中，用一位开发TL在某次故障复盘会上的话，给“修炼测试基本功”这一章做个结束语：故障中的一切问题看似天灾人祸，实则人事不修。

1.3 我该做什么？- 测试工作流

1.3.1 研发过程中的测试工作

研发过程中测试可以做的事情很多，下面流程环节的介绍只列出了最主要的一些测试活动，可以作为一些基本参考，测试怎样能介入的更深入，在团队建立认可和存在感，拿到更好的质量保障结果，是需要在工作中不断的思考实践的，因此这一章虽然是介绍流程，但是实操中不限定角色，不限定阶段，不限定方式，大家结合项目实际的时间资源、人力资源、质量要求做到最佳实践就是可行的工作流。

1.3.1.1 需求设计阶段测试做什么 – 测试计划与需求评估

1.3.1.2 开发设计阶段测试做什么 – 分析与设计

1.3.1.3 测试阶段做什么 – 测试执行与策略实施

1.3.1.4 发布前后

1.3.2 测试工作规范&标准

1.3.2.1 通用版变更红线V2.0

前面介绍环境和权限中提到过，线上变更是风险非常高的操作，90%的故障是变更引起，因此我们在测试过程中往往需要制定详细严格的变更管控，变更风险防控三原则：可灰度，可监控，可回滚。

• 变更红线定义( 示例）：

• 禁止封网期、非变更窗口期进行除紧急变更外的变更。
• 禁止未经测试验证、未经预发、未经灰度的线上变更。
• 禁止一切未通过变更管理平台申请或报备的变更操作，紧急故障处理，可事后补填申请。
• 禁止无影响面说明、操作步骤、验证方案、应急预案的变更。应急预案（如回滚方案）必须具备可操作性。
• 禁止一切与变更方案计划内容、线上问题排查无关的生产环境变更操作。