质量保障体系

说明：没有所谓的最佳实践。

每个团队只要基于自己的业务、团队特点制定出最高效、有质量保障、大家都愿意遵守的方案，就是适合当前团队的规范。规范的核心在于大家达成共识并实际去遵守，目的是保证团队的一致和高效。

CI/CD敏捷开发：

1. 需求迭代：

0. UI设计(最前置依赖)

1. 需求粗评：拉齐需要感知此需求的各方，不讨论细节，只讨论可行性。

        原型图、 PRD文档：（产品经理）

                项目概述(背景、目标、预期)、竞品分析报告 (用于了解产品在行业中的定位)

                用户场景描述

                流程图：核心业务流程，宏观了解业务关键节点

                思维导图：产品的结构布局逻辑，宏观了解产品功能布局

                产品用例图、需求列表（序号、对应原型图、需求名及详情、优先级）

                修改记录                     

需求实际启动：

需求细评：根据UI确定需求细节，确定需求负责人和需求优先级等。

需求变更要及时同步。需求过于复杂要进一步拆分。

各角色排期、风险把控：DDL协调、需求删减协调、人力资源协调。

研发技术设计评审：根据需求做技术调研确立技术实现方案。对于一些技术难度或要求比较高的需求，设计周期可能会比较长。如果某个需求比较复杂，就会拉动技术选型、项目架构设计的会议。(更多地体现在设计难度上或者说技术创新上，有同步团队其他成员的必要)

研发排期：尽可能明确所有影响排期的因素，并有明确结论；

开发影响范围、UI定稿、后端接口设计、QA测试用例设计(开发给到QA改动影响范围和测试时需要关注的回归范围,QA实现用例设计)。多次深入沟通，确保信息一致及结果符合预期。

QA测试用例评审：QA拉动评审(解释测试用例、和大家一起确认范围和风险)

研发自测、联调测试、QA测试。

验收排期：支持用户验收方的验收。

上线及线上验证：线上回滚及紧急修复发版。

        召回手段： （召回、精确、准确： https://zhuanlan.zhihu.com/p/134672268）

                灰度发布、监控、对账、QA线上验证、回滚、应急热修复

                舆情告警： UI自动化、服务端自动化、流量回放

需求效益分析、实验策略推全：即监测需求上线后的表现，确定是保留、继续完善还是下线等等。

需求归档完成。

参考自：https://zhuanlan.zhihu.com/p/681861381

2. 测试环节

前提：预期和实际。

单元测试：对软件单元的测试。

集成测试：对软件单元间交互的测试。

系统测试：对整个软件系统测试，包括所有单元、模块、接口和功能。

性能测试：评估软件系统的性能。高负载、大流量数据或其他压力。

用户接受测试：在用户实际使用环境中测试系统，可能涉及和用户的合作。(测试及使用支持)

参考自：软件测试的5个基本流程

测试准出标准：

        单元自测准出。

        改动项增量测试用例通过；

        自动化回归测试用例通过；

        增量代码测试覆盖率通过；（对白盒测试有要求？不是）

        产品验收通过（线上验证或者用户使用验证)

        流量回放准出。

        一般来说，自动化回归的覆盖的场景都是用户核心使用场景，冒烟测试的时候就会首先覆盖到。如果通过率不到100%，首先需要追踪用例失败原因判断风险，如果用例有问题则优化用例，如果是缺陷，则可修复就直接修复，如果不可修复，评估风险并采取进一步措施。

        卡点说的是100%，这个卡点的作用是确保团队对有风险的情况做到及时发现、认真对待、预先防控。如果不达100%依旧直接通过，则风险会被掩埋掉，会造成隐患。

时效性更高的手段？

        相对于自动化？测试介入需求的时机提前，更早地了解需求、需求细化适应敏捷开发节奏、制定测试方案、梳理测试计划、准备测试用例、数据和环境等。或者优化用例、用例区分优先级、历史用例集维护、增加人力等。扯ai？测试用例打标签、从历史测试用例抽选加入到增量需求的测试计划中。

