基于交付用户满意产品的质量体系

背景

为什么是基于交付用户满意的产品

任何一家公司 都应该以使用户满意作为企业的宗旨。向用户交付满意的产品 也是一种价值观的体现。

如何定义用户是满意的

校宝在线是一家ToB 提供SaaS服务为主的公司。在同类产品满意度调查问卷常见的问题中发现 出现频率比较多的几个问题包括 系统可操作性 系统对业务的帮助 系统稳定性 对培训是否满意 问题处理速度 需要优化的模块 实施服务 售后服务等。从中提炼了跟质量相关的几个 可操作性即易用性 系统稳定性 问题处理速度。其中还有一个不那么明显 但实际上与质量息息相关的 系统对业务的帮助。测试人员经常会说要站在用户的视角 这个视角不单是用户的行为习惯、交互 还有用户所属的行业特性。

基于以上背景 制定出了包含需求质量 持续测试体系以及稳定性的质量体系 下面会逐一展开介绍

需求管理

?

需求的质量从业务正确性和设计合理性两个方向出发。

业务正确性

既然前面提到了用户非常关心系统对业务的帮助 那就不得不提客户诉求。我们的态度是重视客户诉求 但不能一味的、不假思索的无脑实现 毕竟校宝是放眼整个教育行业、推动教育服务整体加速进步 因此利于行业标准化、利益化的客户诉求是我们优先考虑的。其次 不能只看诉求 还要看客户的目标 短期或中长期的目标 从而帮助用户寻找实现目标的路径 这部分就是需求背后的价值以及潜在价值。需求即时性比较好解释 比如客户需要一套夏招季的招生方案 你不能在夏招过了才交付招生功能。

设计合理性

教育是一个相对离散的行业 信息化程度低 直到目前依然有很多机构使用手工账本或excel做教务。而不同门类的培训领域又高度专业化 比如语言类培训、艺术类培训、乐器类培训等 都有各自领域的专业化 这使得教育服务的标准化面临巨大挑战。流程、逻辑、交互都要足够贴近实际业务场景 所以此时测试人员常说的站在用户角度决不能是一个互联网用户的视角 而是一个教育服务从业者的视角。

如果说业务正确性决定了客户 老板 是否愿意买单 那么设计合理性就决定了用户 实际使用者 是否愿意使用。

持续测试CI/CD/CT

持续测试不是什么新鲜概念 这里也不想重新定义 只希望说明我对于持续测试与持续集成和持续交付之间关系的理解 以及我们的路径。

其实持续集成中明确提到了要通过自动化测试保证质量 从而达到提效的目的。只是往往实践过程中自动化测试相关的部分容易被忽视或难以实现。那是不是写好了自动化测试代码就可以了呢 很显然 只有它真正执行来才能发挥作用。那什么时候执行呢。引用注明博主shaonbean的一句话

“持续集成使项目团队能够在需要时执行测试 而不是尽可能多地执行测试”

通过下图CT部分能够更清晰的看出在哪些阶段用什么方法测试。

编码阶段通过单元测试和代码检查来实现代码测试 在提测和功能测试阶段 部署测试环境通过接口和UI自动化确保历史功能正确性 这两项测试通过后才算环境部署完成 系统测试阶段主要还是通过手工的功能测试和性能测试来完成 接口和UI自动化用例经过编排后同样可以在项目发布时做线上回归 以及日常巡检。

这样就实现了自动化 手工测试贯穿项目始终。

度量

把需求响应周期分割为开发周期和交付周期两个阶段。

开发阶段关注三个核心维度的数据 bug创建时间、bug修复时间以及bug库存量走势 从而帮助我们判断 各阶段bug被发现的数量 以及该阶段测试用例的有效性 不同阶段bug修复的成本 从而进一步评价开发过程的质量。

发布阶段关注发布频率、发布前置周期等数据 进而提现团队持续发布的能力。

项目交付后 还要继续跟踪现象问题的数量、类型以及修复时常等数据。

规范

度量数据只能间接的提醒我们项目中还存在哪些问题 需要有一个工具来承接这些问题 从而推动改进 规范承接了这个使命。

分别制定了开发规范、测试规范和交付规范 具体规范内容就不一一列举

图中横向提现了研发 - 测试 - 发布的项目完整流程。纵向提现的是一套包括CI/CD - CT - 度量 - 规范在内的可持续改进的闭环。

稳定性

稳定性方面包括两大块 一是主动维稳 类似汽车的主动安全系统 例如车身稳定、刹车防抱死等 其作用是避免发生交通事故 同样主动维稳也是为了避免发生线上故障。考核指标为故障次数。

在复盘以往的线上故障时发现 有79%的故障由变更引起 包括代码变更、配置变更、数据变更等等。而项目发布占变更的绝大多数。此外 用户对核心业务故障的容忍度非常低 因为这些模块的不可用很大程度上会造成整体业务流程阻断的风险。因此 根据业务的核心程度、造成阻断的可能性等维度 将故障严重等级从高到低划分为P0到P3四个等级。在稳定性建设初期 我们主要聚焦于预防项目交付可能引起的P0级故障。在稳定性小组识别到项目的变更可能存在P0故障可能的时候 会走指定的项目流程 该流程的核心是灰度和稳定性测试。

灰度用于验证发布过程和功能迭代可能导致的线上故障。稳定性测试包括高可用验证和性能测试 用于验证系统在高压或资源吃紧时系统的表现。过去的一年里 主动维稳多次避免了线上P0级故障。

二是被动维稳 类似汽车的被动安全系统 例如安全带、安全气囊等 能够在发生事故的时候保护乘客 只是被动维稳更关心一旦出现故障 怎样尽快恢复系统可用。考核指标为故障时长。

被动维稳包括监控、定位和恢复三个部分。线上故障面临一大挑战是如何先于用户发现它并恢复它 无论如何都不能接受由用户来告知我们出了线上故障的事情持续发生。

这时候监控和恢复就起到了决定性测作用。根据预期阀值设定不同维度的监控告警 包括基础基础资源层面的资源监控 像CPU、内存、磁盘使用率等 基础组件的监控告警 像CDN告警、ECK异常监控、事件消费监控等。加上重新编排的用于线上业务巡检的UI自动化和接口自动化测试用例 基本实现了有效预警和及时发现线上故障的目标。一旦确认出现线上故障 要第一时间进入恢复流程。此时的值班人员就像救火队 规章制度绝对不能少。而回滚和重启大部分情况下是恢复过程中首要考虑的步骤 希望可以在操作上足够的简单 都做到了一键化。而自动扩/缩容、高压自动隔离/恢复等K8S自动化的实践 使得在某些特定情况下 系统出现了预警时做到无人介入即可自动恢复的可能。

定位 是在面临线上故障时 最希望跳过的环节。一来 定位本身需要很长时间 会造成用户更大的损失。二来 定位后的修复、发布会给生产环境带来更大的变更风险。因此 在故障处理过程中更多是先恢复后定位的策略。主要在数据层、容器层、流量控制层和链路访问层面上添加了日志 用于协助事后定位问题。

本文转自网络，原文链接：https://developer.aliyun.com/article/785625
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！