51Testing软件测试论坛

标题: 怎样从需求中测试!! [打印本页]

作者: sun808080    时间: 2006-7-19 10:05
标题: 怎样从需求中测试!!
公司接个项目,做财政系统的"借款/还款"软件,B/S结构
只有2页纸的需求,3个程序员,小弟测试,怎么看需求写用例啊,郁闷!!
作者: 麻辣火鸡    时间: 2006-7-19 10:07
跟开发人员一起讨论分析需求,细化到开发人员能够开始设计以及编码,你也就可以编写测试用力了阿
作者: sun808080    时间: 2006-7-19 11:13
开发已经开始编码了,在网上边找边写,客户需求也变了2次,
测试就我一个,没写过计划.  用例是在什么时候出来的啊?
作者: archonwang    时间: 2006-7-19 11:23
先对需求做精细化处理。
作者: sun808080    时间: 2006-7-19 14:28
我们小公司,没什么细化的东西,有需求说明书就不错了
想知道怎么从需求里面弄出计划或用例来的
作者: harryhu    时间: 2006-7-19 15:11
原帖由 archonwang 于 2006-7-19 11:23 发表
先对需求做精细化处理。

斑竹这句话可能不队,精细化处理还是后期的,前期的需求评审以及需求确定还没有作。
作者: verve    时间: 2006-7-21 12:46
对于这样的情况,最好就是参与开发人员对需求分析的讨论.而且,这样小的团队,很容易和开发交流沟通.然后根据讨论的细化需求,设计测试用例
作者: 乖乖风信子    时间: 2006-7-21 16:50
测这种管理系统,要详细的写测试用例要花很长时间的啊,感觉比真正测试用的时候还要长啊?这样的测试用例值得一个一个去写吗?
作者: madow    时间: 2006-7-21 17:09
用例在开发人员开始写代码之前就应该开始着手了,也就是说开发人员编码前基本的需求应该已经明确了,不过有时候写需求的人可能会漏掉一些问题,这时候就需要测试人员找出这种问题并和客户沟通,这样才能把风险降到最低。

[ 本帖最后由 madow 于 2006-7-21 17:17 编辑 ]
作者: kevin_park315    时间: 2006-7-25 17:31
针对你这种情况:
1.得到客户需求文档
2.成立客户需求分析小猪(测试和开发人员)
3. 分析客户需求和提供需求的输入,这里的输入指:客户需求;你公司的需求;以前项目需求等。
4. 定义测试需求。分析之后会得到一个需求的Risk(包括需求不明确,或是技术问题等),然后和相应的人沟通决绝risk,之后定义测试需求。
5.找客户和技术人员评审测试需求。
6.把测试需求转换成测试用例。简单点就是全部覆盖测试需求。sdlkfj5

[ 本帖最后由 kevin_park315 于 2006-7-25 17:35 编辑 ]
作者: wzb521    时间: 2006-7-25 17:51
把需求贴上来,帮你分析
作者: sun808080    时间: 2006-7-26 09:49
感谢大家热情洋溢的留言,获益非浅!!  需求如下,大家指点:
财政借款管理系统
(财政资金债权管理软件)
一、        功能模块
(一)基础数据模块:分别建立借款单位、担保单位、业务部门、资金性质、还款来源等数据库,对财政借款事项实行属性挂接。
(二)录入模块:登记每一笔财政借款的具体事项。
(三)核销模块:登记每一笔财政借款的归还、冲销情况。
(四)查询模块:借款查询(分年度、分借款单位、分担保单位、分业务部门、分资金性质)、已还款查询、未还款查询。
(五)报表定制功能:万能报表设置
(六)出具催款通知书功能:提前30日借款事项显示为蓝色。打印分处室的催款通知书,借款到期仍未归还,借款事项显示为红色。
二、        基础数据
1、        借款事项的必备要素:借款单位、借款金额、借款日期、还款日期。
2、        需要与借款事项进行挂接的要素(自行选定):责任处室、担保单位、资金性质、约定还款来源等。
3、        需要进行设定的基础数据库包括:
借款单位库、单位性质库(二者要挂接)
担保单位库、业务部门库
资金性质库、借款性质库、还款来源数据库(约定还款与实际还款共用)

三、        录入

录入的基本要素        要素的选项        备注
借款单位        市级预算单位、企业、区县财政局、其他        单位库的具体内容自行定制
同时挂接单位的性质
责任处室        预算处、国库处、教科文处……        具体内容自行定制
担保单位        无担保、XX单位        单位名称自行定制(“无担保”为必须设定的事项)
借款金额        到“元”        出具报表时可按不同意(元、万元、亿元)显示
借款日期        设置日历选项        以合同签订日为准
借款期限        天、月、年        如何设置,是否为选项
归还日期                系统在保存时自动计算
是否计息        无息、有息       
资金性质        一般预算资金、政府性基金、国债转贷资金、预算外资金、其他        农村基金会借款
借款项目性质        一般性借款、专项借款、周转借款、临时性借款、以前年度借款       
约定还款来源        借款单位偿还、担保单位偿还、预算拨款冲抵、以后年度预算安排、结算扣款、其他       
借款事项说明        文字录入        主要填写合同、协议编号、主要内容、其他需要说明事项等

四、        核销(还款)
查找本次还款所对应的借款事项,可设定按时间、按单位或按处室等查询要素,以便于查找。

需要登记以下要素:
核销(还款)时登记的基本要素        要素的选项        备注
还款金额        到“元”        小于或等于借款金额
还款日期        设置日历选项        以资金实际入账日为准
实际还款来源        借款单位偿还、担保单位偿还、预算拨款冲抵、以后年度预算安排、结算扣款、其他       
               

五、        其他
1、        是否按年设账,如果按年设置账套。第一次记录以前年度借款事项时如何处理?
2、        不按月结账,以一笔借款事项全部冲销完毕为结账标志,冲销后的借款记录是否需要保留?
3、        如何统计借款笔数?是否需要统计?
作者: northdesert    时间: 2006-7-27 21:36
感觉需求很不明确,具体用例不知如何写。没有具体数据,只能先有个大概的思路。
原帖由 sun808080 于 2006-7-26 09:49 发表
(二)录入模块:登记每一笔财政借款的具体事项。

针对上面的录入模块的数据先可以根据等价类划分、边界值分析法进行设计。
作者: Lero    时间: 2006-7-28 10:49
这是大概的需求说明。
你说开发已经开始编代码了,那么他们应该有一个大致的模型。
也就是软件的框架,你对应框架和需求。
细化各个功能点
例如:基础数据
            录入模块
            核销模块
等等,这些是大的体系,
然后再分细化。
基础数据-对应的五个库-库数据的正确性
                                                各个库中的数据关联正确性
                                                读取的正确性
                                                数据计算的正确性
                                               真实数据都需要在数据库中进行对比。

等等。
然后,你还可以细化。
只要你愿意,你可以细化到不能再分。
这样,你就比较好根据这些比较具体的功能点来写用例啦。
不过,一个人写会很累的。

我不懂什么边界值和等价类分析

[ 本帖最后由 Lero 于 2006-7-28 10:51 编辑 ]
作者: sun808080    时间: 2006-7-28 15:00
只有这个需求说明,开发已经编码了,没有给什么模型!?只是用AVA Script做了几个静态界面给我,
服务器也差不多,也面大都点不开。
测试数据流的“正确性”应该在吗写用例啊,什么录入和输出结果啊?
而且是B/S结构的。
我不懂怎么用边界值、等价类划分出用例!!望指教!
“感觉需求很不明确,具体用例不知如何写。没有具体数据,只能先有个大概的思路。”我也有同感,而且微我一个人测试这个软件,
等到开发都弄好了一起砸给我,那就累死了!
作者: huangjing    时间: 2006-7-28 16:20
我做了一年多的测试,很惭愧的,没有写过测试用例,都是在程序员完成模块之后再去测试的,有不少局限性,可是我觉得测试用例似乎不太适合小公司的项目,因为本身文档不会很完善,有很多东西会有力不从心的感觉,不知道我的看法是否不对,还望高手们指教!
作者: harryhu    时间: 2006-7-29 13:00
标题: 等价类和边界值——写给Lero
原帖由 Lero 于 2006-7-28 10:49 发表
这是大概的需求说明。
你说开发已经开始编代码了,那么他们应该有一个大致的模型。
也就是软件的框架,你对应框架和需求。
细化各个功能点
例如:基础数据
            录入模块
            核销模块
等等 ...

等价类和边界值是黑和测试用例中常用的方法,还有因果图和错误推断法。这些方法在很多书上有介绍,看来Lero的阿知识面和基本功比较的差,建议多学习。你的回答中大部分是你的实际经验,有些比较空洞,有些还存在错误,建议你参加一个培训,提高自己的水平。经验+理论才能将自己提高一个层次。
你说开发已经开始编代码了,那么他们应该有一个大致的模型。这一点使你从实际工作中来的,不错。
作者: sun808080    时间: 2006-7-31 11:11
我没受过培训,自己看的,所以感觉不爽
Lero的回复很好,我觉得不空洞,在实践中实践,多谢!
书上的理论有用,但在特定环境下的实践中不一定好用。

做测试的不写用例和报告,那老板怎么知道你在干吗,考BUG数量吗?
不正规可以完善,关键在与对测试的重视程度,我现在也是小公司,但老板要求按正规的模式走,没有内容就先空着,模板要有。

在需求不是很明白,而且随时在变,模板不全(自己找全,而且统一模式),项目时间紧张(2个月左右),对数字敏感(财务软件),少人(测试1人)。。。条件下,我就不知道怎么才能根据1页需求写出有效的用例!!

不知道大家有没有同感!!有什么建议:提,有什么好方法:提
实际一点,盼回复!!
作者: lyscser    时间: 2006-7-31 11:19
做测试的不写用例和报告,那老板怎么知道你在干吗,考BUG数量吗?


不写用例那你就不要做测试,不是给老板看的
是给自己看的
作者: Nio    时间: 2006-7-31 14:21
整个项目组人员只有四个人,而要开发出这么个新产品出来,确实难为你们了,呵呵~

另外,如果在软件的功能、操作流程还不清楚的情况下就写出来的测试用例,你信么?

楼主如果是个测试新手或者说对这个软件还不熟悉, 那么最好还是等开发人员把UI都确定下来之后再写CASE,并整理需求什么的。

等软件可以成功做成安装包以后再写CASE也不迟……

说实话,这么多的功能,这么少的人员,这么短的时间,你有时间详细的去写CASE么?

写个主体的功能CASE倒是有可能……
作者: baobaoliang    时间: 2006-7-31 15:54
标题: 回复 #1 sun808080 的帖子
对需求进行详细分解
作者: henry827    时间: 2006-8-4 17:32
个人愚见,楼主可以先写一个整体的测试需求,需求只要写出要测些什么东西,然后根据测试需求来写部分案例,开始肯定案例不完善,需要在后期软件测试的时候不断补充。我们公司现在就是这样的
作者: xingfo    时间: 2006-8-7 17:30
感觉有些意见蛮有指导意见的。
作者: lindongfeng    时间: 2006-8-8 10:12
学会折分用例
  功能模块
(一)基础数据模块:分别建立借款单位、担保单位、业务部门、资金性质、还款来源等数据库,对财政借款事项实行属性挂接。

