怎样从需求中测试!!

baobaoliang

对需求进行详细分解

henry827

个人愚见，楼主可以先写一个整体的测试需求，需求只要写出要测些什么东西，然后根据测试需求来写部分案例，开始肯定案例不完善，需要在后期软件测试的时候不断补充。我们公司现在就是这样的

xingfo

感觉有些意见蛮有指导意见的。

lindongfeng

学会折分用例
  功能模块
（一）基础数据模块：分别建立借款单位、担保单位、业务部门、资金性质、还款来源等数据库，对财政借款事项实行属性挂接。

这一条就可以折分出很多用例来，
例如，新增借款单位，修改借款单位，删除借款单位，而且还要考虑借款单位外下有借款是，这个单位是不是让删除，依次类推，
每个用例具体分配一下内容。对用例进行一下细化。

fantasy521

呵呵，我和楼主一样，公司很小，也是一个人写用例，并且从需求开始写，但是老板对需求非常的重示，所以，我和项目负责人一起去做需求，不过还有很多不懂的地方，我现在是把模块的功能细分化，然后对每个功能再逐一的设计用例，但是我有一点不明白就是关于输入数据，对于真实的数据是找客户要，还是自已根据大概的情况自已设计

ypzineihi

可以自己模拟输入数据

lindongfeng

对于输入的数据部分，我一般采用设计通用用例来解决，通用用例对数据的所有输入情况都已经考虑进去了。

dandan

.......GO ON

Lero

呵呵，我基础的确不好，但是等价类和边界值我也知道。
只是我觉得在测试的时候非要考虑使用那种方法这样反而落了下乘。
根据经验，你其实知道那些地方该怎么测，至于具体使用到了什么方法我的确是没有去研究。
难道非要把用例上的数据，文字都归类到这些测试方法里面就表示这个用例很好了？

浑然天成、妙手偶得！

eaglenan

需求部分的测试方法，51testing就有个相关的英文文档，名字叫EffectiveSoftwareTesting-50SpecificWays.rar(615.78K) ，你找找，对你可以有不少帮助，

harryhu

原帖由 Lero 于 2006-8-9 18:41 发表
呵呵，我基础的确不好，但是等价类和边界值我也知道。
只是我觉得在测试的时候非要考虑使用那种方法这样反而落了下乘。
根据经验，你其实知道那些地方该怎么测，至于具体使用到了什么方法我的确是没有去研究。
...

难道非要把用例上的数据，文字都归类到这些测试方法里面就表示这个用例很好了？
用例不仅仅是现在用，而且以后还要用，所以当然要加上。

swallow1981328

开发文档经常不明确，你有这个不错了。
我们用td管理测试过程，需求基本就列出大体的程序模块，至于用例，由于没有具体内容只有等程序出来再写，按照程序员的描述和需求文档具体编写。
至于测试数据，如果与系统的业务关系非常密切的话，而且你也确实难以理解，就找客户要；如果不是太难懂或难以计算的话，就自己编好了

lyh20041110

我觉得，首先你应该与项目负责人及开发（也就是说整个项目组成员）共同针对客户需求进行可行性讨论与分析，并针对所收集需求及经过讨论后的 需求及时与客户沟通最好能进行签字确认，若没有进过客户认可的需求将会影响你今后测试计划及测试用例－－－－－因需求若不确定就会随时更改，而你的整个测试计划与测试用例是完全建立在需求上的（除非你可以与客户相关人员可以及时沟通），这是测试计划与用例的依据；测试计划在需求出来后两天左右就应该出－－－主要介绍项目的目的、背景、测试主要内容（含优先级划分、附带系统的各个功能模块的简述）、测试方法（黑盒测试、白盒测试、压力测试、性能测试等具体方法的确定－－－－可以是多种方式均有，也可是只以某种方式为主等，对了当然还少不了测试工具的选用－－－－－在计划出来后就可依据需求及测试计划进行测试用例的编写－－－用例主要数据的来源来自于你对需求的理解－－－－针对你所说的需求主要可以从日期、查询、金额数据输入方面入手－－－即：例如：归还日期是否允许大于借款日期、归还日期是否允许超过账期等设定，而金额方面则检查是否允许为负值等.......................

weijiemiamia

看看窗体说明书吧