关于质量标准化的思考和实践
一 定义
1 质量标准化
2 质量内建
3 交付质量
二 共识
1 质量不只是测出来的
A同学:我认为质量是设计出来的,在设计上考虑的各种非功能质量数据,都会落地到代码中。设计的优化会不断的驱动系统质量的优化。 B同学:我认为质量是测试出来的,设计的东西可以避免已知的问题,但在实际测试的过程中,还是会发现其他未考虑到的问题,例如兼容性问题,你能提前通过设计预防吗?所以测试发现问题,问题驱动质量提升。 C同学:听完B同学的发言,我更坚信了质量是设计出来的。在不断的BUG驱动下,我们打补丁式做出来的系统,质量会更好吗?打补丁解一时之急,而后续系统性的设计、重构、升级,才是提升质量的关键点。所以... D同学:如果站到产品层面,我们会怎样去定义产品好不好?在我们定义产品好坏的质量模型里,很可能会包含软件研发相关的非功能质量属性(ISO9126),可能会包括产品舆情、竞品对比中挖掘出的东西。例如,我们去定义一款内容推荐产品的好坏,除了“内容不重复”、“多样性”等维度外,“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准,新功能上线、满足需求,用户就会认为产品好。我们的认知会不断升级,“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈,让质量不断变好。
2 既要、又要、还要、且要
谋而后动的观点:无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析,都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。 探索式测试的观点:无论是保证在设计变成代码的过程中是否100%的完成翻译,还是在测试的过程中受到启发认为应该写下更多的逻辑代码,都是希望所见即所得,想人之未想。B同学说得也对。 技术债的观点:无论是对前段时间的补丁代码进行重构,还是对系统进行架构的升级,还是对基建能力进行优化,都是希望能够打好底盘,走的更远,走得更稳。C同学靠谱。 持续改进的观点:无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情,都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。
3 缺陷发现的时间越早,成本越低
4 测试策略本质上是在质量成本和质量风险之间取得平衡的一种方法
5 开发自测是基本要求和基本素养
三 实践
1 需求阶段
项目开发过程中,发现存在未评估到的需求点,如果不影响到主流程,通过走变更的方式解决。
大型项目进入开发前,需要再评审一遍细的PRD,如果有UED 变更,需要先准备好设计稿再组织PRD评审;
2 资源投入评估
3 系分阶段
目标和背景 功能点及开发人日 系统间和系统内的交互时序图 数据库设计 接口设计(包括提供给前端的接口和提供给业务上下游的接口) 定时任务设计 接口性能评估 兼容性评估(是否兼容旧功能) 灰度方案 系统监控 核对方案 资金安全checkList
4 测分阶段
需要提供给开发的冒烟用例 本次需求的功能点及对应的覆盖用例 本次需求改动点可能影响的旧功能及回归用例 上下游联测方案和时间点 可能导致的资损点分析及需要建核对的场景 接口性能分析 灰度发布方案分析 维护并且更新主干用例库
5 开发&联调&自测阶段
1. 进入项目联调环节后,需要发联调日报(PM汇总发出),并每日晨会同步联调进度。
责任人:PM
2.原则:联调前需要先完成域内的自测;
责任人:开发
3.遇到卡点问题,由接口依赖方主动去push被依赖方解决,如果被依赖方没有及时解决,并影响了进度,需要同步风险
责任人:上游开发
4.联调阶段,上游Mock联调或者真实链路联调发送消息,跟对方开发确认消息是否正确,增加确认过程;真实链路联调和mock联调接口不允许有差异。
责任人:下游开发
5. 由测试同学提供冒烟用例给到开发自测,开发必须把冒烟用例的所有场景走完才可以提测
责任人:开发执行、测试监督
6. 发布前单测增量覆盖率需达到60%,单测通过率 100%
责任人:开发执行、测试监督
7. 提前两天后需完成组内CR
责任人:开发
6 功能预演阶段
预演前需要先完成域间联调 功能预演由测试主导,开发需要在场,如果主链路卡住,需要由开发给出下次预演的时间,并顺延发布时间,周知项目组;
功能预演出现的问题,如果是bug问题,需要由开发本人去推动解决,如果是数据问题,则由测试去推动 环境问题需要完成治理
7 测试阶段
11.9-12.28:设计&开发&联调,已完成
12.21:发票配置后台功能预演,已完成
12.30:开票流程优化功能预演,已完成(延期6.5个工作日)
12.22-1.6:线下测试,已完成
1.8-1.12:预发回归测试,进行中(延期2个工作日上预发,原计划1.5日)
1.13:发布(延期5个工作日,原因:开发人员被其他项目占用资源,进入此项目时间晚)
线下测试进度:100%
预发测试进度:
发票配置后台测试进度:100%
开票流程优化测试进度:90%
项目延期:项目延期至2022.1.13发布,延期5个工作日。 原因:① 开发人员被其他项目占用资源,进入时间晚;② 开发同学前期对工作量评估略少于实际;③xxx项目紧急插入,前端同学需要投入一天。④ 缺陷修复完成时间未如预期,预发提测时间延期2天。 bug修复
回归验证 新开票功能遗留缺陷; 回归嵌入式开票流程; 回归原有开票流程。
8 发布计划评审
发布范围 应用范围 发布顺序 资源梳理 HSF接口 数据库资源 消息资源(metaq) 调度资源(dts) 配置资源(diamond、switch、antx) 灰度计划 发布过程 预发发布过程 线上发布过程 回滚计划 跟踪计划 核对 系统监控 服务监控 风险控制和注意事项 历史数据兼容 幂等逻辑确认 灰度方案 应急开关
9 发布&发布后
10 项目回顾
11 和菲尔兹发布平台的结合
自测类需求与菲尔兹平台的实践
测试接手类需求与菲尔兹平台的实践
冒烟流程线上化,测试可以在平台上添加冒烟用例,并由开发标记冒烟状态,由此我们可以统计冒烟通过率 提测流程线上化,测试可以在平台上把提测打回,由此我们可以统计提测通过率,从而衡量当前开发提测的质量,并针对性地进行复盘
四 总结
MySQL实战进阶
MySQL 是全球最受欢迎的开源数据库,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类应用场景。本课程主要介绍云数据库 MySQL 版的使用、数据迁移、备份恢复、性能优化等方法。 点击阅读原文查看详情!
阅读原文 关键词
系统
用例
场景
问题
产品
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。