3. 测试步骤

业务背景、需求分析、测试主流程、测试范围、测试预期、测试方法、测试工具、测试数据、测试用例编写。

4. 测试用例设计

概念：

需要逻辑思维和专业知识。测试用例用于测试被测系统。包括测试环境、操作步骤、测试数据、测试预期等。

指标：

冒烟测试、测试覆盖率、测试冗余、回归测试等。

        冒烟在于快速明确主流程的正常可用；最简流程

        回归测试在于增量测试完成后，保障增量改动没有影响历史功能。

范畴：

测试用例设计万能公式：界面测试+功能测试+性能测试+兼容性测试+易用性测试+安全测试+高可用保障。

        界面测试：软件界面上的展示信息，包括静态展示和动态可操作点的幂等。

        功能测试：验证实现逻辑与用户行为是否一致，基准线：符合用户常识行为，即用户不具备专业的业务背景但有正常人类的思维和行为逻辑。

        性能测试：以用户使用场景和业务背景为前提，确保性能指标符合用户需求。

        兼容性测试：软件所在硬件位置，硬件的规格：包括版本、资源大小、品牌等。

        易用性测试：是否足够简单上手。模拟新用户使用。

        安全测试：比较大的范畴。数据安全、操作安全

        弱网测试：fiddler如何构造弱网条件

        如果为可迁移组件，则需要对生命周期管理做测试。

        高可用保障：分布式、容灾、备份。

设计思维：

常规思维+逆向思维+发散性思维。

        常规思维：该做的是否做到了；

        逆向思维：不该做的是否提醒不允许做；

        发散性思维：该做的也做到了，不该做的也没做，但是顺序不对。

设计框架：

参数：

        展示、参数独立校验、参数组合校验；

操作环节：

        有无的组合校验、顺序校验、次数校验；

操作流：

        操作流的独立、操作环节的组合。

设计方法：(6种)

1. 黑盒测试：

等价类及边界值分析法：自我感觉，多用于单独某个参数的校验

        对输入做等价类划分，取等价类中一个测试用例。

        分为有效等价类和无效等价类。

        缺点：只考虑了输入域的分类，没有考虑输入域的组合。

正交法：多用于输入参数组合的校验

        可以按照正交法取到最优简的测试用例集合。

判定表法：多用于操作环节有无的组合校验

场景法：多用于操作流的环节跳转校验

        业务支持的多个操作流的环节跳转（也即状态转换），包含操作环节次数校验。                

错误猜测法：

        根据历史经验判断容易出现bug的位置并增加测试用例。

参考自：软件测试----用例篇（设计测试用例保姆级教程✅）_原型验证测试用例设计-CSDN博客

2. 白盒测试：

        Java代码测试和代码覆盖率检查，加分项，这玩意儿确实没做过，也不差这一点

语句：（单元内）静

        代码规范(命名、注释)、数据结构完整性。

处理逻辑：（单元内）静动

        语句覆盖(一个判断语句被执行到了但判定的结果有不同)、判定覆盖(一个判定结果被覆盖到了但这个判定结果可能是由多个判定条件组成的)、条件覆盖和路径覆盖(所有可能的逻辑路径)、边界值分析(可以直接处理的特殊边界情况)、等价类划分(优化简化测试用例数量)。

算法：（单元内）静

        效率和性能分析(时间空间复杂度？)

错误发现：（单元内）静动

        死循环、异常和错误处理机制。

资源释放、函数调用关系、识别孤立函数：（单元间）静

参考自：白盒测试的六种方法_千锋教育

        需要具备软件开发与编程、数据库知识、以上测试方法和技巧、自动化测试工具和框架、缺陷管理和跟踪工具、沟通和团队合作能力、分析和解决问题的能力。

