软件测试人员:你们是如何测试需求变动频繁的项目?

王豆豆最近一直在加班,天天都加班到九点多,项目大多是紧急上线,但其实每天的工作量并不算多,按理说应该在上班时间就能完成,但每天到了下班时间却走不了,不得不留下来继续做。

加班的原因无非二种:1,项目需要上线;2,测试任务没有完成

测试任务没有完成的情况比较少,常态是每天临近下班的时候,开发要不就在这个时候转测,要不就是临时有一个小功能修改完要上线,又或者是紧急安排了一个需求会议,又或者是联测等。

什么是紧急项目呢?

紧急项目是那类上线时间很紧急的项目,比如今天转测,就要求今天或明天就能上线的项目,这类项目就是属于紧急上线的项目,这类项目有一个特点就是需求不明确;测试时间短。

测试人员基本都是临到转测时,才知道有这样一个测试需求,但又因为从接到这个类测试任务之时到上线的时间间隔都很短。

正是因为该类项目的特点,这类项目测试结果没有保障,基本都是测试完主要流程,就匆匆上线了。还有一类项目是这类项目的加强版,是紧急项目的同时需求不断变动。

王豆豆最近做了几个这类的项目,从接到项目的同时才知道测试功能和上线时间。

接到这类项目基本不会编写测试计划,测试用例等文档,接到项目就开始理解需求,与开发沟通改动范围和测试范围,然后开始测试,如果是运气比较好的时候,还没开始测试就能发现以前的结构设计不对,需要改;运气不好的时候,基本都已经测试完成了,才发现需求设计不对,需要重新修改。

有时改动范围不大,可能是表的数据修改了几个字段,有时改动范围大,是整体的流程都有所变化。

对于测试人员来说根本没有什么改动范围不大之说,就是只改了表的几个存储字段,也需要回归以前所有的功能。

如果你觉得上面的项目已经很难了,那还有更倒霉的,测试人员明明是加班加点测试出来的项目,临到上线的却说此功能或者此版本不上了,当然这些对测试人员来说都是常态。

正是因为这些事情在无形之中给测试人员增加测试时间,增加测试难度,导致测试人员对自己测试的结果不放心。

那如果是你碰到这类项目,应该会怎么做呢?欢迎大家留言探讨。

王豆豆针对需求变动频繁项目思考的应对之策:

需求

需求是源头,项目变动的原因就是需求不明确,又或者是需求改动频繁,那为什么会出现这样的问题?

出现这样的问题大多都是开发人员对需求把控不够,刚开始计划是只改动一点点,也有可能是觉得自己的代码不改,兄弟方修改就行,后面等到测试过程中,测试人员提出BUG,发现需要修改代码,而且修改的范围还很大。

其实出现这样的问题本质上来说是因为没有遵循测试应该尽早介入的原则。

应对之策:测试人员在接到项目时,先不急于开展测试工作,可以先与相对应的需求人员和开发人员沟通,可以从先从业务流程方面与需求人员、开发人员沟通,同时知晓开发人员修改思路,代码设计结构等

这不仅是测试人员在了解需求,同时也能起开发人员反思自己的代码设计,如果是设计方面的问题,大多能在此时发现,不会出现测试到一半时才发现,浪费了测试时间。

但这个方法对测试人员要求极高,需要测试人员熟悉业务、熟悉场景设计、业务流程等,同时还需求测试人员对代码有一定的了解,如果讨论之前就知道整个代码的设计框架会特别有帮助。

bug定位与分析

因为是紧急上线的项目,测试时间都很短,那么测试人员需要把大量的时间花测试功能上面,而不是将时间浪费在环境上面。

在项目中遇到这样一种情况:

当开发人员转测的当天,测试人员和开发人员当天都会花费很多时间在调试环境上面。测试环境和开发环境是相对独立的环境,这也导致了有些配置不同的地方,开发人员在转测邮件中需要明确列清本次项目需要修改的配置,那么测试人员在配置环境的时候才能配置完善。

如果前面都做很好,那可以避免环境的bug,但由于某些原因,测试人员在测试过程中还是会遇到一些环境bug。

测试人员在测试过程中遇到BUG时,

第一,先去看BUG日志;

第二,根据BUG日志定位BUG错误的原因,是环境问题还是编码问题,又或者其它问题;

第三,根据分析的结果,能解决的问题尽量自己解决,比如是操作不当某个配置未配;

第四,如果是编码问题,则反馈给开发人员,提交bug,如果测试人员能定位出是什么原因的导致的更好

在这里并不提倡遇到某些bug,测试人员不懂,但使劲钻研,这样反而会影响效率,主要是解决环境类,接口类,因配置或操作而引起的非bug问题。

同时不提倡测试人中一遇到bug不看不管,直接扔给开发人员解决,建议看bug日志,分析bug出现的原因,以便下次遇到类似bug。

原文发布于微信公众号 - 资深Tester(zishentester)

原文发表时间:2018-01-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

SDN实战团分享(十四):网络设备自动化遇到的问题与思考

我一直是做网络的,而且是大家常说的物理网工。 干了16年。虽然,刚刚毕业哪会干了几年的DBA 和SA 的工作。后来就一直在做网络。 企业网,城域网,骨干网都算是...

3986
来自专栏Linyb极客之路

运维管理之线上故障处理原则

墨菲定律暗示我们,如果担心某种情况会发生,那么它更有可能发生,久而久之就一定会发生。这警示我们,在互联网公司,对生成环境发生的任何怪异现象和问题都不要轻视,对其...

2033
来自专栏Java学习网

程序员需谨记的8条团队开发原则

  当你从学校出来,找到第一份软件开发工作的时候,你就不再是一个单独作战的程序员了,你将会有一个团队,你的一举一动也将直接影响团队的效率和产出。下面这8条团队开...

3355
来自专栏云计算D1net

云原生机制的三个核心思想及其未来之路

摆脱临时性自动化方案之定位,发挥优势以实现可预测功能。 ? 您能否以每周为单位向客户发布各类新功能?甚至进一步达到以每天乃至每小时为单位?新晋开发人员能否在上班...

2664
来自专栏SDNLAB

命令行界面(CLI)消亡史

IT行业正在向所有的一切都采用应用程序编程接口(API)演进,这使得企业能够自动执行重复性任务,提高效率并减少错误的系统。但是,这引出了新的问题:在IT系统中A...

3524
来自专栏SDNLAB

JUNOS DEVOPS尤便捷 更精彩

一、 新一轮IT变革来临(DEVOPS) 如今IT发展风起云涌如火如荼,各领域技术百花齐放,各山头厂商占地为王。纵观整个IT江湖,虽拥有众多的昙花一现和太多的不...

3408
来自专栏北京马哥教育

25年Linux内核开发经历总结出来的九条经验

原文: 9 lessons from 25 years of Linux kernel development 作者:Greg Kroah-Hartman 翻译...

39711
来自专栏令仔很忙

软件文档总结(二)

   软件需求主要是从从现实中分离功能,描述软件要“做什么”,在软件需求说明书中,主要的功能和联系如下:

1712
来自专栏云计算D1net

如何集成云层与本地存储

云和本地存储正走向越来越紧密的整合,于是云成为了另一个存储管理员可用的层级。 ? 组织不大可能把100%的数据都移到云服务上,但大多数企业都会至少想让一部分数据...

3176
来自专栏ThoughtWorks

致测试同仁们:让我们做安全测试吧!|洞见

本文首发于InfoQ: http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safe...

3764

扫码关注云+社区

领取腾讯云代金券