上线出现问题之殇以及如何避免

上一篇 / 下一篇  2017-09-17 08:36:55 / 个人分类:测试经验总结

    上线出现问题之殇以及如何避免   
    最近一个月大版本上线出现很多问题,于是领导就把我们叫到一起,谈论了一下背锅的事宜,讨论了解决方案。在这个过程中,大部分人都开始推锅,把锅给开发,给产品,给DBA,即使在讨论解决办法,也是在想怎么把锅甩出去,我们也只能讨论但是我们自己就真的没有问题吗?我认为这将对测试团队能力的提升,测试团队的氛围,和测试团队做事风格的提升等方面产生许多不良的影响,这样会让团队成员把精力大部分放在推锅和甩锅上面,而不是自己如何去尽最大努力去避免出现这些问题,会和其他团队形成对立面,而不是把自己作为团队中的一员去想着怎么把事情做好。最开始上线也会出现很多问题,领导就制定了一个惩罚制度,对于线上出现问题,背锅的人需要发钱。但目前看来效果并不理想。对此,我想说说自己的观点。   首先介绍一下我们的上线流程,测试开发整个一个流水线,先是测试开发共用一套测试环境,并行进行开发和测试,整个提测以后会合代码到预发环境,在预发环境测试结束后会正式上线。上线的过程没有文档,整个过程由开发主管执行(上线过程是全自动化的,只需要上传代码即可),涉及到数据库的部分是由DBA设计和执行,测试只负责验证,在这个过程中,DBA也不会交代自己去修改了什么,更新了什么。    作为测试人员在这样的环境下怎样通过我们自己的努力去尽可能避免问题的发生:   
    一、避免临近上线还在新增需求和改需求的问题    
    1.首先除了与需求、开发进行三方评审后,写checklist的时候,对需求进行需求测试,这个过程需要把一些需求不合理的地方找出来和需求进行沟通和讨论,如果确实不合理需要及时通知开发进行调整,需求需要修改自己的文案,重新提交,测试需要标记修改的内容。这样避免了在需求不合理的情况下开发进行了开发,后面再进行返工的情况,也让测试人员充分理解功能以及功能应用的业务背景,在后面的测试中游刃有余。   
    2.其次,基于测试和需求沟通一致,理解一致的条件下,本公司采用测试、开发共用一套流水线,开发在提交和未提测的过程中测试需要关注开发的开发的功能是否与需求一致,如果是不一致,需要及时和需求、开发进行确认和沟通。不盲从,不妄信,一切以业务背景为基础,这样从测试的角度去避免从开发开发出来的产品与产品的需求不一致。   
    3.最后,和产品沟通避免临近上线还在新增需求和改需求的问题,尽可能提测以后不提交新的大需求和大需求的改动(除非是致命性的),若在提测以后产品提出需求变更,我们需要与开发共同评估工作量和风险,判定变更的风险是否过大,如果过大就推到下个版本再上线,如果影响不大,可以上线。    
    二、避免上线以后因为DBA刷数据出现问题   
    1.如果可能,找DBA沟通,在线上他需要做哪些操作,测试人员需要根据这些操作判定是否到位,在上线以后需要从页面上着重对这些地方进行验证(因为测试人员没有权限访问线上数据库)。  
    2.上线以前测试人员尽可能和开发沟通、了解DBA需要做的哪些内容,自己需要从功能上怎么验证,做到心中有数。
    3.通过测试,测试对业务很熟悉同时在测试过程中已经了解了哪些业务与DBA刷数据有关,自己需要做一个罗列,如果可能,可以发邮件告知DBA,这样既是一种善意的提醒,也避免DBA事情、多任务重出现漏掉的情况,测试人员也能够做到心中有数,在上线后验证时做到不漏掉、不遗忘。
   三、避免上线以后出现大问题
   1.上线以前测试人员需要对自己负责的测试内容做一个上线评估,做一个列表(不管是正式还是非正式的),评估哪些模块风险比较高,需要注意什么,比如兼容老数据的问题,代码是否上传的是最新的等等。
   2. 测试人员的冒烟测试用例需要根据自己工作情况尽可能写的详尽,需要在上线以前写好关于要上线的版本的冒烟测试用例,因为如果我们上线时间是在半夜,这个时候我们的大脑思维很难很活跃的思考问题,如果有详尽的冒烟测试用例,这样我们就可以按照冒烟测试用例,机械的验证,也就避免了漏验的情况。
   3.线上也适度的推行自动化,这样关于一些正常流程由自动化执行,测试人员只需要集中精力去关注需求更新的部分。
   4.坚决拒绝在测试过程中,开发或者DBA说测试环境不做,直接去线上做的情况,应该尽可能的去要求所有的操作必须要经过在测试环境中测试过后才能上线。如果不能做到,需要把这些操作的优先级调到最高,在上线以后重点验证这些地方。
   以上是本人的一些拙见,欢迎给出意见和建议。

TAG:

引用 删除 xyp159   /   2018-01-24 14:23:31
原帖由leizi1126于2017-11-30 15:48:19发表
1.首先除了与需求、开发进行三方评审后,写checklist的时候,对需求进行需求测试,这个过程需要把一些需.

这条在实际情况中其实存在,即使开发听测试的也不允许绕过产品,应该以产品经理为中心,测试提交不合理的需求文档给产品经理时,产品经理应该按照自己的判断采纳建议并即使做出修改和文档,下发给于项目任何有关人员。反之开发提出问题,同理,产品这个时候应该起到一个调度器的作用
测试菜菜鸟的蜕变 引用 删除 幽幽草哈哈   /   2017-11-30 21:26:14
嗯,同意,发现需求不合理,这时应该首先和产品经理沟通,所有的需求都应该在开发 初期一一确认,一但在开发阶段发生需求变更,那么都需要第一时间通知产品经理。
leizi1126的个人空间 引用 删除 leizi1126   /   2017-11-30 15:48:19
1.首先除了与需求、开发进行三方评审后,写checklist的时候,对需求进行需求测试,这个过程需要把一些需求不合理的地方找出来和需求进行沟通和讨论,如果确实不合理需要及时通知开发进行调整,需求需要修改自己的文案,重新提交,测试需要标记修改的内容。这样避免了在需求不合理的情况下开发进行了开发,后面再进行返工的情况,也让测试人员充分理解功能以及功能应用的业务背景,在后面的测试中游刃有余。  我对这条有疑问,一般如果发现研发过程中,发现需求不合理,这时应该首先和产品经理沟通,开发根本不会听一个测试的,并且所有的需求都应该在开发 初期一一确认,一但在开发阶段发生需求变更,那么都需要第一时间通知产品经理,项目经理,因为测试人员本来不能做决策,还有开发人员不会 同意你说的
 

评分:0

我来说两句

Open Toolbar