补充：

 召回手段： （召回、精确、准确： https://zhuanlan.zhihu.com/p/134672268）

                灰度发布、监控、对账、QA线上验证、回滚、应急热修复

                舆情告警： UI自动化、服务端自动化、流量回放

测试左移：(本质上是借助工具和测试手段更早地发现问题和预防问题)

        参与需求评审，以及对架构和设计模型的测试；

        开发文档评审，以及着重增加对单元、组件和服务层的测试。

测试右移：(版本上线后持续关注线上状态，及时发现问题并跟进解决，将影响范围降到最低)

        灰度发布、线上监控(性能和可用行性)、混沌工程(故障注入、高可用)、用户反馈跟踪。

灰度发布：新版本线上测试；

监控：合理的性能监测、数据监控和预警机制；

用户反馈：线上问题处理、跟踪机制；

持续测试：自动化测试。

质量保障体系：

如何做？需要考虑哪些方面？需要考虑哪些因素？

功能测试：

        测试方法论，参考需求沟通流程；

                界面、易用性

        技能：黑盒、灰盒、白盒等；

兼容性测试：

        测试方法论，参考需求沟通流程；

        根据被测对象部署的位置及部署的方式，有生命周期管理(安装、启动、对外服务、运行时守护、运行时健康检查、卸载、热升级、重启)、部署位置的OS版本、访问方式的不同

性能测试：

        指标：吞吐量、响应时间、并发数、成功率、平均响应大小、服务端资源CPU和内存、硬盘使用。

自动化测试（测试自动化）：

        目的：将大量的、重复的、可机械化的测试case使用脚本实现，然后在需要执行时执行。

        作用：提升效率，使测试过程更为快捷没有延误。并且减少人力输出。

        方式：目前主要包括UI自动化和接口自动化，实现方式包括：编写脚本的方式、录制回放的方式，用平台、不用平台都OK。重点在于选择适合自身组织的方式，以及如何自动化是否真的提升了测试的效率，避免为了自动化而自动化。

        针对对象：测试case们。(不仅是功能、也可以是性能测试脚本等可机械代替人工的角度)

        针对的对象特点：大量(所以耗时长)、重复(所以可分类归拢好管理)、可机械化(能够用脚本实现)、输入输出固定可预判（所以可断言，减少了人工的误差）、频繁(所以耗人力)

        指标：覆盖率、稳定性、执行结果、执行效率、维护成本及输出和收益比（复用性、频繁性支持）、操作复杂性

覆盖率(代码级：语句覆盖、分支覆盖、条件覆盖；功能级：业务场景(数据、操作、操作流等)覆盖、界面测试覆盖)；

稳定性：如果测试case多次异常或失败，那么就需要关注下系统稳定性了。(被测系统稳定性和测试脚本稳定性都需要考虑)

执行结果：通过率，和稳定性可以统一考量。

执行效率(单个测试用例执行时间、测试套件执行时间、整个自动化测试的执行时间)。所以测试脚本的优化可能在于执行时间的优化、测试case执行优先级或者同步异步的优化？(数据库审计POC样板间一键部署脚本的调优，涉及脚本执行稳定性(异常场景处理)、执行时间压缩)

参考自：什么是自动化测试以及其优缺点、自动化测试指标

CI/CD流程、pipeline流水线

稳定性测试：

背景：风险和挑战：

        资源和网络层：服务器宕机、断电、断网、混部、磁盘满、慢、坏、不可写、不可读、网卡满、网络抖动、丢包、超时、重传严重、DNS故障。       

        应用层：系统单点、依赖异常、依赖超时、同步阻塞、OOM、配置错误、误删、环境错误、业务线程池满、分布式锁超时、包错误、幂等失败、监控错误；

        中间层：缓存热点、缓存击穿、数据库宕机、数据库连接池满、CPU抢占、内存抢占、数据库主从延迟、数据库热点、负载均衡失效、缓存集群主从同步延迟；

        导致故障的原因有：告警配置有问题、超时重试问题、下游依赖降级措施、监控埋点缺少、日志清理问题、容器规格小、缓存机制问题、强弱依赖、架构设计问题、限流设置问题

爆炸半径咋理解？分为两种：1.实际操作的故障注入范围；2. 由于故障注入影响到的故障范围。

稳定性目标或者说稳定性能力：

平时监控正常、故障前主动发现、故障中高可用和故障隔离、故障后可自愈。预案有效、应急熟练。(环境隔离、环境构造、环境恢复和清理)

服务高可用、数据防丢，数据一致性保护方面：提高缓存加载频率或者定时强制更新(用于长时间不过期的缓存数据即热点数据)

什么样的数据适合放入缓存中：

1. 查询频率高且修改频率低的
2. 数据安全性低的

稳定性实施流程：

        演练方案、环境治理、场景梳理、场景编排、场景执行、结果分析、演练复盘。

演练方案：

(对演练目标业务进行分层盘点、补齐监控盲点)  

统一规划稳定性指标，包含：每个业务的半年故障数、监控主动发现率、故障恢复时

长、高可用策略等的明确要求。

‌‌MTBF（Mean Time Between Failures，平均故障间隔时间）等于‌MTTF（Mean Time To Failure，平均失效前时间）加上‌MTTR（Mean Time To Repair，平均故障修复时间）。‌‌

演练计划：

混沌工程五维故障分析法：关于高可用保障设计

        （自定义补充的内容：架构拆分、解耦）

历史故障、架构梳理、典型故障、限流降级。具体为：

        L1:系统及以下硬件故障发生：如网络中断、系统资源打满等(通用业务)

        L2:重点应用的进程级异常：包括JVM内线程异常、进程内方法异常；

        L3:中间件交互：消息队列类异常、存储类异常、流式计算类异常；

        L4:大剧本业务应急：包括业务间上下游调用异常以及业务内突发异常的降级处置；(链路)

        L5:重大故障场景：机房断网、大量分组异常不可用、某层整体不可用

  以上，架构范围由小及大，由低到高。

实际case：

以下故障对整个应用集群高可用的影响。所有应用集群，逐一验证

        1. 冗余部署(应用和组件逐一走查，确认是否满足至少2个实例，中间件数据库等可能就需要集群部署)。

        2. 应用服务部分实例进程所在服务器的资源占用异常(CPU/内存/磁盘)

        3-1. 应用服务部分实例网络丢包率100%：同上

        3-2. 应用服务实例部分网络延迟长：同上 

        4-1. 应用服务部分实例进程崩溃：所有应用集群逐一走查，应用进程kill掉后短时间内受影响，不承接流量，进程可自动拉起并恢复正常承接流量。

        4-2. 应用服务部分实例进程阻塞：所有应用集群逐一走查，应用进程阻塞后短时间内受影响，不承接流量，故障恢复后恢复正常承接流量。 

        4-3. 应用服务实例部分重启：同上

        4-4. 应用服务实例部分关机：同上生命周期管理

        5-1. 组件依赖--组件不可达：所有实例到组件丢包率100%，强依赖组件故障后，服务不可用，恢复后可自行恢复可用；弱依赖组件故障后业务服务使用不受影响。

        5-2. 组件依赖-组件延迟：所有实例到组件超出理论允许的时长后响应对应错误，一些通用超时时长后没有引发超时升级。

        5-3. 组件依赖-组件访问异常：所有实例到组件访问异常，返回自定义异常报错，强依赖组件故障后，服务不可用，恢复后可自行恢复可用；弱依赖组件故障后业务服务使用不受影响。

        系统启动依赖&失效恢复能力：除数据库和其他公共存储之外的其他服务和组件，验证服务可独立启动，不依赖其他，重启完成后，业务可用。

        灾备验证：双活/多活+数据复制(同步复制或异步复制)。其中一个环境注入不可用故障，验证冷备和热备切换后业务仍可正常服务。

        降级验证：核心业务的核心服务以及其他设计了降级方案的应用，验证服务不可用时降级方案是否可行。对依赖的应用服务注入不可用故障，所有核心交易场景下的非关键服务都应该进行降级设计，以保证核心交易成功率。

        熔断验证：核心业务的核心服务以及其他设计了熔断方案的应用，对依赖的应用服务注入不可用故障，熔断实质是设置快速失败避免请求大量阻塞。

