质量保证策略

1.质量流程把控

1.1 风险前置

1）需求评审准入，在需求评审阶段，基于业务目标评估方案实现的合理性，从方案设计、灰度方案、数据处理等方面识别产品设计问题，涉及第三方的需求必须对其双方研、测联调及上线时间，已关注结论并监督产品结论留痕。

2）用例前置评审，通过前置评审保障产、研、测对需求细节理解的一致性，可根据需求复杂程度和研测比评估，超过一定工作量的需求必须提供P0用例进行评审，研发提测时需严格执行通过P0才可提测

3）开发阶段，研发在开发过程中或测试在设计测试用例时发现有需求不明确或设计方案有变动时必须找产品确认，需求内容有补充或修改的必须通过需求变更流程并同步相关研、测

4）测试资源前置，基于测试方案提前准备测试物料，例如账号、id、设置白名单等，需外部协助提供的，明确物料的要求和提供时间

5）多轮验收，对于复杂项目，功能通常需要分阶段实现。多轮验收可确保每个阶段的功能都能达到预期标准，便于尽早发现潜在问题，避免在项目交付后出现重大缺陷，在复杂项目中测试通过后，可在预发环境（若有）通过邀请产品、PMO、运营进行首轮验收，确保功能符合预期。每个功能模块完成后，邀请相关人员就单一功能进行验收，在整体回归阶段，又对项目全局进行整体验收，前置发现产品设计问题、产研理解不一致的问题，确保项目按计划推进。

1.2 协同保障机制

        建立日会制度，与产品、开发、运营等项目成员通过每日站会实现产研测三方高效同步：会议同步测试覆盖率与阻塞用例，拆解技术卡点，并明确责任人/deadline，研测同步进度风险。

1.3 工具提效

1）接口自动化，涉及接口测试的，同步创建接口自动化用例，实现一键执行回归测试，提高测试效率

2）精准测试，对于复杂需求，开发代码改动量大，影响范围广，按照测试用例完成场景验证后，并不能保证场景100%覆盖，为保障代码逻辑验证到位，利用接入感知器进行带阿米覆盖率检查，定位遗漏测试点，提高用例完整度。

2、高并发性能保障

2.1 功能点梳理及风险评估

        前端、后端共同梳理系统所有功能点以及每项功能的调用路径、前端接口、后端接口、调用次数，接口是否涉及数据库DB读、DB写、涉DB表、是否涉及ES、缓存、MQ消息、OSS存储、涉第三方接口等，并依据上述信息拉齐产、研、测进行风险评估。

2.2 高峰流量分析

        通过监控系统高峰期分析流量数据和接口调用情况，合理评估接口调用顺序和调用量，尽可能减少重复调用的设计。

2.3 高保真压测

        压力测试设计需高度还原真实业务场景，在压测方案中应优先选择线上真实流量作为基准，尽可能覆盖不同用户角色不同行为，同时模拟接口调用链路的执行顺序、频率，从而有效验证系统在高并发下的真实表现。

2.4 特殊场景异步处理

        在高并发场景下，业务对时效性要求不高且对性能负载压力较大的功能，可对批量读写接口采用异步处理机制，通过消息队列实现服务解耦与流量削峰。如大量数据导出下载通过异步推送MQ的方式，既减少超时导致下载失败又通过削峰机制环节数据库负载压力。

3、稳定性保障机制

        保障系统稳定性是大流量项目面临的一项重要课题，合理的容灾设计、全面的兜底处理是测试时考察的另一重点。

3.1 主动/被动降级

        当系统负载较高、或者系统异常时，可考虑进行自动降级和手动降级。

3.2限流演练

        激增的请求会导致接口占用过多服务器资源，使请求的响应速度降低或是超时，甚至导致服务器宕机。定期进行限流演练，在衣服啊环境模拟单机限流、集群限流等场景，利用压测工具逐步增加流量达到jsf或网关限流值，在次极端情况下给用户展示兜底页面，以此降低服务器压力。

3.3兜底策略

        为保证最大程度削减对用户的影响，系统需对各种异常做兜底处理，例如针对系统的超时处理，利用设置接口超时事件，在预发环境模拟真实超时场景，验证处理结果复合预期。

4、上线管控

4.1 上线前验收回归

1）分析回归机制，建立最小回归和最大范围回归机制，对于影响核心流程的P0、P1级需求，是基于最大回归范围用例实现全面覆盖，对于非核心流程的改动，则按最小回归用例执行，当然，回归范围需要与开发充分沟通，对于新增的功能，需持续维护回归用例。

