我以前的团队中主要使用这些方法，如果大家有什么好的方法，请大家补充，完善！！

    需求的不确定会导致软件设计过程中的风险过大。千万不要一上来动手写case。

    那么一方面需要让客户或PM（具体情况视工作流程而定）给出尽可能多的信息。包括截图，客户的使用场景，预期的数据量等等。而且可以通过email/yahoo/photo等方式尽可能的获取你所需要的信息。总之一句话，有什么要什么。

    另一方面要通过与Dev的沟通来确定客户的需求大概可能会是怎样的，那我们应该如何实现，往往code设计决定了测试，以及如何进行测试。测试策略是什么如否应该进行性能测试，测试关键点和难度是什么等等。在条件允许的情况下可以广纳建议结合QA对产品的熟悉基础上进行的想法（这种情况下要求QA有一定的想像力）来终确定客户一个比较粗的框架需求。对于那些很细节或者说虽功能性的问题如UI设计等等，可以暂时不要考虑，也没这个必要。

    接下来要做的是搭建一个主要的功能点框架，类似于写文章时的提纲。再往往这个框架里填东西。在需求没有得到进一步确认之前，千万记住此时QA的主要工作应该只是写框架，而不是写具体到哪个button放在哪个位置。即使写的很详细，一旦客户需求产生变化，那么有可能之前写的case得推倒重写。既浪费了时间，又浪费了精力，你的工作也变得徒劳了。过渡的折磨自己去写有可能无用的case，还不如聪明的学会适当偷懒放松自己。当然这是针对大方向的需求不确定的情况。对于那种小需求改动的情况另当别论。在没有进一步的需求信息之前，case设计基本到此为止了。

    以上是我个人的一些想法和意见，大家仁者见仁，智者见智吧。

    我纳闷了，如果没有需求文档，那后面的工作要如何开展哦，如果后面的工作可以开展，那么肯定需要参照什么文档，或是从客户那里收集到的原始需求。

    另外我们可以根据这些文档或是原始需求来制定测试计划，写测试用例，当然过程中肯定会有不清楚或是不详细的地方，这时候我们需要与客户沟通，直至弄清楚为止。

    但是我们弄清楚了，可开发人员是不是也弄清楚了呢？看来还需要与开发人员进行深入交流，使大家对于客户的需求达到一致。