没有需求文档的时候如何来设计测试用例？（08-06-20）（获奖名单已公布）
测试用例应该依照需求文档来开发，但是我们的项目根本就没有需求文档？那测试用例该如何开发呢？
[color=#0000ff]感谢会员[/color]水印无痕[color=#0000ff]提供此精彩问题！如果你也有问题想提出来和大家一起讨论，[/color][url=http://bbs.51testing.com/thread-129915-1-1.html][color=red]请点击此处>>[/color][/url]
[color=#0000ff]说不定下期讨论的问题就是由你提出的哦，请快快参与吧！[/color]
非常感谢各位会员积极参与，截止至6月27日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
[table=371][tr][td=4,1,371][align=center][font=宋体][size=2][color=#ff0000]获奖名单[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#0000ff]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]获奖名单[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]奖励[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#0000ff]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2]一等奖[/size][/font][/align][/td][td][align=center][font=宋体][size=2]zhuzx[/size][/font][/align][/td][td][align=center][font=宋体][size=2]当当购物卡50元[/size][/font][/align][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=1#pid1000420][font=宋体][size=2]12#[/size][/font][/url][/size][/font][/align][/td][/tr][tr][td=1,2][align=center][font=宋体][size=2]二等奖[/size][/font][/align][/td][td=1,1,98][align=center][font=宋体][size=2]love笨笨[/size][/font][/align][/td][td=1,2][align=center][font=宋体][size=2]300论坛积分[/size][/font][/align][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=1#pid1000013][font=宋体][size=2]7#[/size][/font][/url][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2]hjjlearning[/size][/font][/align][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=1#pid1000093][font=宋体][size=2]8#[/size][/font][/url][/size][/font][/align][/td][/tr][tr][td=1,3][align=center][font=宋体][size=2]三等奖[/size][/font][/align][/td][td][align=center][font=宋体][size=2]testman[/size][/font][/align][/td][td=1,3][align=center][size=2][font=宋体]100论坛积分
[/align][/font][/size][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=2#pid1002083][font=宋体][size=2]21#[/size][/font][/url][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2]goal1860[/size][/font][/align][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=2#pid1002255][font=宋体][size=2]23#[/size][/font][/url][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2]江南飞雪[/size][/font][/align][/td][td][align=center][font=宋体][size=2][url=http://bbs.51testing.com/viewthread.php?tid=118112&page=2#pid1002835][font=宋体][size=2]27#[/size][/font][/url][/size][/font][/align][/td][/tr][/table]
回复 1# 的帖子
我也常常碰到这样的问题，我的经验是跟系统开发人员多沟通以便了解到他们的开发流程、思路、注意细节等等，用笔记下来（俗话说“好记性不如烂笔头”嘛），理顺思路，然后再运用设计测试用例的等价类划分、边界值分析等方法对照系统各模块进行设计！ 沟通与经验通常是解决她的好办法 没有文档对于单元测试来说也是一个难题，弄不好会使测试毫无意义。前段时间，我收到用户反馈说，单元测试的效果不好，经了解，情形是这样的：没有详细设计文档，由测试部门做单元测试，由于没有文档，测试员只好读代码来判断程序功能，预期输出是读代码后自已算出来的，结果效果不好。例如：
int func(int a, int b){return a-b;};
本来是计算两个数的和的，结果程序员将加号写成了减号。
测试时，如果有文档，哪怕是很简单的写一句：返回两个数的和，那么，测试员就可以这样设计用例：输入两个1,判断返回值是不是2，马上就能发现错误，但由于没有文档，测试员不知道代码的设计功能，根据代码，自己算出一个输出：0，这种测试基本上就没有意义了。
我们推荐的解决办法有：
办法一：由开发部门补充文档，可以不要求太正规，只要让测试员想得清楚：什么输入应该产生什么输出就OK了。
办法二：测试员只是设定用例的输入，输出全部设为FALSE，然后由开发部门设定输出。
办法三：由开发部门做基本功能测试，测试部门补充用例。由于已有基本用例，测试员根据现有用例就可以判断程序功能。
办法四：程序员编码时，边开发边测试代码的基本功能，测试部门只是补充用例。与办法三的区别是：办法三是事后测试，办法四是测试驱动开发。
越是排在后面的办法，推荐指数越高。如果这些全部做不到，那我的最后建议是：重新考虑测试是否值得。
[[i] 本帖最后由 VisualUnit 于 2008-6-22 10:40 编辑 [/i]] 1、要求项目组提供测试特性；
2、如果项目组由于各种因素不能提供，则要测试人员自己写测试特性。
3、组织评审，要求对模块熟悉的人员（项目经理、需求、开发）参加。
4、根据测试特性，写测试点，再组织评审。
……
总之，开始一项工作之前，一定要问清楚是什么，完成标准是什么。测试工作的血泪史告诉我们：如果这时讲义气，后面就要遭殃了。 多与用户沟通,同时了解开发的过程文档和资料.通过参加评审会以及相关的文档资料了解项目.尽而有目的的进行测试. 答题的人还不多嘛，我来抛个砖！
这应该是一个非常普遍的问题，目前很多公司的现状就是这样！
没有需求文档，最头疼的问题就是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。下面几个步骤应该可以帮助你明确目标：
1、首先可以查找其他相关文档。比如产品策划书、Feature List，不可能什么文档都没有吧。我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
2、尽量多参加该项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，尽管没有白纸黑字的文档，但讨论过程中也能让你加深对产品的理解。
3、咨询相关人员。经过以上两个过程，应该对产品有了一个初步的理解，花点时间自己把大致的功能点整理一下，遇到不明确的、有疑问的，可以咨询项目负责人或者相关市场人员，他们应该对整个产品心中有数，否则这个产品真的就没法做下去了。这里有一个前提是，在对产品有了初步了解后，才有针对性的去咨询，否则在什么都不知道的情况下，第一，对方没有耐心和时间向你介绍整个产品；第二，对于对方的讲解，估计最多也只能了解个大概，不能很好理解。
4、使用旧版本。如果当前开发的产品是以前做过产品的升级版，或者和以前某个项目类似，这样就最好了，有个实实在在的“demo”给你用，当然理解也更深入了。
5、召集相关人员，对你整理的结果进行讨论。整理以上几步得出的结论，总结成文档，发给相关人员，包括项目负责人、市场部代表、开发人员等，让他们帮助评审check，根据意见对文档不断进行补充完善。当最后通过评审后，这个文档就可以当作依据来设计你的测试用例了。 这里写出我的一点意见。
从做测试过程中发现，一般没有需求说明文档有3种情况
1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务就分配下去了，更不就不写需求文档，或者只是简单书写大体功能点。
2、项目进度紧张，后期需求变动可能比较大，来不及书写详细的需求文档
3、项目是从原有项目上进行迭代开发，开发人员认为不要再进行需求文档编写。
针对上述2点提出个人意见：
对于第一种情况：
1、测试负责人应该坚持开发没出需求文档，就不进行测试，要坚持让开发输出项目需求文档，哪怕是写的不够详细也好。
2、需求文档要进行评审，评审做会议记录，并有专门人员对需求文档进行修改
3、最后就是测试人员进行测试需求分析，再根据测试需求点进行测试用例编写了。
对于第二种和第三种情况：
1、测试人员尽量找到已存在的资料，比如市场调研书，可行性分析报告，收集一切对项目有用的文档。并提出其中的功能点需求
2、如果是迭代项目开发，则找到前期项目的一些需求文档，概要设计，详细设计，测试需求，用例等。提起里面的功能点
3、咨询相关人员，获取项目一些大体功能，最好能知道大体项目的框架，然后记录咨询到的功能点。
4、了解项目大体框架后，可以在网上寻找同类产品，把里面的一些亮点功能点进行提起
5、整合上面的几点，测试人员应该书写一份你认为的测试需求点，然后分发给每个和项目有关人员，如测试人员，开发人员，市场人员。组织进行一个会议评审，在评审中详细记录修改的地方
6、最后整理出一份评审过的测试需求点，进行设计测试用例。
没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例就能多写点。
欢迎访问我的BLOG：[url]http://www.51testing.com/?18049[/url]
[[i] 本帖最后由 hjjlearning 于 2008-6-27 19:42 编辑 [/i]] 一般碰到没有需求说明的情况是发起者不了解测试需要相关的文档，我是将该测试需求退回发起者。假如对方因项目紧急说先测再补充文档，那我可以先进行。
进行的步骤如下：
1、要求发起者对测试需求进行口述测试点及注意事项。
2、由口述获取到的信息编制测试流程，注意，这里是测试流程不是测试用例，假如对方无法提供具体的比如某个输入域的字段长度或者类型，那所谓的边界值等价类就无法运用了。
3、凭经验测试。凭借着对项目的理解，对同行业相关软件的认识等进行。
总结，楼主发的这个主题我个人感觉主要会发生在测试管理流程规范没到位或者发起者不是相关的项目组成员，比如某个老总或者高级别的客户，突然找到测试人员要测试人员进行某某测试。我个人认为这都是属于越权。再紧急的任务，如果目的不是走过场，而是要获得比较准确可靠的测试结果，那就要提供相关的说明，即使是小功能点，也要告知（口述、内部论坛、即时通、简单邮件等途径）用途、设计时的安排等事项。
另外还有种情况是发起者与测试人员都是项目组中的老成员了，非常熟悉项目功能，这时确实可以先省略需求文档然后再补充。
注：我这边一般获取测试任务时发起者都会些测试需求说明书，测试要点说明等。可能与楼主单纯的那种项目需求文档会有些出入。
假如是项目需求说明书那也不能进行测试用例设计的，我们知道这是需求详细设计说明书或者数据库设计等相关文档，所以我对‘没有需求文档’的理解是没有测试需求说明书。 一.上报'没有需求文档将无法进行测试用例设计'的事实给高层管理者(练口才的时候到了),引起他们的重视,让他们尽可能推动开发组或产品组完成需求文档;
二.高层都推动不了的时候,那么先说明测试组可以开始写测试用例(总不能罢工吧:)), 但是责任要划清:完成的测试用例会召集各方人员参加评审,包括开发组/产品组等等的相关人(最好由高层推动其全部到场),当场记录评审意见,根据评审意见修订完成的测试用例即为最终版本,纳入基线;后期又由开发或产品组提出的变更,将执行严格的变更流程,并且把变更情况上报给高层管理者; 个人意见：
1.多和开发人员、项目经历、市场人员沟通交流
2.在开发的时候应该有详细设计吧，可以根据这个写test case
3.既然没有需求，那功能点应该是都齐全吧，那就根据开发根据开发人员的思路设计 test case(违背常理，但是没有办法的)
我以前的团队中的做法，仅供参考
这个问题出题很新颖，着重是考察公司的测试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等网络聊天工具咨询部分需求：
我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。
我以前的团队中主要使用这些方法，如果大家有什么好的方法，请大家补充，完善！！
zhuzx楼主，你太强了
看了你2期题目的答题情况，真是受益匪浅，论坛中答题不能没有你？？呵呵！！继续加油加油，帮助我们这些新手吧！！唉，我什么时候能够变成强人呢？
看到楼主们回答得都这么好，我真的很惭愧，什么时候能够变成强人呢？？不过很感谢51Testing，有了这样一个平台，我成长也很快。 需求的不确定会导致软件设计过程中的风险过大。千万不要一上来就动手写case。
那么一方面就需要让客户或PM（具体情况视工作流程而定）给出尽可能多的信息。包括截图，客户的使用场景，预期的数据量等等。而且可以通过email/yahoo/photo等方式尽可能的获取你所需要的信息。总之一句话，有什么要什么。
另一方面就要通过与Dev的沟通来确定客户的需求大概可能会是怎样的，那我们应该如何实现，往往code设计决定了测试，以及如何进行测试。测试策略是什么如否应该进行性能测试，测试关键点和难度是什么等等。在条件允许的情况下可以广纳建议结合QA对产品的熟悉基础上进行的想法（这种情况下要求QA有一定的想像力）来最终确定客户一个比较粗的框架需求。对于那些很细节或者说虽功能性的问题如UI设计等等，可以暂时不要考虑，也没这个必要。
接下来要做的就是搭建一个主要的功能点框架，类似于写文章时的提纲。再往往这个框架里填东西。在需求没有得到进一步确认之前，千万记住此时QA的主要工作应该只是写框架，而不是写具体到哪个button放在哪个位置。即使写的很详细，一旦客户需求产生变化，那么有可能之前写的case就得推倒重写。既浪费了时间，又浪费了精力，你的工作也就变得徒劳了。过渡的折磨自己去写有可能无用的case，还不如聪明的学会适当偷懒放松自己。当然这是针对大方向的需求不确定的情况。对于那种小需求改动的情况另当别论。在没有进一步的需求信息之前，case设计基本到此为止了。
以上是我个人的一些想法和意见，大家仁者见仁，智者见智吧。我看楼主也没有一个标准的答案。如有说的不对的地方，欢迎指正。 我们公司也是经常没有需求文档,等开发接近尾声了,才通知我们,可以准备测试了.
通常是,我们一边操作系统,熟悉系统,然后写测试用例,
遇到什么问题,问开发人员,或者请开发人员跟我们说明系统流程.
这样做,往往会导致系统单元测试,做得不全面. 没有需求文档的时候，我们是通过产品的介绍文档，help文档进行产品熟悉，然后对重要的，或者是版本新添的内容进行测试。
其实这个题目会有点歧义，就是需求文档时现在还没有，还是就根本没有这个东西。如果现在没有，那么我们在寻求产品目标，设计源头等的过程应该就是在形成需求文档了。或者和客户沟通，把内容记录到需求文档中。如果要是根本没有这个东西，我们也不能通过一些途径自己完成这个类似的文档，那么我们只能遵照测试的基本概念，关于那个不该有的功能不能有，该有的功能不能缺，没提到的功能不能有等等。最简单，但是最有效。而这个东西，说明书或者help文档应该是最明确的介绍了。 支持7#,他写的和我们的实际情况有些相似,处理方式也有些相似;
没有需求文档的时候,一定要和用户经常沟通,这个过程中有个引导用户的过程.比如界面应该是怎样的,处理过程是怎样的.等等细节.当然了在和用户沟通的过程一定是对系统宏观有了初步了解为前提的,然后对细节进行引导.
其次,收集资料就象楼上所说,没有需求文档,一定有和项目相关的其他文档,收集尽可能多的相关资料并了解它;
开发设计的过程中,对于缺少需求文档时可能采取原型法开发,此时我们就需要和开发人员进行有效的沟通,对于已经开发的界面,我们可以在进行测试计划后进行测试用例的编写,功能和流程方面还是主要以开发现有的资料以及开发的模型为主;
需求随着项目的进度会不断的完善,我们的测试用例也会不端的完善,系统也会不断的完善.等项目后期,我们的用例还是完善的.等系统测试或者验收测试的时候,用例启到重要作用! 没有需求文档时
我们当初的做法
1.通过质量管理，或者上级部门协商让开发人员补一份简易的需求；
2.参照之前所有相关会议（项目周会，立项会议），其他相关文档（立项方案，设计文档等），列出测试点；
3.最重要的是 ，做出测试用例文档后，需要开发人员进行评审，划定基线；
4.注意测试用例描述是，要便于跟踪变更。因为需求不确定的项目，变更是最容易发生的。
个人见解。。 我就纳闷了，如果没有需求文档，那后面的工作要如何开展哦，如果后面的工作可以开展，那么肯定需要参照什么文档，或是从客户那里收集到的原始需求。
另外我们可以根据这些文档或是原始需求来制定测试计划，写测试用例，当然过程中肯定会有不清楚或是不详细的地方，这时候我们就需要与客户沟通，直至弄清楚为止。
但是我们弄清楚了，可开发人员是不是也弄清楚了呢？看来还需要与开发人员进行深入交流，使大家对于客户的需求达到一致。
这过程中我们要尽量避免想当然的思维方式。
请大家指教……:handshake [align=center][b]忘掉需求，才能写出好的用例[/b][/align]
为什么没有了需求文档，就测试不了了呢？
即使有了需求文档，它是否可以详细到了写测试用例的地步？
需求不断的变化，用户都不清楚自己要什么，你怎么以需求为依据？
以需求为依据，完全就是教科书的理论。现实与理论是，相差是很远的。
需求文档给与我们的，是最根本，但也是最粗狂的纲领，这个纲领对于测试用例而言，并没有多少实际意义。
测试需要的并不是“需求”，而是一个依据。依据从何而来？
我们可以从各种途径来获取这些依据：
1，一切相关的文档，只要你可以得到的，都可以作为参考。需求文档只是这些文档中的一部分。
2，一切相关的人，积极和各种相关的人进行各个层次的交流，获取我们所需要的信息。
3，最主要的依据，是你自己的知识，经验。包括：
1，对计算机，软件，编程等的理解；
2，对业务知识的掌握；
3，对行业用户行为的熟悉；
4，对测试基本技能的掌握；
需求文档，并不能成为设计用例的唯一依据。
设计测试用例，往往取决于你知识和经验的广度和深度。
补充一点自己的经验：
[b]“没有需求文档如何设计测试用例”这个问题，换个思路考虑的化，其实就是在讨论，没有需求文档的情况下，如何了解熟悉系统。[/b]
实际工作中，我们大多数测试的系统，都不是全新的，没有任何积累的系统。我们测试的系统，往往是公司的历史产品，或项目的升级，这些系统公司多多少少是有些历史资料的，包括以前的需求，设计，测试方案，甚至是Bug记录等，这些东西可以一定程度上帮助我们了解系统。
对于全新开发的系统基本上不可能没有需求的，即使没有需求，它一定有概要设计等文档，我们可以从这些有限的文档中获取一些信息。
文档都是死的东西，最主要的应该是和相关人的交流，和自己的水平。
具体到如需求和测试用例的问题上来，大家可以考虑一下，[b]自己写的测试用例的粒度如何？[/b]
为什么要考虑这个问题？实际工作中，大家写的用例都是很粗的。特别是项目前期如果根据需求写的化，我见过很多人写的测试用例无非是把需求的照抄一下，简单说一下功能是什么。需求本来就写的粗的没有太多价值了，我们在把需求摘抄一下，那就更粗的不行了。试问，这样的测试用例有何价值？？
[b]很多人强调需求，其实际是在讨论责任。无非是出了问题，找个替死鬼而已。[/b]这样说有点重了，但这是真实感受。很多测试人员整天抱怨需求不好，无非是给自己找个理由，找个台阶…………
还是那句话：[b]以需求为依据，完全就是教科书的理论。现实与理论是，相差是很远的。[/b]
我们要清醒的认识到，现在国内，没有多少公司的需求可以详细到写测试用例的地步。而且，需求不明确，需求变化快，没有需求追溯……需求有着太多太多的问题。我们不要奢望通过需求来写测试用例。
强调需求，抱怨需求的人，往往是刚刚工作时间不长的新人。刚刚工作时，我也经常的抱怨。随着工作的深入，需求现在对我的影响越来越有限了。在我的眼中，从测试用例的角度来说，需求变的也越来越不重要了。
[[i] 本帖最后由 testman 于 2008-6-26 19:40 编辑 [/i]] 我们公司研发产品，每一个产品是在上一个产品的基础上添加新特性。所以即使没有需求文档，测试还是可以进行。
对于新特性，我认为最重要的是沟通，与开发人员，与市场销售（我们无法接触客户）等等。
请大家指教了，我是家小公司的测试～呵呵 这是一个很有意思的话题，也是我们日常软件测试当中经常遇到的问题。
个人愚见，解决方法就是采用各种手段获取所需信息。咋一听是废话，但这是我们所有能做的。软件测试人员是面向最终任务的，他们不应该是机器，当输入条件不被现实给出的时候就不能进一步处理，下面罗列一些个人经验：
1。与客户或客户代表沟通
这是一种比较理想的情况，即还能联系到客户或熟知产品的客户代表，并且他们也乐于合作。客户是所有需求的源，所以即便所有文档缺失，需求依旧在他们的脑子里。假如因日久产生淡忘就需要测试人员做更多的沟通，要循循善诱。从技巧上来说，最好是先获取高级需求（或者说抽象需求），然后逐步涉及一些细节。实在想不起来的我们还有测试件本身作为有力的参考。为了提高客户的合作度，软件公司管理层应当从中进行适当的协调工作。补充一句，对于这样零散收集到的信息如何组织，整理，高效确认本身是一个需要技巧的工作，在此略过。
2。产品本身
产品本身也是很好的需求来源，测试人员应当第一时间安装并运行你的测试对象。被测软件可以给出如下信息：
1〉产品的基本状态：是桌面应用还是web应用
2〉从执行文件和库文件大体判断它支持的平台：windows 系统还是unix like系统
3〉自带的文档：即便没有需求文档的软件也可能会有用户手册。当然这是很幸运的，因为用户手册有时就是变相的需求文档。还有就是readme，release notes。
4〉执行脚本：对于暴露代码的执行脚本，可以从中获取一些执行逻辑，而且它本身就是程序的一部分。值得注意的是现在脚本语言越来越多地承担起了功能实现的任务，比如perl, tcl , ruby。虽然通常它们会以打包的形式给出，但结包并不困难。走读关键的源文件可以了解整个产品的框架结构。
3。开发
开发人员，开发文档，开发的单元测试，这些都是需求信息的有效来源
4。上一版本的产品
这是个特例，但却是一个可能性颇大的特例，而且相信稍有点经验的测试人员就应该知道怎么做了。
5。常识，软件常识，领域常识，指导规范和标准
常识：界面显示要正常，结果要符合常理，2+2=5 就有可能出问题；
软件常识：界面是否响应用户操作，界面组件是否显示正常，简单正常操作是否有错误，日志是否有错误，是否能正常启动和关闭，任务栏的托盘鼠标左击或右击应该有菜单弹出，程序关闭后进程应当终止，安装目录的更改不应当影响软件的正常运行
领域常识：与业务逻辑相关，要求测试人员具备一定的应用领域知识，比如一个典型的库存管理系统应当符合惯常的进销存逻辑
指导规范（guideline）是非强制的，但会在整个软件产品当中得到体现，比方说windows窗口右上角的叉应该是关闭，假如点击后最小化了很可能有问题
标准：与上类似，但更为强制要求遵循
信息的来源有很多，有些需要测试人员发挥主观能动才能想到。但无论如何只要你能触及的就不应该是不可测的，当然信息越全面测试就可以更深入。就想到这些，愿为引玉之砖 最近太忙，没怎么来关心，呵呵
这里也浅谈下个人感想。
首先，没有文档的测试工作不应该提倡，尤其是需求文档！
没了客户/用户的需求，何来测试需求依据？到时对方说没有测试到位，彼此双方弄僵，却还是理不顺，说不清。如果有时间，建议还是让对方补个需求文档先。或者，根据提交的测试版本，我方人性化服务为他们制作一份需求文档（测试需求文档），给对方看，这样，省了他们时间后，只需要他们基本通过即可（毕竟本身就是他们没有文档在先，算不是很正规的客户吧－。－）
再者说，如果真没有文档还是不得不进行测试工作的话，设计用例唯有靠多年积累的经验和个人职业素养了。
为什么这么说？经验是你编写用例的保障前提。通过对其他系统测试的积累，这个没有需求文档的系统也一样视作有“文档”的系统。根据自己对于系统的理解，逐个功能模块和分支进行编写用例。这里，时间有空余的话，尽量做全局系统功能测试，把每个功能点都测到位。再最后提交测试结果时，可以很充分的揭露整个系统的缺陷不足，而不必担心哪个点未涉及。
为什么又说依靠个人素养？那是因为没有需求文档的用例设计其实给了你更大的工作灵活性。没有人强迫你必须把整个系统所有模块都编写测试用例，都仅凭你个人想法了。所以，一个有职业素养的测试人员，他会当作一次全部功能点都要进行测试来做工作，虽然这并不是他的工作计划或指标。
最后，我再次重申。如果时间、计划、进度允许，在跟客户有效沟通后，还是最好能够出一个需求文档，哪怕最简单不过的文档，也是一个工作的依据。否则，即便您经验再丰富、职业素养绝对高，也奈何不了最后客户的一句话：“测的什么呀，我们要测的功能都没做到嘛！？……”请别发火，也不要郁闷，记住，客户永远是上帝……有空反省，还是让他们补文档先:Q 1、和研发人员多多沟通，可以请研发的负责人讲解一下产品；
2、列出主要模块和功能点，先把主要模块和主要的功能写出来发给研发，请他们看一下，有问题回复；
3、列出编写测试用例过程中遇到的问题，请研发同事回答；
4、一些关于数据项的用例可以用一些业界或公司的标准来写，举个简单的例子：如密码，电话号码，界面之类；
5、可以请研发做一个简单的产品页面，用于参考；
6、如果可以单元测试的话（现在单元测试通常是由研发来做的），可以一个模块一个模块的写，研发做一个模块，测试人员写一个模块；
7、遇到有分歧的问题，可以和市场或产品部的同事共同研究一下；
8、业务领域部分一定要多多了解，询问甚至开会讨论；
9、模块之间的接口、逻辑关系要详细了解。
最后说一点，记得提交风险报告。
没有需求文档,我们可以通过积累和搜集,了解需求,才能设计好用例!
[color=DarkOrchid][size=4]首先理解该两个概念:什么是软件需求?
EEE软件工程标准词汇表(1997年)中定义需求为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
什么是测试用例?
测试试用例是用来测试软件系统的功能及性能的一系列输入，操作，输出和预期结果;
而需求文档只不过是用户,开发人员,实施人员用于记录软件所需的文档;
所以:
1.首先,没有需求文档,我们可以先了解软件是用来做什么的,是关于哪方面的业务知识?
之前我们有没有做过这方面的测试工作和测试文档记录,测试用例的存档?
先问多自己多几个问题,带着自己的问题可以请教有关的人员,
比如客户,有关的操作人员,开发人员的思路和数据的走向,
总之尽自己的能力搜索自己想要的有关问题或者知识;
也可以通过网络找到业务方面的知识;
2.其次,根据自己的测试经验,可从边界测试用例入手,
比较常出现问题的地方再测试一些大约相同的用例进行重复测试;
3.测试用例编写的原则一定要自己心中有数,了解软件的整体框架,业务知识的积累,
还有用户经常操作的地方要多设计几个用例,并了解用户操作的一般习性;
4.总之,测试用例编写没有需求文档,可通过自己的积累和搜集资料进行一些需求了解,
进而设计一些切合实际的用例,对测试是有很大的帮助;
以上只是个人的一些看法,如写得不好,望指点!并希望:大家在测试中能找到自己的位置![/size][/color]
[[i] 本帖最后由 fengyun32 于 2008-6-26 11:54 编辑 [/i]] 我觉的要做两件事
第一：向研发经理、上级领导提出问题，分析没有需求的坏处（其实大家心里都清楚），建议逐步完善。没有需求文档，其实这个问题很严重，并不是说让这样的情况一直恶化下去。我们公司现在的情况就这样，这样的后果就是开发人员开发完提交测试，好，发现的很多问题，改，一直矢循环。如果我们把BUG扼杀在萌芽状态，我想这不仅是开发人员、测试人员工作量减少的问题，对于公司来说也是节省了很大的一笔开支。当然，目前我的努力的结果也不是说太好，但总是在进步！第二：事实已经这样了，而且时间上也是来不及了，我们应该从现在的情况入手，来开展我们的工作。我经常是程序都写好了，再写用例，结合一些常识、业务知识、类似系统参考等做为补充。其实在这个时候你会发现，你是很痛苦的，因为开发人员有可能是“先做后想”，有些东西因为没想好，需求不明确，所谓的BUG可想而知！
都说“三思而后行”，为什么不把我们的工作在动手之前想好呢？而是造成不良的局面的时候再去收拾？当然事实已如此，不能再怨天尤人！而应积极面对！当然我目前的主要工作就是要调整好自己的心态。如何去做的更好！:lol 关于这个问题，我想先提另一个问题，什么情况下会没有需求文档，而又要设计测试用例了？
以下是我的一些经验与看法：
１，在项目开发进展的频率高且时间短的时候，一些用户模糊的需求过来，要求的功能，在有限的时间点内要求完成；
２，需求变更量大；
对于一些小型的开发项目而言，上面两种情况是经常出现的．那么在没有需求文档的时候，如何来设计测试用例？
对于第一点，跟开发与ＰＭ进行讨论，找出大概的功能点，讨论出要做什么，做成什么．可以通过做一些最基础的测试页面等给用户看，来进一步确认需求．
对于第二点，利用公共测试用例．很多功能模块都是相似的．将主要的核心东西找出来，写成公共测试用例．那些需求变更再快，也只要修改少量的用例，就可以达到效果． 首先分析没有需求文档的几种情况
1、在现有系统上升级
2、用户需求不明确，边实现边完善
3、项目紧，没有去写需求文档
但是，不论什么情况，既然有了产品，开发或设计人员就应该是对于用户需求有了相当了解及思路。就可以从其它途径去整理我们测试所需要的文档。
1、查看已有的相关项目资料，设计文档，或功能修改或开发人员，分析已有资料，尽可能去了解需求,功能点
2、与相关人员多沟通，从他们设计或开发系统的思路中去整理需求，凭已有资料及分析，对于不透彻的地方，尽可能提出疑问，再由开发人员或用户去确认
尽可能多的了解了用户的需求，整理成一些相关的测试需求的文档，经过项目组相关人员评审，再根据这些文档去写测试用例 没有需求却死去活来的还要搞清需求~我不知道为什么这样的答案能获得最佳... 谢谢大家精彩分享:victory: [quote]原帖由 [i]dabeixiong[/i] 于 2008-6-30 15:01 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1006226&ptid=118112][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
没有需求却死去活来的还要搞清需求~我不知道为什么这样的答案能获得最佳... [/quote]
因为用户的实际需求和需求文档根本就是两回事 冠军经验匪夷所思 1、和研发人员多多沟通，可以请研发的负责人讲解一下产品；
2、列出主要模块和功能点，先把主要模块和主要的功能写出来发给研发，请他们看一下，有问题回复；
3、列出编写测试用例过程中遇到的问题，请研发同事回答；
4、一些关于数据项的用例可以用一些业界或公司的标准来写，举个简单的例子：如密码，电话号码，界面之类；
5、可以请研发做一个简单的产品页面，用于参考；
6、如果可以单元测试的话（现在单元测试通常是由研发来做的），可以一个模块一个模块的写，研发做一个模块，测试人员写一个模块；
7、遇到有分歧的问题，可以和市场或产品部的同事共同研究一下；
8、业务领域部分一定要多多了解，询问甚至开会讨论；
9、模块之间的接口、逻辑关系要详细了解。
最后说一点，记得提交风险报告。
好贴就是要多看，多想！！！
好贴就是要多看，多想！！！回复 12# 的帖子
我个新手，看到您的回答真是受益匪浅啊 正在学习中求测试用例
大家好，我刚注册这里还不太了解，请各位多多指教，我们公司做威盛平台手机软件，因为我之前一直做MTK的，对VIA平台不了解，老大要我写测试用例，大家有谁有的请发给我，谢谢！[email]kate775@126.com[/email]:) :) [quote]这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？以前我们公司招测试Leader的面试题 ...
[size=2][color=#999999]zhuzx 发表于 2008-6-24 14:19[/color] [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1000420&ptid=118112][img]http://bbs.51testing.com/images/common/back.gif[/img][/url][/size][/quote]
说的太好了~我们目前也是没有需求的写测试用例，执行用例；很多情况靠自己去猜是不够的……受教受教了 我们近百人的公司竟然拿不出一套像样的测试用例，股东舍不得拿出财力物力好好整一套标准，整天忙于测试，实属悲哀。
页:
[1]
2