没有需求文档的时候如何来设计测试用例？（08-06-20）（获奖名单已公布）

testman

忘掉需求，才能写出好的用例

为什么没有了需求文档，就测试不了了呢？
即使有了需求文档，它是否可以详细到了写测试用例的地步？
需求不断的变化，用户都不清楚自己要什么，你怎么以需求为依据？

以需求为依据，完全就是教科书的理论。现实与理论是，相差是很远的。

需求文档给与我们的，是最根本，但也是最粗狂的纲领，这个纲领对于测试用例而言，并没有多少实际意义。

测试需要的并不是“需求”，而是一个依据。依据从何而来？

我们可以从各种途径来获取这些依据：
1，一切相关的文档，只要你可以得到的，都可以作为参考。需求文档只是这些文档中的一部分。
2，一切相关的人，积极和各种相关的人进行各个层次的交流，获取我们所需要的信息。
3，最主要的依据，是你自己的知识，经验。包括：
             1，对计算机，软件，编程等的理解；
             2，对业务知识的掌握；
             3，对行业用户行为的熟悉；
             4，对测试基本技能的掌握；


需求文档，并不能成为设计用例的唯一依据。
设计测试用例，往往取决于你知识和经验的广度和深度。


补充一点自己的经验：

“没有需求文档如何设计测试用例”这个问题，换个思路考虑的化，其实就是在讨论，没有需求文档的情况下，如何了解熟悉系统。

实际工作中，我们大多数测试的系统，都不是全新的，没有任何积累的系统。我们测试的系统，往往是公司的历史产品，或项目的升级，这些系统公司多多少少是有些历史资料的，包括以前的需求，设计，测试方案，甚至是Bug记录等，这些东西可以一定程度上帮助我们了解系统。

对于全新开发的系统基本上不可能没有需求的，即使没有需求，它一定有概要设计等文档，我们可以从这些有限的文档中获取一些信息。

文档都是死的东西，最主要的应该是和相关人的交流，和自己的水平。

具体到如需求和测试用例的问题上来，大家可以考虑一下，自己写的测试用例的粒度如何？

为什么要考虑这个问题？实际工作中，大家写的用例都是很粗的。特别是项目前期如果根据需求写的化，我见过很多人写的测试用例无非是把需求的照抄一下，简单说一下功能是什么。需求本来就写的粗的没有太多价值了，我们在把需求摘抄一下，那就更粗的不行了。试问，这样的测试用例有何价值？？

很多人强调需求，其实际是在讨论责任。无非是出了问题，找个替死鬼而已。这样说有点重了，但这是真实感受。很多测试人员整天抱怨需求不好，无非是给自己找个理由，找个台阶…………

还是那句话：以需求为依据，完全就是教科书的理论。现实与理论是，相差是很远的。

我们要清醒的认识到，现在国内，没有多少公司的需求可以详细到写测试用例的地步。而且，需求不明确，需求变化快，没有需求追溯……需求有着太多太多的问题。我们不要奢望通过需求来写测试用例。

强调需求，抱怨需求的人，往往是刚刚工作时间不长的新人。刚刚工作时，我也经常的抱怨。随着工作的深入，需求现在对我的影响越来越有限了。在我的眼中，从测试用例的角度来说，需求变的也越来越不重要了。

[ 本帖最后由 testman 于 2008-6-26 19:40 编辑 ]

poi0110

我们公司研发产品，每一个产品是在上一个产品的基础上添加新特性。所以即使没有需求文档，测试还是可以进行。
对于新特性，我认为最重要的是沟通，与开发人员，与市场销售（我们无法接触客户）等等。

请大家指教了，我是家小公司的测试～呵呵

goal1860

