1需求及设计阶段
1.1需求分析
工作目的:站在技术角度分析产品需求的可行性方案
沟通对象:产品经理
使用工具:Xmind、Excel、Word、Visio、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
1、需求必须是可核实、可以落地、可以执行:必须有一个可观察的结果
2、站在技术角度分析需求的可行性,是否可以提供更优的解决方案
1.2需求评审
工作目的:评估需求的合理性、完整性,产研测三方达成一致
沟通对象:产品经理、测试工程师、UI设计工程师
使用工具:会议、电话、CPC、腾讯会议
操作步骤:
1、评审前
1)产品经理下发迭代需求,研发组长进行组内安排,需求分析;
2)理解需求内容,调研可行性方案;
3)总结并记录需求疑问点,在需求评审会中进行提问;
2、评审中
开发人员参加需求评审会议(现场会议或远程视频会议)
有需求不明确的地方开发人员当场提出疑问:
1)解决了什么问题?
2)提升了什么指标?
3)有什么商业价值?
4)需求的疑问点?
如评审过程中发现需求有遗漏,需要进行补充,若涉及需求变动较大,则进行二次需求评审会议;
开发人员也需要思考产品需求是否合理,可适当提出自己的产品意见;
3、评审后
需求评审后,如有需要更新需求文档的,产品经理需及时进行文档更新,更新后同步给相关研发人员、测试人员、UI设计师。
1.3项目详细计划制定
1、正常排期:需求评审完成后,研发人员将评审会议内容反馈组长,经商讨后研发组长交付排期给产品经理;
2、确定交付日期的情况:产品经理下发上线日期,经研发组长评估调取相关资源后给出排期,;
1.4技术方案设计
工作目的:提供可行性的技术方案并输出技术设计文档
沟通对象:相关开发人员
使用工具:电话、CPC、腾讯会议、语言表达
操作步骤:(系统操作须有图片)
参会需求评审后,给出需求的技术方案:
1、方案设计
1)技术选型(前端/后端框架、日志中间件、消息中间件、数据库等)
2)技术架构(组件与组件之间如何协同工作,如何部署)
3)技术难点预知(明确存在的技术难点,并确定解决方案)
4)性能瓶颈预知(明确可能存在性能瓶颈的地方,并确定应对措施)
5)上下游系统交互(明确在流程中的哪个位置,约定接口文档提供时间、接口联调时间)
6)功能模块划分(任务拆分和分配)
2、输出设计文档
技术方案确定后,输出技术设计文档,包括:总体设计、概要设计、详细设计等
1.5UI设计方案评审
工作目的:确保设计稿与需求一致性
沟通对象:产品经理、测试工程师
使用工具:会议、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
1、参加UI部门组织的设计方案评审会,确保界面与需求一致
1.6测试方案评审
工作目的:校验三方(产研测)对需求的理解一致性
沟通对象:产品经理、测试工程师
使用工具:电话、CPC、腾讯会议、语言表达
操作步骤:
1.参加测试人员组织的测试用例评审会议,会议可通过会议室或远程会议(例:腾讯会议)方式进行;
2.对测试人员在测试用例评审时的“冒烟测试用例”,要认真倾听,并提出自己的疑问;
3.在会议中记录存在的问题,会后及时与测试人员讨论、追踪;
4.接收测试人员发送的测试用例文档;
1.7技术方案评审
工作目的:充分了解产品需求,设计出满足需求的技术方案
沟通对象:产品经理、UI、相关开发人员
使用工具:电话、CPC、腾讯会议、wiki
操作步骤:(系统操作须有图片)
技术方案确定后,需要输出技术设计文档,包括:总体设计、概要设计、详细设计、接口设计等
1、邀请相关三方系统开发、前后端开发、移动端开发、产品经理、测试人员参与技术方案的评审
2、评审过程中有不明确或疑问的地方应当场提出并解决,如遇到无法会上及时解决的问题,记录下来,会后可再进行沟通,修改或补充
3、从多个方案中选择出适合目前的最优方案
4、确定技术方案后,考虑团队现有的资源及项目的优先级,然后根据技术设计文档进行评估排期。
排期模板如下:
2开发阶段
2.1开发编码
工作目的:
编码的目的是写出高质量的代码以更好的满足业务的需求。需求评估后再进行开发内部技术评审,涉及到 数据库设计、接口设计、第三方接口交互等,同时还要考虑代码的封装性、可维护性、可扩展性等。
开发人员也尽量提供一份功能改动点的文档出来,说清楚改动了哪些点,哪些重要的点被改动了,让测试人员做好评估。
沟通对象:产品经理、UI设计、测试工程师、相关开发人员
使用工具:PHPStorm、Vscode、Navicat、电话、CPC、邮件、腾讯会议
操作步骤:(系统操作须有图片)
1、 编码
开发人员编码过程中,需要遵守团队的编码规范,同时严格按照设计文档中的技术方案执行,除了保证代码逻辑的正确性外,还需要考虑代码封装性、可维护性、可扩展性,当编码阶段发现技术方案需要调整时,需要及时通知开发经理,经过同意后才能实施,涉及到引入新框架和新技术,也需要提前跟开发经理沟通。
1)PHP编码规范
URL 请求地址采用”-“分割。
方法名采用驼峰法。
参数必须小写和下划线分割,严禁使用驼峰或者其它格式,且提交参数与返回字段名一致。
获取数据采用 GET, 添加,修改必须 POST 。
API 返回格式必须调用 jsonResult 基础方法。
错误码必须调用 ErrCode,不能直接写错误码数字。
分页采用框架自带的, 自建二维数组必须 [‘data’ => $arr], 分页条目必须使用 limit 参数。
接口返回备注信息(msg), 必须写在 config.msg 文件。
redis 的 key 必须写在 config.redis_key 文件。
composer 安装新依赖必须写 doc/composer.txt 文件中,并说明用途。
新增定时任务,进程必须写 crontab 文件中,并说明用途。
redis 必须有设置过期时间。否则存 mysql,再缓存
model 名字与表名一致(如:表 q_user MODEL:QUser )
请求外网地址,必须设置请求时长 2s
redis 不存储长期数据, 只用于缓存和临时数据存储
2)Mysql 注意事项
字符集 utf8mb4 排序规范 utf8mb4_unicode_ci
数据库字段必须小写 + 下划线
新表字段必须有 status,created_at,updated_at
status 状态必须 1 启用, 0 禁用
尽量不使用 NULL
查询 sql 字段必须加上表名
严禁使用 * 号查询
sql 语句必须写 model,不能写在控制器
更新、插入、删除多条数据,非日志类型必须 “采用事务”(保证一致性)
3)YAPI 文档注意事项
字段说明必须与产品文档保持一致(前端反馈核对字段不清晰)
迭代版本接口需新增版本目录 (防止混乱)
接口有变更,必须同步更新接口文档
4)合并分支事项
必须以 master 创建分支开发,且带上自己的名字和日期(feature-function-username-20221012)
发布至 master,必须先合 master 到开发分支
“测试分支” 禁止合并到 “开发分支”
“预发布分支” 禁止合并到 “开发分支”
2、代码审查
开发人员需要控制代码提交的频次和粒度,每次代码提交之后 24 小时内,需要主动联系代码审查人完成检查,组长负责检查是否执行到位。
代码审查主要审查的内容:
规范性检查(是否符合代码规范、提交备注规范等)
健壮性检查(是否陷入死循环、资源未释放等)
安全性检查(是否存在SQL注入、XSS、SSRF、CSRF、越权、文件上传等)
性能检查(是否存在未加缓存频繁连接DB,是否需要连接池)
2.2环境搭建
工作目的:工欲善其事必先利其器,通过各种环境的搭建、保证项目的顺利开发、测试、上线
沟通对象:运维
使用工具:gitlab、jenkins、阿里云
操作步骤:(系统操作须有图片)
1、开发环境(dev)
开发环境是:开发人员自己使用的测试环境,来进行开发逻辑的测试及前后端代码联调;
2、测试环境(stg)
测试环境是:开发人员前后端联调没问题后,提测后发布的供测试人员使用的环境,来进行所有业务方项目需求迭代版本进行测试;
3、预发布环境(light)
预发布环境也叫UAT环境,是一套跟生产环境非常近似的环境,项目配置、数据库连接与正式环境一致,可高度还原正式环境,可模拟线上环境对项目进行测试,更好的发现在测试环境中,因为一些限制因素而不容易发现的问题
4、生产环境(prod)
生产环境:线上代码运行的环境,真实用户直接访问,必须保证服务器的高可用和稳定
2.3开发联调及自测
工作目的:保证代码达到提测标准,为测试交付高质量代码
沟通对象:相关开发人员、测试人员
使用工具:postman、微信开发者工具、Navicat、Wiki、电话、CPC、腾讯会议、邮件
操作步骤:(系统操作须有图片)
1、根据代码规范进行开发
开发人员需要根据开发排期表中的任务清单进行相关功能的开发,如果涉及到三方接口,需要跟三方部门人员约定好三方接口文档,并按照接口文档进行开发;如果涉及到前后端接口,后端先给前端提供相关的接口文档。
开发完成后,开发人员积极主动地推动联调工作,如果遇到阻碍及时通知组长进行协调。
联调完毕后,开发人员通过Jenkins工具来部署合并代码,再进行自测,并将标准化的自测报告发给测试团队
对于有性能要求的项目,需要开发人员进行性能测试,并出具标准化的性能测试报告
自测完毕后,通过邮件方式进行提测申请,使用标准化的申请提测邮件模板
2、发布自测成功的代码合并到stg测试环境,供测试人员正式测试
开发人员通过Jenkins工具来部署合并代码,来进行提测、缺陷问题修复更新部署再测试;
测试用例评审:开发人员必须参加,避免出现测试与开发对需求理解不一致的情况。
Bug修复:开发人员及时关注 Bug 列表,快速修复迭代发布,如果测试进度存在延期风险,需要及时通知组长
2.4项目跟进
工作目的:把控项目开发进度,及时跟进
沟通对象:测试工程师、产品经理、各端开发人员
使用工具:电话、CPC、腾讯会议、邮箱
操作步骤:(系统操作须有图片)
1、与测试人员、产品经理过冒烟测试用例,保证新功能完整性,旧功能回归场景是否全,有无漏掉的场景等。
2、开发人员需积极主动地推动联调工作,同时对涉及到的主流程进行自测,保证主流程没问题,便于测试人员的工作顺利开展。
3、如果涉及到访问量比较大的接口,需要对接口进行压测,通过压测发现瓶颈所在,提早优化。
3测试阶段
3.1测试执行
工作目的:及时修复Bug和跟进
沟通对象:测试工程师、运维
使用工具:会议、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
1、测试人员将Bug提交到jira缺陷管理平台上,研发人员收到后,第一时间进行Bug修复,并将缺陷问题状态变更;
2、如修复的Bug再次开启,研发人员再次修复缺陷问题并记录;总结经验,减少再次重启bug;
3、研发人员在接收到缺陷问题时,发现测试人员阐述的Bug描述,不在本次迭代需求内,将问题指派给产品经理;产品经理要求研发人员实现此功能,则需要评估时间,在可控范围内继续执行,若超出工期则需上报直属领导、产品经理以及相关人员进行讨论给出最终方案;
4验收及发布阶段
4.1产品或业务验收
工作目的:验收需求,为上线做准备
沟通对象:测试工程师、产品经理、UI交互设计师
使用工具:会议、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
1、提前做好上线准备:
考虑代码合并是否有冲突,如果有冲突提前做好合并工作。
如果涉及到 SQL,提前整理出涉及到的 SQL 语句,不要临时上线出现漏掉 的情况,同时还要考虑历史数据是否需要修复。
如果涉及到后台管理系统,提前配置好 RBAC 的权限。
如果涉及到定时脚本,提前配置好 Job 的执行任务。
如果涉及到配置,提前做好准备。
2、提前做好回滚预案:
根据各自的发布系统,提前做好回滚方案,涉及到多端的提前沟通好。
4.2产品上线
工作目的:因环境不同会导致不同问题产生,保证线上功能的正常使用
沟通对象:测试工程师、产品经理、UI交互设计师
使用工具:会议、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
1、开发人员首先确认 Bug 全部关闭,同时产品人员在测试环境验收通过,然后需要主动推动相关团队理清上线依赖和上线顺序,同时确定回滚预案,最后根据公司运维提供的发布方式,部署到线上环境
2、及时跟踪线上回归测试情况,如遇问题通过日志、线上数据等及时定位问题,并解决问题
日志监控:
容器性能监控,查看内存、CPU 曲线是否正常;
调用次数、响应时长及 HTTP 状态码监控;
异常业务状态码告警时,需要输出堆栈信息;
对外提供的接口,记录响应时间、入参、出参,需考虑敏感数据脱敏;
调用第三方服务,记录响应时间、入参、出参;
数据监控:
新增用户数监控;
发送短信数监控;
使用优惠券订单数监控;
退款订单数监控;
未支付订单数监控;
… 等等
上线后需要密切关注以上指标,查看有无超预期情况、接口超时情况、接口错误日志等
线上环境部署完成后,通过邮件方式通知产品人员和测试人员,使用标准化的上线完毕邮件模板,同时积极推动测试人员和产品人员完成线上验证,线上出现问题后第一时间通知组长及开发总监。
如果涉及到改动比较大,必须使用灰度发布,先用小部分流量测试,慢慢再开放全量
5运维阶段
5.1上线后复盘和总结
工作目的:吸取经验、提高效率、保质保量
沟通对象:测试工程师、产品经理、UI交互设计师
使用工具:会议、电话、CPC、腾讯会议
操作步骤:(系统操作须有图片)
如果需求在测试环境和正式环境,均未测试出 Bug,上线一段时候后出现 Bug,这种问题需定期复盘,复盘模板如下: