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