请问写测试用例前要不要做需求文档的测试啊？
我们公司让我直接根据需求写测试用例，可是我写用例的时候发现有好多的需求都有问题，主要是数据类型和输入方法的错误，（其他错误我也看不出来，我根本就不懂真正的客户需求）我想问的是1、在写测试用例以前是不是要做需求文档的测试呢？
2、需求文档的测试是测试需求的哪些方面，是否包括数据类型是否合理呢？ 好像早了点，再说，如果不懂需求写出的用例就不能保证多么有效了，建议还是搞清楚需求，起码显性的需求先要明白。
R请问写测试用例前要不要做需求文档的测试啊？
回答:1.理论上,在需求文档编写时,测试员就可以提出不合理的问题.实际中,那时没有让测试介入,所以,这是整个项目的计划的问题,你目前不必先去测试需求文档.你此时的角色,是为了系统测试做准备.若是这样,你的用例就没有必要很细.只需一个大的框架.比如你提到的:数据类型是否合理. 这些都是异常流出现的状态.目前你只要编写正常流就可以了!
2. 需求文档的测试一般偏重于检查需求,确保所有需要的文档是完整的.数据类型是否合理不包括在此阶段,它应该用在软件设计文档测试中. 测试从文档审查－静态分析－代码审查－系统测试，回归测试包含在各个阶段之中，需求规格说明是文档审查的一部分工作，只有经过回归审查之后才能进入下一个阶段 需求文档的检查,不仅仅是测试人员能够做得了的
在开发过程中,需求分析阶段,需求文档是要通过评审后,才能进入下一阶段的
而需求评审应该是专家评审,包括业务专家、项目经理、需求分析师、系统设计师、测试经理等相关人员 过程不规范了不是！既然是写用例用的，那楼主看的应该是产品需求了。
需求是要评审地！评审通过的产品需求才能拿过来做测试计划和写测试用例呀！
产品需求的评审依据客户需求，产品需求主要由研发部编写，需要组织研发人员，测试人员，质量管理人员，需求管理人员和高层经理进行评审，可能楼主所在的单位没有这么全的机构设置，但至少要组织研发和测试人员在一起评审一下。
在编写测试计划或者用例的过程中发现需求有问题可以向编写者提出，经他们考虑后进行变更。
当然，产品需求的不恰当，也可能是客户需求本身就制定的不太合理造成的，同样，要想客户需求的负责人联系各方面来变更客户需求。
如果这两个需求做不好，写不好测试用例是次要的，真到了编码编到一半或者到系统测试了才意识到要修改的必要，那影响的东西可就多了。
测试队伍起到的一个质量保证的作用，越是早介入早发现问题，就能够越早的把好质量关。
不过，呵呵，如果楼主单位测试人员的地位和说话的分量不够的话，恐怕就起不到好作用了。
页:
[1]
