功能模块提测前要做的几件事
概述
在项目管理流程中,有几个关键阶段:
需求阶段、开发阶段、测试阶段、上线阶段
其中的需求阶段和开发阶段是最为重要的,一个是设计,定义这个功能如何运作,一个是执行与实现,这两个阶段把控好了,往下走就会顺利很多。下面重点讲一下开发阶段中的提测步骤,在提测前应该准备什么东西,以保证提测的质量。
首先关于提测这个动作,我自己是这么理解的:
提测了,就说明开发人员认为功能就长这样了,已经完全按照产品
PRD
完整的实现了,是个严谨、负责、认真的动作。
理论上,研发人员一旦提测,就可以开始处理其他需求任务了的。
为啥要注重提测质量
在刚才提到几个项目管理阶段中,越早认真越好,早发现问题早解决,如果到了测试阶段,还出现各种各样的问题,基本都是要付出惨痛的代价的。
你有没有遇到过,功能提测后,还出现如下情况:
功能跟产品
PRD
里的不一样,走偏了; 前端BUG
几百个; 严重阻塞性BUG
几十个; 测试环境极度不稳定,测试人员一直来让开发人员定位。
这些问题都会造成极大的沟通成本、执行成本,也会占用很多资源,直接影响了整个部门对需求处理的吞吐量,而这些本身是可以尽量避免的。解决的办法就是狠抓提测这个步骤。下面列一下我自己实战过且发挥了作用的一些手法。
<font color="orange">注意:这里着重强调的是,提测这个动作执行前,要做的事情,关注的是,测试人员接手后,是否能顺利走下去,像架构方案、技术设计、压测、回滚方案呀,这些是另外的动作,是必做的,不会在文章里强调。</font>
提测前要做的事情(不分先后)
完成端到端联调
自己负责的部分再完美也是没用的,端到端一联调,可能就出问题。
端到端联调的重要性再怎么强调都不为过,它可以整体性的验证功能模块是否符合产品预期。像UI
问题、体验问题、后端接口数据问题、兼容性问题等,都可以在这个阶段发现。
另外有两个小技巧可以用上:
- 如果开发环境不太稳定或者数据不全,建议直接在测试环境里做开发联调,把环境调顺了,完成后,测试人员可以在同一个测试环境里做功能测试,可以避免提测后,一大堆环境问题,而测试人员又不知道如何处理,只能找开发定位,造成的资源浪费。当然如果测试人员有能力独立维护测试环境的话,就不建议这么干哈。
- 根据测试人员提供的冒烟用例,有目标的进行开发联调,提高联调效率。如果开发人员很有耐性,能按照产品
PRD
里提的点,逐个验证,那当然更好了。
执行冒烟用例
测试人员在需求评审完后,就需要开始进行测试用例设计了,其中的冒烟用例是一个子集,是基础的用例,这些用例如果无法通过,测试人员就可以将提测的模块打回(<font color="red">会有一封大大的同时又抄送老板的主题为xxx功能冒烟不通过,打回
的邮件发出来</font>),因此开发人员需要认真的执行冒烟用例。
另外测试人员提供的冒烟用例必须要有质量,能准确覆盖基础的重要的功能点。
列出改动点
这里的改动点,说的是,你当前开发的模块,改动了哪些已有的且在线上稳定运行的模块。你需要列出来,让测试人员更有目的性更有效率的去做回归测试。
准备好上回归环境的清单
像配置文件变更、数据库变更,MQ
配置,这些在提测前,都需要准备好,要不然就可能出现功能模块在测试环境或者回归环境无法顺利运行的情况,缺胳膊少腿的,像大一些的模块,涉及到的服务很多,每个服务都有自己变更,不及时
记录起来,很容易忘记。这样会极大的降低功能测试的效率。
我之前遇到过好几次,一个功能模块周一晚上提测,隔天测试人员开始介入,但是直到隔天下午功能模块才顺利的在测试环境里运行,这是多么的不应该,浪费开发人员和测试人员的时间,严重一些的,还可能导致项目延期。
必要时,产品经理提前验收
像大一些的功能模块,涉及到的点非常多,这个时候,如果产品经理有时间的话,可以让其在功能提测前验收一把,这样可以及早发现功能模块是否走偏了,也可以发现很多的前端体验问题,及时让开发人员解决掉。
我是遇到过,一个项目,提测后,测试人员提了几百个
前端体验或者UI
问题,单单是测试人员写BUG
描述,就花费了很长时间,然后还需要让开发流转BUG
,这些都需要时间。
想对测试人员说的
如果开发提测前,上文提到的那些动作没有准备好,测试人员是可以不进行测试的,因为提交给测试人员的,是一个极度不稳定的东西,一旦进入测试环节,就开始坑
测试人员了。因此宁愿按住它
,不开始。另外这也是保护测试人员的一种方式,毕竟队列就这么长,别随便给测试扔一些不靠谱的功能。
另外,测试人员可以理直气壮挑战开发人员的,其实只有一处,就是提测质量
,如果功能模块都上线了,但是出问题了,那么老板第一个找的就是测试人员,因为功能是否能上线,是测试人员决定的,相当于跟老板说:
功能经过严格的测试了,可以交付了。
而事实上,上线后却是一堆问题。因此测试人员一定要死磕开发人员的提测质量
,冒烟不过的,打回,再冒烟不过,严肃警告,还是冒烟不过,那就狠一点,可以直接不测试某些开发组提测过来的模块,因为一提测过来,进入到测试环节后,就又开始各种不顺利,各种浪费。
小结
流程有了,就要开始考验执行力了,这是个难题,一开始的话,比较建议的方式是,项目指定一个懂项目管理流程的技术负责人,授予他/她临时权力,由它全程统筹,到处督战,谁不配合,可以直接指出。按照这种方式,实施几个项目后,大家就会开始慢慢适应。
原文链接
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
每日一博 | 深入理解 Object 提供的阻塞和唤醒 API
点击上方蓝字 ↑↑ Throwable文摘 关注公众号设置星标,不定时推送高质量原创文章 关注 前提 前段时间花了大量时间去研读JUC中同步器AbstractQueuedSynchronizer的源码实现,再结合很久之前看过的一篇关于Object提供的等待和唤醒机制的JVM实现,发现两者有不少的关联,于是决定重新研读一下Object中提供的阻塞和唤醒方法。本文阅读JDK类库源码使用的JDK版本是JDK11,因此本文内容可能不适合于其他版本。 Object提供的阻塞和唤醒API java.lang.Object作为所有非基本类型的基类,也就是说所有java.lang.Object的子类都具备阻塞和唤醒的功能。下面详细分析Object提供的阻塞和唤醒API,它们有一共共同特点:必须在synchronized所修饰的代码块或者方法中使用。 阻塞等待-wait 等待-wait()方法提供了阻塞的功能,分超时和永久阻塞的版本,实际上,底层只提供了一个JNI方法: //这个是底层提供的JNI方法,带超时的阻塞等待,响应中断,其他两个只是变体publicfinalnativevoidwait(lon...
- 下一篇
疫情期间游戏行业网络攻击
由于新型冠状病毒大流行,互联网对我们的生活产生了极大的影响,其中所有变化都会以某种方式影响数字安全。本文会从游戏行业出发,以信息安全的角度来研究我们周围的变化。 主要发现 1、与1月相比,4月每天阻止访问恶意游戏网站次数增加了54%,5月与4月相比下降18%; 2、阻止访问在线游戏主题的网络钓鱼网站次数有所增加。从2月到4月,来自虚假Steam游戏平台网站的通知数量增加了40%; 3、攻击者经常使用Minecraft,《反恐精英:全球攻势》和《巫师3:狂猎》; 4、受到此类攻击占比前几位分别是:越南(7.9%),阿尔及利亚(6.6%),韩国(6.2%),匈牙利(6.2%)和罗马尼亚(6%)。 游戏行业数据 来自不同来源的数据显示,疫情使得玩家活跃度急剧增加。据介绍,今年3月游戏产业,游戏销售等均大幅增长。 四月份,Steam的下载量以及在线播放数量均创新纪录。Steam用户活动图(包括游戏内和仅安装客户端)显示了4月4日的活动高峰。此后,活动开始减少,但速度缓慢。 在疫情期间人们有更多的空闲时间来玩游戏。不同国家/地区的玩家在视频游戏上花费的时间增长表如下: 并不是所有玩电子游戏的人在...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7安装Docker,走上虚拟化容器引擎之路