转测试是项目上线前最后一道坎,需求全部做完并自测后,项目就进入了转测试阶段。很多没想到的问题都会在这个阶段涌现出来,这个阶段大家都会很辛苦,通常都会加班加点。为了缓解这个阶段的压力,我们需要做以下几个改进:
把一些可提前做的事情放到转测试之前做。比如:UI设计师正常是在转测试后来验收视觉效果。但项目周期只要超过1个月,我就会要求UI验收在每一个前端页面完成后,就开始验收视觉效果。当然这个提前,要根据设计师的工作情况灵活调配。一般公司还会有UE设计师岗位,是验收交互流程的。同样也可以提前验收。
如果是一个时间周期很长的项目,我更倾向于分阶段转测试。比如本来项目发开周期需要两个月,根据需求分类,我们可以分成两个阶段性的里程碑。完成第一个里程碑就把这一部分转测试。这样测试压力就被分散了。
测试人员会根据测试用例验收功能,首先会进行单元测试和简单的集成测试。本来这个是开发人员做的,但是测试人员会按流程走一遍。如果连基本功能测试都通不过,会直接打回。所以,让研发人员自测后在转测试,以免浪费时间。
还有一种回归测试的时候经常出现的问题:测试反馈一个问题,开发说已经改了,两个人可能因为沟通方法不对就吵了起来。最尴尬的是测试人员当着开发人员面给复现了bug,所以为了自己不尴尬,自测是一定要做好的。
测试用例一般在需求确定后就开始准备了。最开始我们团队里的测试是按照评审后测试用例的先后顺序来测试。这样测试一轮需要非常久的时间。后面我们决定给测试用例的子项也做一个优先级。先做常见的主流程测试,然后在测试异常测试。对于需要前置资源的测试,统一拿到资源后在测试。这样测试的效率大大提升了。
一般测试需要用到的工具、账号都应该在转测试之前准备好。
很多功能测试都是靠人力去测试的,所以测试周期会很长。要想办法培养测试人员走自动化测试的道路。不要让人力成为测试的瓶颈。目前市面上很多自动化测试的工具,测试人员想要更进一步,还是要多学会使用一些测试工具。当然不是为做而做,而是要根据工作中的要求,选择性的来学习。工欲善其事必先利其器。
很多测试工作市场上都有相对完善的测试工具,没必要自己去模式环境。比如,对于一些兼容性测试,可以使用云测试这种第三方平台来辅助测试。公司只需要购买使用用户最多的几款机型即可。
测试工程师根据测试用例测试出的bug都会提交到项目管理软件,测试出一个提交一个。对于能复现的会有复现的操作步骤和日志。不能复现操作的,要提供日志。同时备注bug等级。一般会优先处理bug等级高的。我前面推荐的teambition、worktile、tower之类的项目管理软件也可以用作bug管理。
bug提交后,研发人员能够收到提醒,在这一阶段研发的工作主要是修复bug,如果前期业务逻辑理解的很清晰,编码规范、自测也做得好。这一阶段相对是很轻松的。如果做得不好,那情况会很糟糕,bug会越改越多。如果真到这一步了,只能优先去处理等级高的bug。
如果测试到最后,真遇到bug多到达不到上线标准。怎么办?这时候项目负责人千万不能强行上线,准备上线后在进行修复。这种冒险不值当,可以选择砍掉一部分你不重要的需求或者项目延期。绝不能带着重大bug上线。
项目测试达标后,就需要着手启动上线了。在项目上线过程中我们还需要做以下准备。
清单的要素包括:什么人,在什么时间,需要准备什么资料,做什么事。其中,要明确先后顺序,要明确如何验证是否出现异常、明确验证方式以及问题处理方式。
有条件的,要搭建一个跟正式环境一模一样的测试环境。先在测试环境预上线一次,把所有的相关环节的资料和流程用清单的形式记录好。尤其是上线过程中遇到的问题。解决后,再重新再走一遍上线流程。最好是能全自动部署,减少人工参与。
上线之前,先对前一个版本进行备份。包括程序和数据。一旦上线出现问题,要能一键还原上一个版本。
不要在周五上线版本。项目上线后,我们还需要观察,所以要尽量避开周五。另外项目上线的时间通常要选择使用人数最少的时间,这样受影响的用户最少。大部分情况都是在凌晨之后,所以一般项目上线后会聚个餐(早餐)
主要是给服务部门做好培训。比如客服、运营、销售。尤其是客服,要告知其可能出现的问题以及应对方案。避免用户反馈问题,客服不知道的情况。这个也可以在测试阶段去做,根据培训的工作量灵活调整。
上线后,还需要观察一段时间正常的用户日志和系统日志。有条件的还需要对重要业务设置关键性指标。指标出现异常要能够有短信或电话预警。对异常的数据要去排查原因。这里不仅仅只考虑”坏“数据的异常,还要考虑“好”数据的异常情况。另外,数据异常不代表是程序有问题,也可能是业务上引发的效应。
如果怕出现问题,可以提前对新功能做好A/Btest的控制。A/Btest是指用户打开软件后,一部分用户看到的老业务A的业务流程,另一部分看的是新功能B的业务流程。这样便于我们观察新功能对用户行为带来了什么影响。如果数据下降很大,那说明新功能可能有问题,我们可以主动隐藏新功能。
上线后要做一个项目复盘,复盘的目的有两个:
一、对于项目中出现的问题,要找原因。根据原因再想解决方案。避免在后面的项目中再次出现。比如说项目延期,可能每次都会出现,但每次出现的原因并不一样。只要我们坚持改进,团队总能达到预期完成计划的一天。
二、对于项目中做的好的,也要讲,该表扬表扬,能推广的推广。表彰推广就是我们团队的价值观体现。我们经常说要打造组织文化,对工程师群体来说,组织文化就是在项目过程中生长起来的。
上线前准备也可能会碰到一些异常情况。这个时候出现问题,只能先找原因,解决后才能上线。比如,我们在上线测试环境的时候,非常顺利。但是在正式环境上线后就出现了异常。这种问题一般是某个环节错误操作或者遗漏操作导致的。说到底还是上线清单写得不够详细。不过也不要过于担心这种情况,解决的多了,出现的概率只会越来越小。
最后,在项目上线并且确定没问题之后,要给团队一个缓冲期,缓解一下压力。所以说周四上线是最好的,周五发现没什么事。周六周日就能好好休息一下。休息是为了更好的工作,因为下一个版本的需求马上就要来了。