如果没有需求规格说明书，如何设计测试用例？

H]0BtJ I0也许你经常会听到：“测试用例应该依照需求文档来开发，但是我们的项目根本就没有需求文档？那测试用例该如何开发呢？”51Testing软件测试网bJE9^"hLx

是啊，没有SRS（Software Requirement Specification）或者PRD（Product Require Document）的话，我们的测试用例的依据又是什么呢？51Testing软件测试网3Z&D)@:hL]

看到一个网友给出了几点建议，基本把我想要说的都表达到位了，这里就偷个懒，借花献佛了：

N'^)O:xbnm;d0　　1、根据客户的功能点整理测试需求追朔表：

KUf/e$RKM0　　一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

　　2、根据开发人员的Software Specification List整理我们的功能测试点：

　　一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

　　3、开展项目跨部门讨论会：

DwUU6H.I9@Xa2v0　　可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

RI7UK\0　　4、测试人员整理用例需求疑问递交项目组和客户代表回复：

`9y3A
e/g/H,Rf0　　测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。51Testing软件测试网(CY*};R!J6n

　　5、项目内部用例评审：

　　测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。51Testing软件测试网V^:J8n?G"q

　　6、邮件和客户代表确认部分争议问题：51Testing软件测试网 b(]p3o
np3O L

　　测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

　　7、项目Demo和部分已开发系统：

:PNU,G$}p/qOmv0　　大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。51Testing软件测试网E;JzE;s

　　8、参考同行业和竞争对手的类似产品：51Testing软件测试网LCcO5l

#C OJ!{ tc.E0　　假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

7p!Fak1uX)j0d0　　9、交叉模块的测试，最容易被人忽略：

　　一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

#y6N.y4Z+H0　　10、可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：51Testing软件测试网4o`sV+^#Z3\8`

1R%@5pvy
} EP1p0　　我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。51Testing软件测试网:m
q/]3{[%n#}

 51Testing软件测试网.Y2t]y
o