需求文档不明确，怎么处理？项目很紧急，也会写测试用例吗？

需求文档不明确，应该怎么处理？

不管哪个公司，大公司还是小公司，一直以来都会有这种问题，也许是互联网行业的特色。。其实现在很多互联网公司的这类问题很难解决。

产生需求不明确的情况分析：

1.客户不知道自己想要什么。

2.客户需求明确了，但是在开发过程中，频繁修改需求。

3.产品同学考虑需求不严谨或产品同学能力不足，导致需求功能改来改去。

4.项目催的紧，老板要求，一般都是产品压开发、测试时间，需求不明确也不找自己原因。

5.人员变动，导致需求经历好几手，在项目迭代过程中对历史数据从不考虑，产品对历史数据逻辑处理不足。

那么如何处理呢？

1.对于客户不知道想要什么，客户频繁修改需求：

让产品同学有计划、有规划的了解客户的需求，这个没有什么好办法。测试同学就是把现有的问题整理出来，列成一个表格，发给产品，让产品分版本、分不同的迭代进行逐步实现。

2.产品能力不足

我之前也遇到过几个产品同学能力很差的情况，这种情况真的很憋屈！

产品说什么改什么，产品逻辑思维不清楚，你就让他说清楚了再到工作群里同步。

通过其他方面好好帮帮他呗。如果不想带他，那就让他自己把逻辑说清楚。

3.测试同学要把产品同学需求不明确的功能点一一列出来，不光跟产品说明，也要留下证据。

项目很紧急，也会写测试用例吗？

我的回答是:“不管多忙也好，都应该要写测试用例”。但是我们这时不必非要编写非常详细的测试用例，编写测试用例虽说是一个很好的习惯和梳理功能的步骤，但是这是一个非常"烧脑"的过程。

如果你是一个没有什么经验的测试小兵，那我劝你可以加个班、加个点好好理解和梳理一下业务逻辑，然后自己将这个项目的用例编写一波，因为你刚刚入行对业务还不太熟悉的时候，最好就是。

写过测试用例的人都知道，其实编写测试用例的时间远远大于测试的时间，在整个测试流程中，测试用例占了绝大部分的时间，而测试过程仅占了其中一小部分，因此，如果项目很赶时间，可以先按照自己的思路去测试，在测试完成之后及时把这个思路记录下来，如果没什么时间，在写测试用例的时候可以不用写得那么详细，只需要把测试标题写上，标题中反应了你的各个测试点，这样整个测试过程就可以保存下来了，等到以后有时间了，再来补充测试步骤等。不管你有多忙，只要你想，只写个标题的时间总是能挤出来的。

xmind是个好东西！！！