没有需求文档的时候如何来设计测试用例
从做测试过程中发现，一般没有需求说明文档有3种情况
1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务分配下去了，更不不写需求文档，或者只是简单书写大体功能点。
2、项目进度紧张，后期需求变动可能比较大，来不及书写详细的需求文档
3、项目是从原有项目上进行迭代开发，开发人员认为不要再进行需求文档编写。
针对上述2点提出个人意见：
对于第一种情况：
1、测试负责人应该坚持开发没出需求文档，不进行测试，要坚持让开发输出项目需求文档，哪怕是写的不够详细也好。
2、需求文档要进行评审，评审做会议记录，并有专门人员对需求文档进行修改
3、后是测试人员进行测试需求分析，再根据测试需求点进行测试用例编写了。
对于第二种和第三种情况：
1、测试人员尽量找到已存在的资料，比如市场调研书，可行性分析报告，收集一切对项目有用的文档。并提出其中的功能点需求
2、如果是迭代项目开发，则找到前期项目的一些需求文档，概要设计，详细设计，测试需求，用例等。提起里面的功能点
3、咨询相关人员，获取项目一些大体功能，好能知道大体项目的框架，然后记录咨询到的功能点。
4、了解项目大体框架后，可以在网上寻找同类产品，把里面的一些亮点功能点进行提起
5、整合上面的几点，测试人员应该书写一份你认为的测试需求点，然后分发给每个和项目有关人员，如测试人员，开发人员，市场人员。组织进行一个会议评审，在评审中详细记录修改的地方
6、后整理出一份评审过的测试需求点，进行设计测试用例。
没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例能多写点。
一般碰到没有需求说明的情况是发起者不了解测试需要相关的文档，我是将该测试需求退回发起者。假如对方因项目紧急说先测再补充文档，那我可以先进行。
进行的步骤如下：
1、要求发起者对测试需求进行口述测试点及注意事项。
2、由口述获取到的信息编制测试流程，注意，这里是测试流程不是测试用例，假如对方无法提供具体的比如某个输入域的字段长度或者类型，那所谓的边界值等价类无法运用了。
3、凭经验测试。凭借着对项目的理解，对同行业相关软件的认识等进行。
总结，楼主发的这个主题我个人感觉主要会发生在测试管理流程规范没到位或者发起者不是相关的项目组成员，比如某个老总或者高级别的客户，突然找到测试人员要测试人员进行某某测试。我个人认为这都是属于越权。再紧急的任务，如果目的不是走过场，而是要获得比较准确可靠的测试结果，那要提供相关的说明，即使是小功能点，也要告知（口述、内部论坛、即时通、简单邮件等途径）用途、设计时的安排等事项。
另外还有种情况是发起者与测试人员都是项目组中的老成员了，非常熟悉项目功能，这时确实可以先省略需求文档然后再补充。
注：我这边一般获取测试任务时发起者都会些测试需求说明书，测试要点说明等。可能与楼主单纯的那种项目需求文档会有些出入。
假如是项目需求说明书那也不能进行测试用例设计的，我们知道这是需求详细设计说明书或者数据库设计等相关文档，所以我对‘没有需求文档’的理解是没有测试需求说明书。
这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？
以前我们公司招测试Leader的面试题目中也有类似的一个题目？我面试了很多人，回答都不是很理想，都只能够回答上几句话，并且都有“需求不明确”等同感，只是工作中太忙缺少总结，给出一个常见的很熟悉的问题，马上作答不知道如何说起。
下面是我的一些看法，恳请各位同行批评指正：
1.根据客户的功能点整理测试需求追朔表：
一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个重要的依据。
2.根据开发人员的Software Specification List整理我们的功能测试点：
一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。
3.开展项目跨部门讨论会：
可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。
4.测试人员整理用例需求疑问递交项目组和客户代表回复：
测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。
5.项目内部用例评审：
测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。
6.邮件和客户代表确认部分争议问题：
测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。后编写测试用例的时候，以客户的邮件内容为准。
7.项目Demo和部分已开发系统：
大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。
8.参考同行业和竞争对手的类似产品：
假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China?pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。
9.交叉模块的测试，容易被人忽略：
一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。
10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。
我以前的团队中主要使用这些方法，如果大家有什么好的方法，请大家补充，完善！！
需求的不确定会导致软件设计过程中的风险过大。千万不要一上来动手写case。
那么一方面需要让客户或PM（具体情况视工作流程而定）给出尽可能多的信息。包括截图，客户的使用场景，预期的数据量等等。而且可以通过email/yahoo/photo等方式尽可能的获取你所需要的信息。总之一句话，有什么要什么。
另一方面要通过与Dev的沟通来确定客户的需求大概可能会是怎样的，那我们应该如何实现，往往code设计决定了测试，以及如何进行测试。测试策略是什么如否应该进行性能测试，测试关键点和难度是什么等等。在条件允许的情况下可以广纳建议结合QA对产品的熟悉基础上进行的想法（这种情况下要求QA有一定的想像力）来终确定客户一个比较粗的框架需求。对于那些很细节或者说虽功能性的问题如UI设计等等，可以暂时不要考虑，也没这个必要。
接下来要做的是搭建一个主要的功能点框架，类似于写文章时的提纲。再往往这个框架里填东西。在需求没有得到进一步确认之前，千万记住此时QA的主要工作应该只是写框架，而不是写具体到哪个button放在哪个位置。即使写的很详细，一旦客户需求产生变化，那么有可能之前写的case得推倒重写。既浪费了时间，又浪费了精力，你的工作也变得徒劳了。过渡的折磨自己去写有可能无用的case，还不如聪明的学会适当偷懒放松自己。当然这是针对大方向的需求不确定的情况。对于那种小需求改动的情况另当别论。在没有进一步的需求信息之前，case设计基本到此为止了。
以上是我个人的一些想法和意见，大家仁者见仁，智者见智吧。
我纳闷了，如果没有需求文档，那后面的工作要如何开展哦，如果后面的工作可以开展，那么肯定需要参照什么文档，或是从客户那里收集到的原始需求。
另外我们可以根据这些文档或是原始需求来制定测试计划，写测试用例，当然过程中肯定会有不清楚或是不详细的地方，这时候我们需要与客户沟通，直至弄清楚为止。
但是我们弄清楚了，可开发人员是不是也弄清楚了呢？看来还需要与开发人员进行深入交流，使大家对于客户的需求达到一致。
