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

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

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

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

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

3.1 稳定性保障&大促保障

• 保障设计的三位一体

水平：通用平台的测试方案，例如交易中台、搜索中台等行业：具有特定业务形态的业务测试方案，重点保障的测试方案，例如资损、预案、强弱依赖、全链路压测等

• 测试技术的推陈出新

我们容忍部分重叠，但是如果有公共可以技术化的东西还是希望通过效率和技术传承去避免人肉的失误，在集团多年的测试技术发展下，大促质量保障沉淀非常丰富。

3.1.1 全链路压测

全链路压测诞生至今，一直稳居大促质量保障核武器地位。多年以来，随着大促业务发展和技术升级不断的持续迭代，打造了一套常态化、国际化、服务化为目标的全链路压测体系。

3.1.1.1 全链路压测简介

全链路压测是以全链路业务模型为基础，将前端系统、后端应用、中间适配层、DB等整个系统环境，完整得纳入到压测范围中，以http请求为载体，模拟真实的用户行为，在线上构造出真实的超大规模的访问流量，以全链路压测模型施压，直至达到目标峰值，在压测过程中发现系统瓶颈和验证系统能力。

• 业务架构
• 基本原理

入口：前端http请求，如detail页面、确认订单页面、提交订单等媒介：eagleeye为主线，将全链路压测标识（见名词解释），通过HSF、tddl、notify等，进行传递终点：影子表，当流量执行到存储层时，tddl会进行判断，带全链路压测标记的数据流量走影子表，影子表为正式表前加“__test_”，即__test_表名

• 压测标传递原理

http请求中加上eagleeye标记（tb_eagleeyex_t=1）;tbsession中的埋点将该标记映射到eagleeye中（t=1）;而后随系统调用，通过上下文和各个中间件将t=1标记一直传递下去，业务逻辑根据此标识判断是否走全链路逻辑，最终直到各个系统依赖的DB层，通过tddl判断eagleeye中全链路标识，若带有t=1，则走影子表，若t=null，则走正式表。登录和非登录会做业务支持上的区分，登录用户会通过login集体登录预热，携带打标cookie。

3.1.1.2 全链路名词解释

3.1.2 功能预演

每年全民预演都是最耗人力的一项测试任务，需要各种行业的PD运营跟测试一起参加。所以提高全民预演的有效性发现更多有效bug，提高组织效率非常重要。

• 每年大促，在所有业务需求整体发布之后，会邀请产品、运营、开发、测试、CCO等多种角色集合到一起，对整个大促期间核心玩法进行全民的测试和验收。
• 预演平台针对全民预演做深度定制，帮助全民预演效率提升、体验提升。

3.1.3.1 模块架构&平台介绍

• 预演组织管理

• 用例录入、任务分配。
• 数据构造。
• 账号分配。
• 业务设置。
• 进度大盘

• 预演执行引导

• 预演任务、执行账号自动领取
• 业务执行。
• 问题跟踪

• 预演问题排查

• 问题复现&排查。自动填充更多bug信息。

3.1.3 预案专项

预案每个BU都有，预案是最保命的，但是有时候预案也是最致命的，集团有各种灰度方案，发布过程中有各种灰度的策略，现在能够引起故障，除了系统问题还有一个最高风险就是错误的预案被推送。所以预案是我们风险非常高的东西，大促各个BU在协同的时候，一个预案可能影响到很多上下游系统。所以是绝对不允许说有一个人没有作战规律去执行的。但是我们强调了很多次作战纪律，仍然因为人的因素或者是新老团队交接而犯错。所以一个安全的预案平台是至关重要的。在预案执行时对权限和AB角的流程机制也是非常重要的。

3.1.4 资损防控

3.1.4.1 大促资损防控怎么做？

