如何从容应对提测

当收到开发的提测后，你是二话不说立刻进行测试呢，还是先找开发沟通确认清楚再开干呢。磨刀不误砍柴工，有些准备工作是可以达到事半功倍的效果的。

首先需要和开发确认实现的功能和实现方式，这是确保开发的设计和需求是一致的。从开发描述的实现功能和实现方式中可以挖掘开发可能遗漏的特殊场景，以及对异常情况是否有处理，如果没有的话开发同学可以立马回去优化，而不必等到一轮测试之后再去修改已经有些遗忘的代码。同时，结合开发的实现方式我们可以补充被遗漏的测试点。可能你会奇怪在测试用例评审的时候不是已经确认过了吗，为什么现在还要再确认。因为评审一般是在开发阶段或者开发前的阶段进行，而coding非常受开发主观因素的影响，所以有必要在开发完成并提测之后进行再次确认。
“这个是在接收到报备请求的时候，判断是否需要过人审，是的话就去发送消息通知。”
“是同步还是异步处理的，发通知时出现异常会影响该请求的正常返回吗？”
“异步处理，发消息异常不会影响后续逻辑。”

过一遍提交的代码。这是确保开发设计的和真实提交的代码一致。可以直接上版本控制系统比如Git去看开发提交的记录，或者在IDE（如IDEA）中将此分支的代码和其他分支的代码进行比对，找到改动点。
“你这块功能应该需要改到vue吧？”
“是啊。”
“但是我没看到你在这个版本提交过vue的代码，你要不再检查一下？”
“哎，真的忘记提交上去了”

检查相关配置，需要执行的sql、需要添加的定时任务、其他配置等。检查sql、配置等不合理的地方，以及确保正式测试之前测试环境已经ready。
“这个发送人员是配置在Nacos上的。”
“我看到你配的权限是FKZG，但是FKZG是风控主管的意思，需求里不是说要发给风控专员吗？”
“噢原来这样，我以为FKZG是风控专岗的意思呢，我改一下。”
“需要满足的产品是员工贷，但是我看你配置的仅仅是001这个产品编号，002和003也是属于员工贷大类下吖”
“我去确认下仅001员工贷还是员工贷大类下的都需要哈”

检查代码是否部署测试环境。如果是用Jenkins进行部署，可以结合提交记录和构建记录确认开发代码是否已经部署到测试环境，如果已经部署上去了就可以进行测试了，如果还没有则需要先部署再进行测试，避免出现造好数据要测试时发现和预期不符，排查了半天之后才发现代码并没有部署成功的情况。

进行冒烟测试。这是确保产物和需求一致。先执行冒烟测试，确保主流程和主要改动功能是可以走通的，再继续执行其它测试用例，注意要先关注优先级高的用例，避免前期花过多时间在和业务逻辑关联性不高的地方。

通过这些方式，在正式测试之前就可以发现一些隐含的问题，同时避免出现无效测试，缩短开发提交版本到收到问题反馈的时间。测试的目的不是为了测试而测试，而是要基于风险尽早去挖掘可能存在的问题。