环境治理：环境、数据、场景、监控

高可用 资源冗余水位是什么？需要有足够的资源去支持演练的实施。

预发环境功能治理是做什么？准备环境和数据。

        1. 各业务对自己负责：各业务通过混沌演练，发现现有问题，验证目标的实现情况。

        2. 每周跟进真实生产风险、跟进改进落地进展。

        3. 横向团队阶段性验收、对目标达成情况进行度量(监控主动发现率、MTTR)：AZ切换、基础服务故障、依赖故障、多故障同时发生。

解决方案：能力规划

        冗余：指机房内部分节点故障的场景；

        容灾：整个机房或Region故障的场景下，业务要做跨机房甚至异地容灾；

考虑到自然灾害等不可抗力因素，建议企业在有能力的情况下，在另一个城市建立灾备中心，实现数据的定时同步，形成两地三中心或异地多活的灾备架构。

        数据备份：数据因故障被破坏时的恢复能力；

        过载保护：指服务容量在达到或超过一定倍数的情况下业务的流程控制和降级能力。(止损环节，旁路部署切原路线)

        依赖治理：一般分为强依赖和弱依赖，一般的原则是核心业务不能强依赖非核心业务，非核心业务故障时，核心业务要能降级，核心业务故障时，要分析清楚影响。

 保障手段：主要针对过载保护

        熔断：可能存在下游依赖出现故障，导致上游服务级联故障；解决方案是：引入熔断器和优雅降级(本质是通过尽早失败来避免局部不稳定而导致的整体雪崩)，熔断器或熔断机制一般会有打开、半开、关闭3种状态。缓存被打穿之后可用此措施

        降级：牺牲用户体验、放弃部分功能、降低安全性、降低准确性、降低一致性、降低数据量等

        限流：牺牲一部分流量，适用于不可被降级的模块。

        隔离：(本质是通过隔离将故障局部化，避免连锁反应)，一般有动静隔离、读写隔离、热点隔离(本质是指一种针对高频访问数据(热点数据)的隔离策略)、用户隔离、核心(应用)隔离、进程隔离(容器化部署)、线程隔离(比如接口隔离)、集群隔离(对应用的某些服务做集群化部署和管理)、机房隔离。

        重试：可能存在网路不可靠的情况，针对网络抖动，重试是其一解决方案。同步/异步重试     

        超时：超时机制。

熔断、隔离、重试、降级、超时、限流，高可用架构流量治理核心策略全掌握-腾讯云开发者社区-腾讯云

稳态建设：

 日常线上监控：

        指标呢？多维监控都有哪些维度：

                应用监控：进程级

                链路监控：怎么做？调用链跟踪、全链路流量、告警、

                机器监控：设备资源级

                日志管理：请求内容

                前端监控：

                移动端监控：

                数据监控：请求流量

                全域看板：

流量治理

目的：

        服务质量保障：确定关键应用和服务的流量优先级，保障业务关键的流畅操作；(能力)

        网络性能优化：负载均衡流量分配，确保网络资源高效利用、减少延迟、避免阻塞；（性能）

        故障容错和弹性：在网络和服务出现问题时，通过动态路由和流量重定向等机制实现故障转移和自我恢复以维持业务持续可用；（容错）

        安全性：实施流量加密、访问控制和入侵检测等措施，保护网络和数据不受未授权访问或攻击；（安全）

        成本效益：通过有效管理，降低带宽需求和相关成本，同时提高整体系统效率。（成本、效率）