• 了解大促需求和目标，制定资损专项目标，跟各业务域接口人KO，KO内容包括时间计划，资损目标，纪律；
• 梳理各域历史遗留资损问题，跟进修复进度；
• 制定资损点梳理模板，跟集团资损专项总负责人review，给各业务域接口人进行梳理；
• 资损梳理模板review，资损点测试，监控项补全，资损用例可沉淀到天启资损专项用例组；
• 核心项目资损链路梳理及review，预演资损问题跟进，进行记录及风险评估，同步大促项目组；
• 大促值班计划，资损监控问题（如bcp）反馈群，跟进goc反馈问题，进行记录及风险评估；
• 大促复盘，当天问题分析，后续改进建议。

3.1.5 故障演练

为了提高系统,流程,人员在面对突发状况的应对能力，真正实现故障快速发现，快速止损，快速恢复，提升系统的整体的健壮性。

3.1.5.2 演练流程规范

3.1.5.3 攻防演练接入案例

• 准备方法

1.分析链路和监控报警关系，设计演练场景

2.在预发环境模拟注入验证，关注点 故障可以生效

3.在安全生产环境注入验证，关注点 故障点可以触发监控报警

4.将演练场景在mk平台归档到演练空间

• 流量模拟

演练需要在安全生产环境通过压测流量模拟出故障，需配置故障注入流量的策略配置。

• 监控报警

业务域同学要判断出服务会导致的故障监控报警，新版应急场景。

• 故障模拟

1.首先在预发环境验证故障和预案，确认故障注入能生效

2.在安全生产环境验证演练方案是否能触发监控报警

3.1.5.5 预期恢复动作

预期恢复动作会考核开发的处理，蓝军提供的方案需要准确。

3.2 如何从0-1实现自己的效能创新，思路和解法。

效能不是从天而降，一定是服务于业务，基于业务测试痛点的。接下来会从以一款接口自动化效能产品的前世今生为过程，剖析如何从业务中的问题抽象出解决方案，0-1通过技术创新实现平台化效能产品，以及在不断的业务实践中优化产品做深入的过程。

第一步：起源

关键字：前瞻性的力量、逼上梁山的YY、有梦才有远方、骨感的现实

了解技术的前世今生，发展历程，脑暴效能突破的方向和目标。

接口测试1.0：使用框架进行接口测试，如junit，itest等，门槛高，维护成本高，环境稳定性依赖高。

接口测试2.0：提供可视化界面降低门槛，但是缺乏灵活性，环境稳定性依赖高。

接口测试3.0：利用大数据技术的智能接口测试。

第二步：转变

关键字：效能目标设定、智能化初探、能力综合体将技术创新形成产品化能力：同位同理的用户心、视觉交互的体验把关、关注竞品的发展动向，优化现有解决方案

。初期的效能产品局限会在更倾向于工具化层面的思考，只聚焦于解决点状问题。

第三步：破局

遇到困境时，思考质量产品的本质，从价值出发。

• 思考：

• 用户市场很广，当前产品有差异化，服务好非TMF，价值空间依旧在。
• 用户痛点还很多，应该共建互通，攻坚技术难题，聚焦用户价值。
• 智能化探索之路还很远，创新力才是竞争力，不一定拘泥于当下几个点。

• 结论：

• 核心价值：广大非TMF应用的技术同学的测试赋能，解决质量和效率问题。
• 竞争力：不断得用创新探索智能化测试
• 方向决策：进一步开放共赢

第四步：深耕、智能、开放

3.3 如何体系化思考质量保障

质量保障是一门精细的学科，有独立的知识体系，我们在思考质量策略时可能经常听到这个词：体系化。其实每个人的思考过程都是体系化的，差别在于如何更好组织思路让认知形成闭环以及扩大这个环。在质量保障的角度体系化思考就是尽可能的扩展和质量相关的所有因素，组织起来，让这个组织的过程和结果没有盲点、矛盾点。

第一步：梳理你的所有输入 – 一切质量相关的事都要管

• 业务背景和现状是什么
• 业务复杂性有哪些
• 技术复杂性和成熟度如何
• 团队成熟度和协作成熟度如何
• 质量现状如何

第二步：整合输入，思考如何解决，如何闭环

第三步：排兵布阵，落地节奏

第四步：沉淀&反思&优化