需求测试要点

wmty · 发表于 2005-11-18 21:57:06

软件测试的一个主要依据是软件的需求

在需求评审的时候怎样判断需求符合标准？

只考虑可测性，也就是审查能否作为测试需求，并从中提炼出测试用例。

1.功能说明要求，具体到什么程度。
输入，输出项是否全面
2.性能要具体求

第十二颗地雷 · 发表于 2005-11-23 14:37:54

需求评审要求的是行业专家！！
说白了就是对这行的经验！！
以行业专家的经验，行测试人员的言语
（用测试人员的行话把行业专家的要求说出来）

skinapi · 发表于 2005-11-25 11:32:07

需求评审肯定有相应的checklist做参考，楼主可以到网上找找看。

天网 · 发表于 2005-12-15 12:15:11

需求评审可以从以下几个方面去关注：
1、需求的完整性；
2、需求的一致性；
3、需求的无歧义；
4、需求的可验证；
5、需求的可追踪；
6、需求的正确性。

这是对在需求文档中已经描述的需求进行评审时所需要关注的地方。可能测试人员更关注需求的可验证性。但需求评审的难点是要去发现那些需求遗漏和需求的偏差，而不仅仅是对已经挖掘和定义的需求去进行评审。这对评审者提出了非常高的要求，但需求活动是非常高层次的活动，对参与者要求高也是很自然的事。很多公司也制定了流程要进行规范的需求评审，但需求质量还是不高，就是因为流程有了，可是执行流程的人的技术能力还没达到要求。要想有好的质量，流程和技术，缺一不可。

wzb521 · 发表于 2005-12-23 10:36:56

需求评审中的软件功能还应该考虑：需求的清晰性、需求的覆盖率、需求的级别、安全性需求。
不同公司、不同的软件所要关注的重点是不同的。
需求评审中还应包括：需求风险、需求是否可以转换为代码、以及需求约束

仅代表个人观点

小月三木 · 发表于 2005-12-28 09:41:45

好，东东，昨天才需求评审完，本身做测试的，也没有评审过，今天好好学习下，下次可以用大家这些理论东西对照来做，应该会做的更好！

fanna007 · 发表于 2006-1-23 22:46:27

需求说明的特征:
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能
所需的所有必要信息。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如
用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有
用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参
与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完
全是评审者凭空猜测。
3. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行
的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与
需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也
可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户
的输入，如使用实例或别的来源。
5. 划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。
如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制
自由度。
6. 无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，
所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需
求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
7. 可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确
定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，
而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

[ 本帖最后由 fanna007 于 2006-1-23 22:49 编辑 ]

fanna007 · 发表于 2006-1-23 22:47:26

需求规格说明的特点
1. 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功
能将有助于你避免不完整性。如果知道缺少某项信息，用 T B D (“待确定”)作为标准标识来标
明这项缺漏。在开始开发之前，必须解决需求中所有的 T B D项。
2. 一致性
一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所
有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
3. 可修改性
在必要时或为维护每一需求变更历史记录时，应该修订 S R S。这就要求每项需求要独立标
出，并与别的需求区别开来，从而无二义性。每项需求只应在 S R S中出现一次。这样更改时
易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容
易修改。
4. 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这
种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，
而不是大段大段的叙述。

[ 本帖最后由 fanna007 于 2006-1-23 22:49 编辑 ]

walker1020 · 发表于 2007-4-13 21:07:07

此帖子的讨论有深度，顶一下！

velata · 发表于 2007-6-8 15:33:42

嘻嘻
我们是写测试用例的时候顺便测试了需求用例
检查也只是检查下有无明确逻辑错误，有无错别字而已

june_zhuhui · 发表于 2007-6-11 21:10:08

学习中

jysql · 发表于 2007-11-20 10:23:10

学习中

synthere · 发表于 2007-11-20 15:39:29

学习学习ing

6739 · 发表于 2008-4-18 14:51:11

学习中

shuangpu56 · 发表于 2008-4-21 15:16:11

嘻嘻
我们是写软件测试用例的时候顺便测试了需求用例
检查也只是检查下有无明确逻辑错误，有无错别字而已。

magiexj · 发表于 2009-3-26 16:17:38

如何做好需求评审

wolsion · 发表于 2009-3-26 17:54:42

关注学习中。。。

lixiaoxiao6 · 发表于 2009-3-31 11:47:33

还没见过需求评审呢，(*^__^*) 嘻嘻……

		自动登录	找回密码
密码			(注-册)加入51Testing

需求测试要点

相关帖子

学习

如何做好需求评审

站长推荐 /1