这是一个很有意思的话题，也是我们日常软件测试当中经常遇到的问题。
个人愚见，解决方法就是采用各种手段获取所需信息。咋一听是废话，但这是我们所有能做的。软件测试人员是面向最终任务的，他们不应该是机器，当输入条件不被现实给出的时候就不能进一步处理，下面罗列一些个人经验：
1。与客户或客户代表沟通
  这是一种比较理想的情况，即还能联系到客户或熟知产品的客户代表，并且他们也乐于合作。客户是所有需求的源，所以即便所有文档缺失，需求依旧在他们的脑子里。假如因日久产生淡忘就需要测试人员做更多的沟通，要循循善诱。从技巧上来说，最好是先获取高级需求（或者说抽象需求），然后逐步涉及一些细节。实在想不起来的我们还有测试件本身作为有力的参考。为了提高客户的合作度，软件公司管理层应当从中进行适当的协调工作。补充一句，对于这样零散收集到的信息如何组织，整理，高效确认本身是一个需要技巧的工作，在此略过。

2。产品本身
  产品本身也是很好的需求来源，测试人员应当第一时间安装并运行你的测试对象。被测软件可以给出如下信息：
1〉产品的基本状态：是桌面应用还是web应用
2〉从执行文件和库文件大体判断它支持的平台：windows 系统还是unix like系统
3〉自带的文档：即便没有需求文档的软件也可能会有用户手册。当然这是很幸运的，因为用户手册有时就是变相的需求文档。还有就是readme，release notes。
4〉执行脚本：对于暴露代码的执行脚本，可以从中获取一些执行逻辑，而且它本身就是程序的一部分。值得注意的是现在脚本语言越来越多地承担起了功能实现的任务，比如perl, tcl , ruby。虽然通常它们会以打包的形式给出，但结包并不困难。走读关键的源文件可以了解整个产品的框架结构。

3。开发
    开发人员，开发文档，开发的单元测试，这些都是需求信息的有效来源

4。上一版本的产品
    这是个特例，但却是一个可能性颇大的特例，而且相信稍有点经验的测试人员就应该知道怎么做了。

5。常识，软件常识，领域常识，指导规范和标准
    常识：界面显示要正常，结果要符合常理，2+2=5 就有可能出问题；
    软件常识：界面是否响应用户操作，界面组件是否显示正常，简单正常操作是否有错误，日志是否有错误，是否能正常启动和关闭，任务栏的托盘鼠标左击或右击应该有菜单弹出，程序关闭后进程应当终止，安装目录的更改不应当影响软件的正常运行
    领域常识：与业务逻辑相关，要求测试人员具备一定的应用领域知识，比如一个典型的库存管理系统应当符合惯常的进销存逻辑
    指导规范（guideline）是非强制的，但会在整个软件产品当中得到体现，比方说windows窗口右上角的叉应该是关闭，假如点击后最小化了很可能有问题
    标准：与上类似，但更为强制要求遵循

信息的来源有很多，有些需要测试人员发挥主观能动才能想到。但无论如何只要你能触及的就不应该是不可测的，当然信息越全面测试就可以更深入。就想到这些，愿为引玉之砖

土土的豆豆

最近太忙，没怎么来关心，呵呵
这里也浅谈下个人感想。
首先，没有文档的测试工作不应该提倡，尤其是需求文档！
没了客户/用户的需求，何来测试需求依据？到时对方说没有测试到位，彼此双方弄僵，却还是理不顺，说不清。如果有时间，建议还是让对方补个需求文档先。或者，根据提交的测试版本，我方人性化服务为他们制作一份需求文档（测试需求文档），给对方看，这样，省了他们时间后，只需要他们基本通过即可（毕竟本身就是他们没有文档在先，算不是很正规的客户吧－。－）
再者说，如果真没有文档还是不得不进行测试工作的话，设计用例唯有靠多年积累的经验和个人职业素养了。
为什么这么说？经验是你编写用例的保障前提。通过对其他系统测试的积累，这个没有需求文档的系统也一样视作有“文档”的系统。根据自己对于系统的理解，逐个功能模块和分支进行编写用例。这里，时间有空余的话，尽量做全局系统功能测试，把每个功能点都测到位。再最后提交测试结果时，可以很充分的揭露整个系统的缺陷不足，而不必担心哪个点未涉及。
为什么又说依靠个人素养？那是因为没有需求文档的用例设计其实给了你更大的工作灵活性。没有人强迫你必须把整个系统所有模块都编写测试用例，都仅凭你个人想法了。所以，一个有职业素养的测试人员，他会当作一次全部功能点都要进行测试来做工作，虽然这并不是他的工作计划或指标。
最后，我再次重申。如果时间、计划、进度允许，在跟客户有效沟通后，还是最好能够出一个需求文档，哪怕最简单不过的文档，也是一个工作的依据。否则，即便您经验再丰富、职业素养绝对高，也奈何不了最后客户的一句话：“测的什么呀，我们要测的功能都没做到嘛！？……”请别发火，也不要郁闷，记住，客户永远是上帝……有空反省，还是让他们补文档先

vxiaoqiangs

1、和研发人员多多沟通，可以请研发的负责人讲解一下产品；
2、列出主要模块和功能点，先把主要模块和主要的功能写出来发给研发，请他们看一下，有问题回复；
3、列出编写测试用例过程中遇到的问题，请研发同事回答；
4、一些关于数据项的用例可以用一些业界或公司的标准来写，举个简单的例子：如密码，电话号码，界面之类；
5、可以请研发做一个简单的产品页面，用于参考；
6、如果可以单元测试的话（现在单元测试通常是由研发来做的），可以一个模块一个模块的写，研发做一个模块，测试人员写一个模块；
7、遇到有分歧的问题，可以和市场或产品部的同事共同研究一下；
8、业务领域部分一定要多多了解，询问甚至开会讨论；
9、模块之间的接口、逻辑关系要详细了解。
最后说一点，记得提交风险报告。

fengyun32

首先理解该两个概念:
什么是软件需求?
EEE软件工程标准词汇表(1997年)中定义需求为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。

什么是测试用例?
测试试用例是用来测试软件系统的功能及性能的一系列输入，操作，输出和预期结果;

而需求文档只不过是用户,开发人员,实施人员用于记录软件所需的文档;

所以:
1.首先,没有需求文档,我们可以先了解软件是用来做什么的,是关于哪方面的业务知识?
之前我们有没有做过这方面的测试工作和测试文档记录,测试用例的存档?
先问多自己多几个问题,带着自己的问题可以请教有关的人员,
比如客户,有关的操作人员,开发人员的思路和数据的走向,
总之尽自己的能力搜索自己想要的有关问题或者知识;
也可以通过网络找到业务方面的知识;

2.其次,根据自己的测试经验,可从边界测试用例入手,
比较常出现问题的地方再测试一些大约相同的用例进行重复测试;

3.测试用例编写的原则一定要自己心中有数,了解软件的整体框架,业务知识的积累,
还有用户经常操作的地方要多设计几个用例,并了解用户操作的一般习性;

4.总之,测试用例编写没有需求文档,可通过自己的积累和搜集资料进行一些需求了解,
进而设计一些切合实际的用例,对测试是有很大的帮助;

以上只是个人的一些看法,如写得不好,望指点!并希望:大家在测试中能找到自己的位置!

[ 本帖最后由 fengyun32 于 2008-6-26 11:54 编辑 ]

江南飞雪

我觉的要做两件事
第一：向研发经理、上级领导提出问题，分析没有需求的坏处（其实大家心里都清楚），建议逐步完善。没有需求文档，其实这个问题很严重，并不是说让这样的情况一直恶化下去。我们公司现在的情况就这样，这样的后果就是开发人员开发完提交测试，好，发现的很多问题，改，一直矢循环。如果我们把BUG扼杀在萌芽状态，我想这不仅是开发人员、测试人员工作量减少的问题，对于公司来说也是节省了很大的一笔开支。当然，目前我的努力的结果也不是说太好，但总是在进步！第二：事实已经这样了，而且时间上也是来不及了，我们应该从现在的情况入手，来开展我们的工作。我经常是程序都写好了，再写用例，结合一些常识、业务知识、类似系统参考等做为补充。其实在这个时候你会发现，你是很痛苦的，因为开发人员有可能是“先做后想”，有些东西因为没想好，需求不明确，所谓的BUG可想而知！
  都说“三思而后行”，为什么不把我们的工作在动手之前想好呢？而是造成不良的局面的时候再去收拾？当然事实已如此，不能再怨天尤人！而应积极面对！当然我目前的主要工作就是要调整好自己的心态。如何去做的更好！