2）高效验收模式，为保证验收质量，需邀请产品、研发、运营、体验BP全员验收，但在此过程中容易产生效率低下的情况，对此，我们考虑通过“流程演示-配置核验-探索性验收”的方式来保证验收效率和质量，通过测试录屏使验收人员快速了解功能全貌，确保功能符合预期；通过配置项讲解保证运营理解到位，一定程度上避免运营配置问题，同时通过自由探索性验收模拟用户真实行为，识别潜在问题。

4.2 灰度发布策略

        涉及AB实验或重大改动的需求，为保障上线后无重大问题，采取灰度发布、逐级放量的策略，因此，分流策略的有效性是测试工作的另一重点，一方面，需验证AB策略或人群策略复合预期，另一方面，还需考虑人群交叉命中的情况，以及均不命中的用户如何处理。

4.3 版本管控

每次上线的功能，为规避新上线功能对旧功能产生影响，需要对版本过度重点测试：

1）核心P0级功能验证。可通过手动或使用维护的自动化对P0功能完成验证，自动化若支持多环境的，可前置在测试、预发环境先通过验证，上线后P0需确保全部验证通过。

2）上线准备。上线前检查需注册的接口、SQL、MQ、调度任务等是否在线上完成注册。

3）上线顺序评估。前端上线、运营配置、服务端上线的先后顺序需合理评估，上线期间存在代码新旧替换的中间状态，例如在服务端增加字段，存量数据是否涉及洗数。有时需要考虑这种中间态做特殊逻辑处理，例如对当前的参与状态作缓存，跨天后用户才可访问新数据。

5、监控预警及应急处理

        在大流量场景下，如何识别、分析风险，将损失降到最低，监控必不可少。构建高可用性监控系统的核心价值，并非通过冗余告警来堆砌，而是通过高信噪比的报警来确保系统的有效性。及发现故障准确告警并直指问题核心。

5.1 全链路系统监控

1）硬件资源监控。如CPU利用率、内存使用率、磁盘I/O吞吐量、网络贷款使用率、TCP连接数等；

2）性能监控。服务端已关注监控API响应时间、吞吐量、错误率等；前端已关注LCP、FCP、CLS、FID、TTFB以及页面完全加载事件、首包事件、白屏事件等；

3）组件监控。前端的API请求告警，js报错监控，图片、网络资源等网络层报警灯；服务端更已关注数据库、R2M读写异常告警；

4）依赖服务故障。对外部第三方接口、组件的报错、超时等异常情况监控预警，并执行降级处理。

5）业务场景异常监控。围绕接口状态码异常构建多维监控体系。

5.2 业务数据可视化监控

        针对业务访问量以及业务数据仅监控，形成数据看板，利用同比、环比方式分析，力求更准确、高效的发现风险或潜在问题。例如：监控流量稳定性、用户关键行为监控、防控资损风险。

5.3 关键配置巡检

        为保证运营配置正确有效，一定程度上减少运营配置错误产生的线上问题，考虑对关键、易出错的配置进行自动化巡检。

5.4 异常告警应急处理

如何及时接口告警并快速响应，将损失降至最低是做监控的核心目的，异常告警及异常处理的时效性显得极为重要。

1）告警批次方面，通常根据实际场景来确定，同时需结合经验合理调节，比如：XX接口调用超时异常，设置为10S内出现50次触发告警，但对于其中XX类型相关的告警会增加频次。

2）在通知方式上，可以采用邮件、短信、微信、内部通讯软件等方式触达，对于优先级较高的关键告警建议采用更容易已关注到的通知方式，增加触达被已关注的几率，保障问题处理的时效性；

3）在应急处理方面，开发、测试执行值班体系，提前安排好值班人员和联系方式，对于业务性异常，紧急关停入口，同时报备相关人员。另外晨会同步通报昨日异常处理进展，事后从技术层面、流程层面进行故障复盘，沉淀知识库或形成SOP。

6、质量保证规划

6.1 测试用例智能化生成

        AI与测试工作深度融合，在提升测试效率与质量方面有客观的前景，基于业务信息对大模型进行训练，AI通过分析需求文档与历史测试用例，可以自动生成可覆盖核心功能的测试点，识别潜在的测试盲区，保证测试完整性。但高质量用例的生成，依赖对大模型的持续投喂以及提示词的优化，目前这部分工作还需持续探索。

6.2 日志智能解析

        利用AI与日志结合进行缺陷分析，是另一可探索的方向。通过将特定的异常逻辑进行模型训练，AI可自动分析日志报错信息，迅速准确地识别问题点，辅助测试人员高效定位缺陷。这种方式有望取代传统的手动查验与分析异常的方式，在线上监控中也可发挥重要作用。

6.3 UI自动化完善

        可以通过脚本的录制、回放，自动识别页面元素与交互逻辑，同时介入mock能力，模拟不同场景下不同用户的操作行为，生成高可用、已维护的UI自动化脚本，以提升巡检效率与监控覆盖率