测试人：拿到需求之后要做的二三事

正常情况下，业务方来了一个需求，产品会将需求分解，设计成需求文档，开发也会根据这个设计对应的接口文档，而测试，需要做的是结合需求文档、接口文档以及自己目前对业务的了解，设计各种场景，考虑目前这样的设计，是否存在弊端，并且进一步明确一些不确定的点。

一：多与产品沟通

在某种维度上，测试是最了解业务的人，而且测试考虑问题的角度，应该是从客户的角度出发，这与产品的角度所类似。所以，为了更好的了解需求，也为了能及早的发现一些设计上的问题，测试应该与产品保持密切的联系。就产品需求，多与产品沟通，明确业务背景、需求愿景、具体场景、实现逻辑等各个点。一个研发团队，与产品沟通最多的人，不应该是开发，而是测试。

二：新增功能不一定是测试的重难点

一份测试用例设计，一次需求剖析，我们首先要明确的是这次测试，哪些点是重点，哪些点是可以后期优化的不是这么重要的。

如果这是一个完全的新产品，那么本次的改动点，都是重点。但是更多的时候，我们拿到的是在现有产品上的一些更新优化，有时候，新的功能就不一定是重点了。

1:向“钱”看齐，公司利益至上

举个例子，本次在车辆出库操作的时候，增加了一个可以批量的动作，方便业务人员操作。那么，这个批量的操作里面，那些极限的可能发生问题的场景，其实根据发生的概率，不是那么的重要，反而，这个车不能出库的车被出库了，或者说车费用没算对&#