提测

提测的意思是提交测试,开发完了转QA同学进行测试.

自测完然后给QA测试

开发完成一个阶段目标,提交给测试验证

业务上线流程:
提交QA功能测试;
提交安全团队做安全测试

 

项目开发百科了解

开发环境(dev):开发环境是程序猿们专门用于开发的服务器,配置可以比较随意,为了开发调试方便,一般打开全部错误报告。

测试环境(test):一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。

生产环境(prod):是值正式提供对外服务的,一般会关掉错误报告,打开错误日志。

三个环境也可以说是系统开发的三个阶段:开发->测试->上线,其中生产环境也就是通常说的真实环境。

 

如何提测?

项目提测对测试工程师来说是再普通不过了.

开发在Dev环境联调, 功能开发联调结束提交给测试, 测试工程师需要在测试环境验证本次新(迭代)功能, Dev环境和测试环境是隔离的, 测试不能在开发环境去测试, 开发也不能在测试环境联调, 这个是必须要保证的.

 

接下来就是谁来部署测试环境呢?  无非两种可能

1.让开发同学帮助部署测试环境

2.测试自己部署测试环境.

第一种是让开发同学帮助部署, 那结果很有可能就是等……, 开发同学都非常的忙, 忙着开发新项目, 忙着修改bug, 忙着联调, 忙着解决客服投诉过来的问题…. 反正就是一直都很忙.

第二种测试自己动手部署测试环境. 对于有好奇心的同学来说, 这正是一个学习的好时机. 展开了讲解 , 无论是哪个行业, 从小白到有资历都需要经过较为漫长的过程, 这个过程会坎坷充满荆棘.

那我们如何自己维护测试环境呢?

开发提测需要提供: svn或者git地址, 项目分支,  新增和变更SQL,  新增和变更服务, 新增和变更中间件, 新增和变更配置文件等等.

更新SQL:

是否有新建-数据库 (create database),
新建表(create table )
更新表(update table)
更新表字段(alert table )
初始化数据(insert into)
新建存储过程(create procedure) 等
更新服务:

服务很好理解, 比如订单管理服务,记录订单时间和状态等; 有会员服务, 记录会员基本信息如年龄,性别, 会员开通日期, 到期日期, 会员级别等: 有优惠券服务, 记录优惠券发放日期, 使用日期, 到期日期等; 不同的服务做不同的事情, 在提测的时候要求给到清晰的服务变更情况,  甚至有些服务有关联性, 有先后更新顺序, 某个服务的更新不能影响其他服务的工作.

变更的中间件:

项目中是否使用到新的组件中间件. 如大数据会使用ES(elastic search), ZK 等等; 新组件的使用需要在提测之前就要告知测试组, 并说明组件运行依赖环境,组件版本等信息, 方便测试提前准备机器和环境等.

变更的配置:

配置的变更也很好理解,每个服务调用都有一个配置文件, 里面信息配置直接影响服务和服务, 服务和中间件的调用等,普遍用application.properties这样来命名的

有了以上这些信息, 测试自己维护测试环境就简单了, 只要按照部署流程来做, 测试的事情就会越来越顺手, 再也不用去找我们非常忙碌的开发工程师, 他们有更重要的事情做, 我们也学到了很多技能, 公司对我们测试的依赖性也会越来越强.

随着项目组的不断扩大和技术的不断革新, 持续集成(CI),持续发布(CD),  DevOps, 也是有可能的,期待这一天早点到来. 理想很丰满, 现实很骨感. 我们一起努力吧!

许多公司现在配置都走中心化路线, 如将配置文件单独抽取出来.

国内应用登记情况来看,Apollo和disconf是最为热门的两个

携程开源配置中心Apollo,使用场景就非常广泛, 有兴趣的同学可以向这方面拓展知识.

配置中心参考:

https://blog.youkuaiyun.com/fenglongmiao/article/details/82986954

https://www.cnblogs.com/xiaoqi/p/configserver-compair.html

版权声明:本文为优快云博主「测试工程师成长之道」的原创文章,遵循 CC 4.0 BY-SA 版权协议
原文链接:https://blog.youkuaiyun.com/weixin_40881502/article/details/83344498