这一条就可以折分出很多用例来,
例如,新增借款单位,修改借款单位,删除借款单位,而且还要考虑借款单位外下有借款是,这个单位是不是让删除,依次类推,
每个用例具体分配一下内容。对用例进行一下细化。
作者: fantasy521    时间: 2006-8-8 11:01
呵呵,我和楼主一样,公司很小,也是一个人写用例,并且从需求开始写,但是老板对需求非常的重示,所以,我和项目负责人一起去做需求,不过还有很多不懂的地方,我现在是把模块的功能细分化,然后对每个功能再逐一的设计用例,但是我有一点不明白就是关于输入数据,对于真实的数据是找客户要,还是自已根据大概的情况自已设计
作者: ypzineihi    时间: 2006-8-9 10:33
标题: 可以自己模拟输入数据
可以自己模拟输入数据
作者: lindongfeng    时间: 2006-8-9 17:39
对于输入的数据部分,我一般采用设计通用用例来解决,通用用例对数据的所有输入情况都已经考虑进去了。
作者: dandan    时间: 2006-8-9 18:13
.......GO ON
作者: Lero    时间: 2006-8-9 18:41
呵呵,我基础的确不好,但是等价类和边界值我也知道。
只是我觉得在测试的时候非要考虑使用那种方法这样反而落了下乘。
根据经验,你其实知道那些地方该怎么测,至于具体使用到了什么方法我的确是没有去研究。
难道非要把用例上的数据,文字都归类到这些测试方法里面就表示这个用例很好了?

浑然天成、妙手偶得!
作者: eaglenan    时间: 2006-8-10 15:17
需求部分的测试方法,51testing就有个相关的英文文档,名字叫EffectiveSoftwareTesting-50SpecificWays.rar(615.78K) ,你找找,对你可以有不少帮助,
作者: harryhu    时间: 2006-8-10 15:44
原帖由 Lero 于 2006-8-9 18:41 发表
呵呵,我基础的确不好,但是等价类和边界值我也知道。
只是我觉得在测试的时候非要考虑使用那种方法这样反而落了下乘。
根据经验,你其实知道那些地方该怎么测,至于具体使用到了什么方法我的确是没有去研究。
...

难道非要把用例上的数据,文字都归类到这些测试方法里面就表示这个用例很好了?
用例不仅仅是现在用,而且以后还要用,所以当然要加上。
作者: swallow1981328    时间: 2006-8-10 15:56
开发文档经常不明确,你有这个不错了。
我们用td管理测试过程,需求基本就列出大体的程序模块,至于用例,由于没有具体内容只有等程序出来再写,按照程序员的描述和需求文档具体编写。
至于测试数据,如果与系统的业务关系非常密切的话,而且你也确实难以理解,就找客户要;如果不是太难懂或难以计算的话,就自己编好了
作者: lyh20041110    时间: 2006-8-11 09:11
我觉得,首先你应该与项目负责人及开发(也就是说整个项目组成员)共同针对客户需求进行可行性讨论与分析,并针对所收集需求及经过讨论后的 需求及时与客户沟通最好能进行签字确认,若没有进过客户认可的需求将会影响你今后测试计划及测试用例-----因需求若不确定就会随时更改,而你的整个测试计划与测试用例是完全建立在需求上的(除非你可以与客户相关人员可以及时沟通),这是测试计划与用例的依据;测试计划在需求出来后两天左右就应该出---主要介绍项目的目的、背景、测试主要内容(含优先级划分、附带系统的各个功能模块的简述)、测试方法(黑盒测试、白盒测试、压力测试、性能测试等具体方法的确定----可以是多种方式均有,也可是只以某种方式为主等,对了当然还少不了测试工具的选用-----在计划出来后就可依据需求及测试计划进行测试用例的编写---用例主要数据的来源来自于你对需求的理解----针对你所说的需求主要可以从日期、查询、金额数据输入方面入手---即:例如:归还日期是否允许大于借款日期、归还日期是否允许超过账期等设定,而金额方面则检查是否允许为负值等.......................
作者: weijiemiamia    时间: 2006-8-16 09:29
看看窗体说明书吧




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2