第95贴【2004－9－2】：需求测试

天网

软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %～8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。

[ Last edited by 天网 on 2004-9-2 at 10:00 ]

天网

同行评审（Peer Review）是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。需要进行同行评审的特定工作产品在定义项目软件过程的时候被确定并且作为软件开发计划的一部分被安排了进度。

michelle_happy

我也很想知道关于同行评审的定义

beiyue

wuxiongyu

太长了,,看不到

jackei

下面的内容来自小可Blog中的“测试需求与测试用例”一文，有兴趣的朋友可以参考。也可以参考《程序员》2004年第8期中该文的”完美版”^_^http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx

在实际工作中，对软件需求的检查可以简单的概括为两个方面的内容。
一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，关键是不要迷信所谓的“都是用户提出的真实的需求”。我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。
二是要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的直白一点，就是要保证所有的需要实现的需求在最终实现后，都可以用某种方法来明确的判断是否符合需求文档中的要求。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。

aitn

请问搂主：
1、“同行评审”中的同行是指测试人员同开发人员、项目需求人员、项目经理吗？
2、“同行评审”怎样实施？因为在现实生活中，测试人员的话是没有太多分量的。在测试不是很受重视的情况下，怎样让发起这个“同行评审”
谢谢

beiyue

有时候系统分析人员和开发人员低估测试人员的能力
在做需求的时候根本就不让参与
这样我们做起来非常被动
当然这个涉及到整个开发流程的规范性上面了

qiguojie

beiyue说的好对。。这个时候发现的问题。。是最不值钱的。。呵呵

xiaojinzi

我想请教一下：
1.所说的“同行评审”都评审什么，或者说从哪个角度 / 方面评审，“同行评审”太抽象  了。
2.本帖提到的一些自动化工具是指什么？能指点一下吗？

beiyue

babybear315

测试的方法：
1 确认需求，确定需求是确定的，描述清晰的，没有歧义的。
2 功能设计人员，开发人员，测试人员对功能的理解要达到一致。
3 确定功能需求需要达到的指标，核实功能设计书和任务书。

fy_fuying

赞同。尤其是开始制定时面对的是潜在的用户，需求也是要常常变的。

erbao

不知道需求测试到底怎么测试？