<think>嗯,用户想了解"提测"在软件开发中的定义和流程。这个问题需要结合软件工程的专业知识和实际工作流程来回答。 先看用户提供的几个引用内容。引用[2]提到测试从项目立项就介入,与开发并行;引用[3]详细描述了开发时间评估和提测日期安排;引用[4]则明确解释了开发自测case和提测流程。这些材料很好地补充了基础定义。 需要从几个维度解释"提测": 首先定义核心概念:提测是开发阶段向测试阶段过渡的关键节点,开发团队将已完成的功能模块交付给测试团队验证。这个动作标志着开发工作基本完成(至少是某个迭代周期内),进入质量保障阶段。 然后梳理典型流程: 1. 开发完成与自测:开发人员实现功能后,需要先执行基础验证(引用[4]提到的开发自测case) 2. 代码评审与构建:团队进行代码审查后,将代码合并到测试分支并生成可测试版本 3. 正式提测:通常通过邮件或管理系统提交测试申请,附带版本说明和测试建议 4. 测试准入检查:测试团队评估代码质量,决定是否接受测试(引用[3]提到的明确测试范围) 特别要注意引用[3]强调的两个实践细节:一是时间评估要精确到0.5人日,二是分批提测策略。这反映出实际工作中提测不是一次性动作,而是可以分阶段进行的灵活流程。 最后补充价值:提测流程规范化能减少测试资源浪费(避免测试未完成的功能),同时引用[1]提到的测试过程质量概念也与此相关——规范的提测是保障测试有效性的前提。 还需要考虑生成相关问题来帮助用户延伸思考。比如提测质量如何控制、不同团队协作模式对提测的影响等,这些都能深化对流程的理解。</think>在软件开发中,"提测"(全称**提交测试**)是指**开发团队将已完成编码和初步自测的功能模块/代码版本,正式移交给测试团队进行系统化验证的过程**。这是开发与测试阶段衔接的核心环节,直接影响项目质量和进度。 --- ### **提测的定义与核心目标** - **定义**:开发人员完成需求开发后,将代码部署到测试环境,并通知测试团队介入验证。 - **目标**: - 验证功能是否符合需求设计 - 发现代码缺陷(Bug) - 评估版本稳定性 > 引用[2]强调:现代软件测试从项目立项即介入,与开发并行而非仅作为后期阶段[^2]。 --- ### **标准提测流程(含关键环节)** #### 1. **开发自测(提测前提)** - 开发需执行基础用例(如主流程、核心功能),确保无阻塞性缺陷。 - 提交**自测报告**,标注测试范围及风险点(引用[4])[^4]。 #### 2. **代码合并与构建** - 代码通过评审后合并至测试分支。 - 生成**可测试的版本包**(含版本号)。 #### 3. **正式提测申请** - **形式**:邮件/JIRA/禅道等工具通知测试团队。 - **必备内容**: - 需求文档链接 - 代码变更范围 - 自测结果 - 测试环境部署说明 > 引用[4]指出:测试需提供**开发自测用例**以快速验证主流程[^4]。 #### 4. **测试准入检查** - 测试团队评估: - 代码是否覆盖需求? - 基础功能是否可操作? - 环境是否就绪? - **若未通过**:退回开发,注明原因(如“主流程崩溃”)。 #### 5. **测试执行与反馈** - 测试周期内提交缺陷报告。 - 开发修复后**重新提测**(可能多次迭代)。 --- ### **关键实践与挑战** 1. **分批提测** - 大型项目将功能拆解,分批次提测以缩短周期(引用[3])[^3]。 - **例**:优先提交核心模块,测试提前介入,非核心功能后续补充。 2. **时间管理** - 开发需精确评估:开发时间 + 自测时间 + 联调时间(精确到0.5人日)(引用[3])[^3]。 - **风险**:若提测质量差,导致测试阻塞,整体进度延迟。 3. **质量卡点** - **提测标准**需明确(如:单元测试覆盖率≥80%、无高危缺陷)。 - 引用[1]指出:测试过程的质量直接影响结果有效性[^1]。 --- ### **提测失败的常见原因** | 原因 | 后果 | |---------------------|-----------------------| | 自测不充分 | 测试阻塞,重复返工 | | 需求理解偏差 | 功能与预期不符 | | 环境配置缺失 | 测试无法执行 | | 代码合并冲突 | 版本不稳定 | > 引用[3]提到:若项目紧急,需通过**并行开发**或**增加资源**压缩时间[^3]。 --- ### **提测后的协作流程** ```mermaid graph LR A[开发提测] --> B{测试准入检查} B -->|通过| C[执行测试] B -->|不通过| D[退回开发] C --> E[提交缺陷] E --> F[开发修复] F --> A C -->|测试通过| G[发布上线] ``` --- ###
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值