软件产品研发流程v1.0
2025-04-19 08:56:36 5 举报软件产品研发流程v1.0
作者其他创作
大纲/内容
测试用例标准建立测试准入准出标准建立和落地对应版本和分支，以集成测试环境上的分支为测试重心，测试完成后该版本上预发和生产。
05. 测试前沿技术探索
阶段二：扬帆起航，各方向建立起基本工具和平台，逐步提升技术和业务能力
逐步提升测试业务能力和技术能力，尽早发现问题逐步建立测试自己的线上的业务监控（基于核心场景用例）
04. 测试技术提升
02. 开发过程管理
Step - 03
01. 需求评审与管理
需求质量可度量开发质量可度量测试质量可度量线上质量可监控
线上问题跟踪管理：需要统一在平台上做管理和流转响应规则建立：需要产出线上故障响应方案，和各业务线响应责任人
04. 线上问题优化和复盘
线上监控
04. 问题预防
Step - 05
建立PRD标准（需要明确的流程，性能指标等）PRD全员负责制：全角色评审，尽量杜绝后期变更，PRD评审需要业务方参与和确认
2周一个版本迭代，一个月2个版本，月前提前一周左右确定版本中需求的范围版本确定后，原则上不接受任何临时插队需求；
02. devops探索
Step - 06
建立代码门禁规则建设测试用例管理平台，实现全类型用例沉淀及迭代优化，打好测试灵魂基础。
03. 开发分支管理
基于AI的测试技术探索基于测试工程的测试架构探索/测试功能能力建设
需求评审过程和记录落地，可量化，数据可分析项目过程中的需求变更数据落地，可量化可分析
PMS主导全场景E2E的用例整理和维护，自动化落地及持续迭代测试工作拆分，迭代节奏正常后，补齐接口测试相关工作
05. 线上故障响应机制
软件产品研发流程
02. 持续提升质量
目标：
处理问题脚本/工具需要经过各方评估和检验（产品，开发测试）故障复盘一定要有跟因，一定需要明确整改行动项，行动计划和测试人，并作为任务项跟踪
03. 测试标准
03. 提升效率
上线方案
Step - 07
开发设计评审，需要拉上产品、测试，如果上下游关联，需要上下游一起参会评审按story提测，做到所提即可测（story功能可以完整走通）
版本节奏（建议2周一个迭代）版本对应分支分支对应环境版本迭代定义明确，按系统迭代，不是按需求迭代PMS目前的痛点：按各需求的节奏迭代和排期，导致比较混乱，无全局节奏，人力配比无法做到最优。
Step - 08
规划和初步落地测试相关的平台和工具（测试数据制造和任务管理等）人员培养与全面业务能力提高
Step - 04
开发阶段
03. 测试管控提升
建设测试管理平台：测试工作管理线上化、自动化；落地多维度自动化，提升测试效率终极目标：建立测试实时验证，实时结果反馈
Step - 01
02. 版本规则建立
01. 质量可度量
需求池规范化管理统一明确迭代的定义：以系统版本为横线，需求分期为纵线TAPD上需求命名规范+迭代命名规范和迭代规范划分
产品需求
测试点分析（内审）、测试用例评审（外审）测试过程可追踪，测试记录完备（功能测试记录，性能测试数据记录，其他测试等）如何评估测试质量（测试质量度量标准需要建立）
性能测试能力和调优能力建设落地自动化（接口与UI）能提升测试平台产品化和方案化
需求评审
阶段三：激流勇进，能力互补形成闭环依赖，技术引领质量
Step - 09
阶段一：夯实基础，明确本职可达的目标
测试产出的缺陷一律平台录入管理，跟需求对应测试提UAT，需要产品在UAT环境自行验证测试意识需要提升，除业务场景外的，极端场景，比如性能，稳定性/鲁棒性。
05. 测试平台/人员培养
技术需求等
需求范围数量需要控制（目的：聚焦工作，做有价值的需求，需求按重要级别和紧急程度2个维度，每个维度中各级别数量控制好），业务方需要内部做需求PK，辨别出真正核心的诉求。
Step - 02
版本计划
01. 需求池建立\\管理
上线清单：资源/配置/数据/人力/上线验证清单/需要配合平台或系统/回滚方案/回滚后验证方案回滚方案中需要明确，需要开发牵头做
线上监控机制线上故障响应流程机制/方案完善（第一响应人\\升级机制\\处理流程\\工具）线上问题溯源：测试是否漏测？测试是否有能力发现？开发问题？架构问题？产品问题？线上使用问题？
测试阶段
UAT
测试用例（功能/性能）执行结果可追溯，可实时量化需要有全局的版本演进节奏和意识拉通自动化和devops机制，提高质量验证效率
代码review是否需要测试参加开发代码分支管理和策略，对应版本节奏，建议系统一个迭代一个版本
产品需要独立UAT，此阶段不包含在测试阶段测试提供技术相关支持，业务相关由产品自行解决（考验自身对业务和系统，包括上下游业务的理解和熟悉程度）基于迭代版本统一UAT
开发设计评审？开发单元测试覆盖新系统-架构设计评审开发与测试配合的模式（Devops）
业务需求
重视评审，问题在评审会上提出/需求讲述不清晰准确，可以驳回--标准？第二阶段重视性能要求，2B端重点关注海量数据查询\\汇总\\导出，移动端的兼容\\性能需求；测试资源提前识别PRD通过，需要明确前端起止时间，后端起止时间，联调时间，明确到模块；测试需要明确测试起止时间；提测节奏
04. 测试环境和节奏管理
形成需求池（业务需求、技术优化、BUG修复、配合外部方需求）输出PRD，并且评审，评审需要全角色：产品、开发、测试（业务方需要参加？）；技术改造需要产品知晓和一起评估。都需要评审分用户、上下游系统、技术改造&缺陷修复
逐步落地devops，试行代码门禁，提高提测质量提测记录需要可追溯，可实时量化，需要相关数据落地
05. 测试工作补齐
0 条评论
下一页