jangjing

关于这个问题，我想先提另一个问题，什么情况下会没有需求文档，而又要设计测试用例了？
以下是我的一些经验与看法：
１，在项目开发进展的频率高且时间短的时候，一些用户模糊的需求过来，要求的功能，在有限的时间点内要求完成；
２，需求变更量大；

对于一些小型的开发项目而言，上面两种情况是经常出现的．那么在没有需求文档的时候，如何来设计测试用例？
对于第一点，跟开发与ＰＭ进行讨论，找出大概的功能点，讨论出要做什么，做成什么．可以通过做一些最基础的测试页面等给用户看，来进一步确认需求．
对于第二点，利用公共测试用例．很多功能模块都是相似的．将主要的核心东西找出来，写成公共测试用例．那些需求变更再快，也只要修改少量的用例，就可以达到效果．

橙子

首先分析没有需求文档的几种情况
1、在现有系统上升级
2、用户需求不明确，边实现边完善
3、项目紧，没有去写需求文档

但是，不论什么情况，既然有了产品，开发或设计人员就应该是对于用户需求有了相当了解及思路。就可以从其它途径去整理我们测试所需要的文档。

1、查看已有的相关项目资料，设计文档，或功能修改或开发人员，分析已有资料，尽可能去了解需求,功能点
2、与相关人员多沟通，从他们设计或开发系统的思路中去整理需求，凭已有资料及分析，对于不透彻的地方，尽可能提出疑问，再由开发人员或用户去确认

尽可能多的了解了用户的需求，整理成一些相关的测试需求的文档，经过项目组相关人员评审，再根据这些文档去写测试用例

dabeixiong

没有需求却死去活来的还要搞清需求~我不知道为什么这样的答案能获得最佳...

khm0508

谢谢大家精彩分享

水印无痕

原帖由 dabeixiong 于 2008-6-30 15:01 发表
没有需求却死去活来的还要搞清需求~我不知道为什么这样的答案能获得最佳...

因为用户的实际需求和需求文档根本就是两回事

dqar

冠军经验匪夷所思

vivian2008

1、和研发人员多多沟通，可以请研发的负责人讲解一下产品；
2、列出主要模块和功能点，先把主要模块和主要的功能写出来发给研发，请他们看一下，有问题回复；
3、列出编写测试用例过程中遇到的问题，请研发同事回答；
4、一些关于数据项的用例可以用一些业界或公司的标准来写，举个简单的例子：如密码，电话号码，界面之类；
5、可以请研发做一个简单的产品页面，用于参考；
6、如果可以单元测试的话（现在单元测试通常是由研发来做的），可以一个模块一个模块的写，研发做一个模块，测试人员写一个模块；
7、遇到有分歧的问题，可以和市场或产品部的同事共同研究一下；
8、业务领域部分一定要多多了解，询问甚至开会讨论；
9、模块之间的接口、逻辑关系要详细了解。
最后说一点，记得提交风险报告。

思渝

好贴就是要多看，多想！！！

zero_up

我个新手，看到您的回答真是受益匪浅啊

lytfh

正在学习中

胡春霞

大家好，我刚注册这里还不太了解，请各位多多指教，我们公司做威盛平台手机软件，因为我之前一直做MTK的，对VIA平台不了解，老大要我写测试用例，大家有谁有的请发给我，谢谢！kate775@126.com

moonylts

这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？
以前我们公司招测试Leader的面试题 ...
zhuzx 发表于 2008-6-24 14:19

    说的太好了~我们目前也是没有需求的写测试用例，执行用例；很多情况靠自己去猜是不够的……受教受教了

miqiangyam

我们近百人的公司竟然拿不出一套像样的测试用例，股东舍不得拿出财力物力好好整一套标准，整天忙于测试，实属悲哀。