每日一博 | 功能模块提测前要做的几件事
概述
在项目管理流程中,有几个关键阶段:
需求阶段、开发阶段、测试阶段、上线阶段
其中的需求阶段和开发阶段是最为重要的,一个是设计,定义这个功能如何运作,一个是执行与实现,这两个阶段把控好了,往下走就会顺利很多。下面重点讲一下开发阶段中的提测步骤,在提测前应该准备什么东西,以保证提测的质量。
首先关于提测这个动作,我自己是这么理解的:
提测了,就说明开发人员认为功能就长这样了,已经完全按照产品
PRD
完整的实现了,是个严谨、负责、认真的动作。
理论上,研发人员一旦提测,就可以开始处理其他需求任务了的。
为啥要注重提测质量
在刚才提到几个项目管理阶段中,越早认真越好,早发现问题早解决,如果到了测试阶段,还出现各种各样的问题,基本都是要付出惨痛的代价的。
你有没有遇到过,功能提测后,还出现如下情况:
功能跟产品
PRD
里的不一样,走偏了; 前端BUG
几百个; 严重阻塞性BUG
几十个; 测试环境极度不稳定,测试人员一直来让开发人员定位。
这些问题都会造成极大的沟通成本、执行成本,也会占用很多资源,直接影响了整个部门对需求处理的吞吐量,而这些本身是可以尽量避免的。解决的办法就是狠抓提测这个步骤。下面列一下我自己实战过且发挥了作用的一些手法。
<font color="orange">注意:这里着重强调的是,提测这个动作执行前,要做的事情,关注的是,测试人员接手后,是否能顺利走下去,像架构方案、技术设计、压测、回滚方案呀,这些是另外的动作,是必做的,不会在文章里强调。</font>
提测前要做的事情(不分先后)
完成端到端联调
自己负责的部分再完美也是没用的,端到端一联调,可能就出问题。
端到端联调的重要性再怎么强调都不为过,它可以整体性的验证功能模块是否符合产品预期。像UI
问题、体验问题、后端接口数据问题、兼容性问题等,都可以在这个阶段发现。
另外有两个小技巧可以用上:
- 如果开发环境不太稳定或者数据不全,建议直接在测试环境里做开发联调,把环境调顺了,完成后,测试人员可以在同一个测试环境里做功能测试,可以避免提测后,一大堆环境问题,而测试人员又不知道如何处理,只能找开发定位,造成的资源浪费。当然如果测试人员有能力独立维护测试环境的话,就不建议这么干哈。
- 根据测试人员提供的冒烟用例,有目标的进行开发联调,提高联调效率。如果开发人员很有耐性,能按照产品
PRD
里提的点,逐个验证,那当然更好了。
执行冒烟用例
测试人员在需求评审完后,就需要开始进行测试用例设计了,其中的冒烟用例是一个子集,是基础的用例,这些用例如果无法通过,测试人员就可以将提测的模块打回(<font color="red">会有一封大大的同时又抄送老板的主题为xxx功能冒烟不通过,打回
的邮件发出来</font>),因此开发人员需要认真的执行冒烟用例。
另外测试人员提供的冒烟用例必须要有质量,能准确覆盖基础的重要的功能点。
列出改动点
这里的改动点,说的是,你当前开发的模块,改动了哪些已有的且在线上稳定运行的模块。你需要列出来,让测试人员更有目的性更有效率的去做回归测试。
准备好上回归环境的清单
像配置文件变更、数据库变更,MQ
配置,这些在提测前,都需要准备好,要不然就可能出现功能模块在测试环境或者回归环境无法顺利运行的情况,缺胳膊少腿的,像大一些的模块,涉及到的服务很多,每个服务都有自己变更,不及时
记录起来,很容易忘记。这样会极大的降低功能测试的效率。
我之前遇到过好几次,一个功能模块周一晚上提测,隔天测试人员开始介入,但是直到隔天下午功能模块才顺利的在测试环境里运行,这是多么的不应该,浪费开发人员和测试人员的时间,严重一些的,还可能导致项目延期。
必要时,产品经理提前验收
像大一些的功能模块,涉及到的点非常多,这个时候,如果产品经理有时间的话,可以让其在功能提测前验收一把,这样可以及早发现功能模块是否走偏了,也可以发现很多的前端体验问题,及时让开发人员解决掉。
我是遇到过,一个项目,提测后,测试人员提了几百个
前端体验或者UI
问题,单单是测试人员写BUG
描述,就花费了很长时间,然后还需要让开发流转BUG
,这些都需要时间。
想对测试人员说的
如果开发提测前,上文提到的那些动作没有准备好,测试人员是可以不进行测试的,因为提交给测试人员的,是一个极度不稳定的东西,一旦进入测试环节,就开始坑
测试人员了。因此宁愿按住它
,不开始。另外这也是保护测试人员的一种方式,毕竟队列就这么长,别随便给测试扔一些不靠谱的功能。
另外,测试人员可以理直气壮挑战开发人员的,其实只有一处,就是提测质量
,如果功能模块都上线了,但是出问题了,那么老板第一个找的就是测试人员,因为功能是否能上线,是测试人员决定的,相当于跟老板说:
功能经过严格的测试了,可以交付了。
而事实上,上线后却是一堆问题。因此测试人员一定要死磕开发人员的提测质量
,冒烟不过的,打回,再冒烟不过,严肃警告,还是冒烟不过,那就狠一点,可以直接不测试某些开发组提测过来的模块,因为一提测过来,进入到测试环节后,就又开始各种不顺利,各种浪费。
小结
流程有了,就要开始考验执行力了,这是个难题,一开始的话,比较建议的方式是,项目指定一个懂项目管理流程的技术负责人,授予他/她临时权力,由它全程统筹,到处督战,谁不配合,可以直接指出。按照这种方式,实施几个项目后,大家就会开始慢慢适应。
原文链接
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Jboot v3.3.1 发布,分布式事务新增对 Seata TCC 的支持
Jboot 是一个基于 JFinal、JFinal-Undertow、Dubbo、Seata、Sentinel、ShardingSphere、Nacos 等开发的微服务框架,帮助开发者降低微服务开发门槛。同时完美支持在 idea、eclipse 下多 maven 模块,对 java 代码、html、css、js 等资源文件进行热加载。爽爽开发,快乐生活。 Jboot 目前已经开源超过了 3 年的时间,迭代了 100+ 个版本,已经被超过 1000+ 公司在使用。 Jboot 主要有以下特征: 1、基于 JFinal 的 MVC + ORM 快速开发。 2、基于ShardingSphere +Seata 分布式事务 和 分库分表。 3、基于 Dubbo 或 Motan 的 RPC 实现 4、基于 Sentinel 的分布式限流和降级 5、基于 Apollo 和 Nacos 的分布式配置中心 6、基于 EhCache 和 Redis 的分布式二级缓存 Jboot v3.3.1 更新内容如下: 新增:Seata tcc 的支持 新增:RegexValidate 注解对 Controller...
- 下一篇
DragonFlyBSD 从 FreeBSD 引入 AMD 温度驱动程序
除了部分主板方面的特定问题,DragonFlyBSD 在 AMD Zen 系统上通常都运行得十分正常。现在,它从 FreeBSD 引入了一些新的驱动,整体运行情况有了更好的改善。 从 FreeBSD 引入的部分驱动中,amdtemp 驱动尤其值得关注。此驱动支持对 AMD 0Fh, 10h, 11h, 12h, 14h, 15h, 16h, 和 17h 系列处理器的温度进行监控。其中对 AMD Family 17h 的支持涵盖了 Zen 1 以及 Zen 2,包括 Threadripper 和 EPYC 等。 除此之外还有 amdsmn 驱动。此驱动用于在 AMD Zen 系统上支持AMD 系统管理网络(System Management Network,SMN)。 DragonFlyBSD 团队引入这些驱动后,对它们的代码进行了小幅度改进,目前这些驱动程序位于DragonFlyBSD 代码树中。 与许多 BSD / Linux 社区一样,DragonFlyBSD 项目负责人 Matthew Dillon 对 AMD Zen 2 产品有着深刻的印象,或许这也是 DragonFlyBSD...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7安装Docker,走上虚拟化容器引擎之路