专栏首页资深Tester软件测试人员:你们是如何测试需求变动频繁的项目?

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

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

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

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

什么是紧急项目呢?

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

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

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

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

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

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

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

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

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

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

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

需求

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

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

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

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

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

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

bug定位与分析

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

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

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

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

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

第一,先去看BUG日志;

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

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

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

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

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

本文分享自微信公众号 - 资深Tester(zishentester),作者:王豆豆

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 测试经验分享:做一个靠谱的软件测试人员(一)

    王豆豆
  • 有关测试流程中的问题

    最近在带一个学生,是一个超级认真、努力的学生,布置的作业和学习点都会认真去完成,我能感受到他是在尽心尽力地去做好,从提出的问题中就能看到这个变化,由以前的很外行...

    王豆豆
  • 软件测试新人问题回复(一)

    今天的文章是一个新入行的小伙伴咨询的一些问题,问题有点多,所以分成二次回复,针对这些问题,王豆豆觉得很适合刚入行、未对软件测试有过深了解的小伙伴们学习,故分享出...

    王豆豆
  • 测试经验分享:做一个靠谱的软件测试人员(一)

    王豆豆
  • DevOps中的测试工程师

    DevOps需要在各个阶段进行协作,因此,使开发人员和测试人员从敏捷孤岛式转变为一个在各个阶段中所有成员不断参与的运营已变得非常具有挑战性。

    八音弦
  • 软件测试和开发比例

    这篇文章是我从stackoverflow上翻译过来的,如果以后遇到好的文章我还会继续翻译。

    Peter Shen
  • [android] 测试的相关概念

    /********************2016年5月4日 更新********************************/

    陶士涵
  • ASP.NET Core Web API 集成测试

    本文需要您了解ASP.NET Core Web API 和 xUnit的相关知识.

    solenovex
  • 测试面试题集-1.测试基础理论

    最常使用的测试用例设计方法包括等价类划分法、边界值分析方法、场景法、错误推测法。其中,最容易发现错误的是边界值法,使用最多的是场景法。以注册为例:首先从需求确定...

    ITester软件测试小栈
  • 《Scikit-Learn与TensorFlow机器学习实用指南》 第08章 降维

    很多机器学习的问题都会涉及到有着几千甚至数百万维的特征的训练实例。这不仅让训练过程变得非常缓慢,同时还很难找到一个很好的解,我们接下来就会遇到这种情况。这种问题...

    SeanCheney

扫码关注云+社区

领取腾讯云代金券