需求评审与需求测试.docx

需求评审与需求测试.docx

《需求评审与需求测试.docx》由会员分享，可在线阅读，更多相关《需求评审与需求测试.docx（25页珍藏版）》请在冰豆网上搜索。

需求评审与需求测试

一.需求评审与需求测试

在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。

因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。

需求工程师取得用户的显性需求后，要仔细的分析用户到底要求软件实现

什么功能，用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户

所想的和需求说明书上所描述的有偏差。

并且需求工程师取得用户的需求后必须

做仔细透彻的分析，有时候用户的需求并不一定正确，可能是用户忽然的想法，

并不可行。

如果需求工程师不能对用户提出的需求进行判断的话，可能辛辛苦苦

的实现了用户需求，结果被用户自己否决掉。

用户绝对不会将责任揽到自己身上，

他们只会说“你们是专家，怎么能怪我呢？

”。

网上有一幅漫画形象地描述了信息在传递过程中产生的误差。

需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此

对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。

通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。

1、需求评审

需求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必

须自己对需求做评审。

如果需求组递交的需求规格说明书在指导后面的工作的时

候出现很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。

为了

需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自

己的工作成果足够好，才会将需求规格说明书提交给正式评审组。

正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，

当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们

仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问

题

正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统

设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。

因此正式评审

将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑

剔评审才能通过。

2、需求测试

可以认为需求评审也属于需求测试范围，但是这里提的需求测试和评审不同，它

是测部门来测试需求是否符合用户的要求。

显然这是有难度的，传统的测试工作

都是从单元测试开始，编码之前全部做得都是计划性工作。

测试人员对需求分析

进行测试？

那么前提条件是测试人员必须熟悉需求分析，这对测试人员的要求提

高了。

将需求测试人员作为测试人员中的特殊种类来培养，能够对需求是否正确

进行检查，这样就能够在需求阶段就引入测试。

当然需求测试人员可以是经过培

训的需求分析人员，但是他必须脱离需求组，加入测试部门，这样才能保证测试

不是自己人测自己，以保证测试的效果。

需求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编

写完成的条件下，判断软件是否会出错。

而需求测试，只是验证需求是否真的是

用户的。

对于需求的功能测试，可以用RAD工具建立界面原型，用户通过原型的

操作来确定是否需求跟他的期望相同。

对于那些用户不合理的需求，测试人员要能够分辨出来，并跟用户进行核对，确定用户的真实需求。

可以说需求测试是需

求测试人员和用户共同来执行的。

之所以将需求测试和需求评审并行进行，是因为需求评审是项目的各方干

系人共同进行的检查工作，评审工作关注的焦点是分散的，很难将偏离用户的需

求检查出来，并且涉及的人很多，因此不可能耗费太长时间。

而需求测试执行的

时间可以比评审时间长，有专门的关注方面，能够检查出不合理的需求分析，在

项目前期进行错误纠正，往往比实现后纠正要节约几百甚至几千倍的成本。

二．测试人员眼中的需求分析 

1 测试人员在需求分析过程中的职责测试人员的职责是对需求分析中产生的各

种文档进行评审，确定其质量达到要求（尽量减少错误），提出修改意见，为今

后的跟踪和测试打下基础。

同时希望通过此文来丰富我们现在《文档审查检查表》

的内容和可操作性 

2 需求分析阶段的测试1首先检查所有的文档（或文档相关方面）是否齐全，包

括项目范围、用户分析、实体和实体关系图、使用实例、软件需求规格说明文档。

2 检查所有的文档是否按照正确的模板来写？

3 数据字典和使用实例是否在项目范围之内？

4 软件需求规格说明文档是否与数据字典和使用实例相符，内容是否在项目范围

之内？

5 项目范围是否清楚？

读完一份项目范围书后应该能清楚的标明哪些功能要作，哪些功能不作。

6 项目范围参考文档是否列清楚？

能从参考文档中查到对应的依据。

7是否做过用户分析？

是否有对用户类型的描述，是否与对应的用户作过讨论，讨论的结果是否包含在

使用实例中。

8 是否有实体联系图？

是否对用户数据进行详细的分类和统计，并对对应数据作详细的描述，有没有收

集用户提到的相关报表的样式？

2.1使用实例文档审查清单 

1 使用实例是否是独立的分散任务？

2 使用实例的目标或价值度量是否明确？

3 使用实例给操作者带来的益处是否明确？

4 使用实例是否处于抽象级别上，而不具有详细的情节？

5 使用实例中是否不包含设计和实现的细节？

6 是否记录了所有可能的可选过程？

7 是否记录了所有可能的例外条件？

8 是否存在一些普通的动作序列可以分解成独立的使用实例？

9 是否简明书写、无二义性和完整地记录了每个过程的对话？

10 使用实例中的每个操作和步骤是否都与所执行的任务相关？

11 使用实例中定义的每个过程是否都可行？

12 使用实例中定义的每个过程是否都可验证？

13 使用实例是否有唯一的编号？

2.2 软件需求规格说明的审查清单 1 组织和完整性（对大项目尤其重要，因为

大项目分割的模块很多，容易丢失一些功能） 

2 正确性 

3 质量属性 

4 可跟踪性 

5 特殊的问题三.需求说明的特征:

1. 完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这

些功能所需的所有必要信息。

2. 正确性

每一项需求都必须准确地陈述其要开发的功能。

做出正确判断的参考是需求的来

源，如用户或高层的系统需求规格说明。

若软件需求与对应的系统需求相抵触则

是不正确的。

只有用户代表才能确定用户需求的正确性，这就是一定要有用户的

积极参与的原因。

没有用户参与的需求评审将导致此类说法：

“那些毫无意义，

这些才很可能是他们所要想的。

”其实这完全是评审者凭空猜测。

3. 可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

为避免

不可行的需求，最好在获取（ e l i c i t a t i o n）需求（收集需求）过程中始终有

一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负

责检查技术可行性。

4. 必要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。

“必

要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。

要使每项需求

都能回溯至某项客户的输入，如使用实例或别的来源。

5. 划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的

分量。

如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或

调度中就丧失控制自由度。

6. 无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二

义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

避免二义性的

有效方法包括对需

求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

7. 可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测

等来确定产品是否确实按需求实现了。

如果需求不可验证，则确定其实施是否正

确就成为主观臆断，而非客观分析了。

一份前后矛盾，不可行或有二义性的需求

也是不可验证的。

四.需求阶段的测试

首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认

为是需求阶段，或者没有规范需求工作的设计阶段。

如果有一个比较明确的需求

文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。

这里，

对于需求文档的检查主要是两个方面：

1.检查需求文档描述的正确性，测试人员要对于真实的系统所涉及的业务非常

熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务

制度熟悉，在检查需求

文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用

户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需

求。

另外，还有一个用户的嘘气是否符合行业规范的问题，如果不符合，那么是

否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要

走行业规范，让你的需求变动，所以要事先明确好。

2.检查需求文档描述的准确性。

主要是考虑文档中是否存在描述的模糊的地

方，对于自己不清楚的问题一定要明确。

这个时候是要保证需求的可测试性—— 

我得意思是说保证需求是可以完全为测试工作服务的。

那么在检查完了需求之后，就可以开始设计测试用例了，在这个阶段因为

没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发——虽然 

RUP中对于用例的要求有这一项。

因而测试用例的设计应该从业务角度出发，

从实际业务出发来设计测试用例。

当然，在测试用例的描述时，要尽量考虑怎样

同应用程序脱离开而仍然具有有效性。

当然，这个阶段所实现的测试用例是不过完善的，只能涵盖某些内容，但是

我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。

不

过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，

而不是被动的等待。

要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的

方法来开展工作。

相信学过马克思哲学的朋友都知道什么是客观性和主观能动性吧。

当然，在设计阶段和最后的编码阶段，都还可以继续添加、修改或者剔除掉部分

测试用例，使之更加完善。

一般软件测试都是编码阶段开始，而在现代软件测试中都是推崇使用测试驱

动的方式进行软件开发的，以减少为修正错误而付出有时候甚至是惨重的代价。

我们应该在需求阶段就重视和开始进行测试，这是因为系统的大多数的重要决定

都是在需求阶段做出的，一旦一个即使是微小的错误在需求阶段产生，并延续到

编码和集成测试结束之后才发现，其代价就是要重新确定需求再进行设计再编码等。

据估计，再验收测试阶段发现的错误的修复费用比能在需求阶段发现的错误

要付出的多10倍。

所以说，需求阶段的测试是必要的。

每个测试阶段都应该有负责人或者是负责组织，这里的负责人或负责组织不一

定是负责着测试的任务，而是对测试的结果进行确认和经过确认后负有这个测试

结果的责任。

需求阶段的测试负责人应该是最好是用户，用户可以看见经过测试

之后记录下来详细的需求变化做出决定，这样可以使用户更加明确了需求的内

容。

所以说服用户积极参加和承担需求测试责任是需求测试成功的第一步，也是

系统开发顺利进行的第一步。

需求阶段的测试是在需求完成之后评审需求之前这段时间中进行的，应该由管

理部门来提出测试要求，测试小组执行并向管理部门提交有关问题的可选方案及

最佳方案等报告。

需求阶段的目标一般有如下5点：

1）需求已经文档化并且完整地描述了用户的需求期望；

2）业务问题已经解决了；

3）系统要求的性能价格比已经经过讨论研究并证实是合理的；

4）已经明确了控制需求的方向（“控制”在这里的意思是包括所有的机制、方

法及应用程序中用于保证其功能与期望相一致的过程。

）；

5）确定需求阶段所有解决问题的方法和途径是有效和正确的。

在测试过程中，

一定要以测试目标为中心，去查找不充分的不完整的需求，直到所有的不充分的

不完整的需求得到解决并经过再测试OK，需求阶段的测试才可以结束。

在进行需

求阶段的测试之前必须了解“测试因素”的概念，掌握一些测试技术和一些测试工

具。

为了了解“测试因素” 

其实测试人员在需求阶段介入测试要求是非常高的，静态测试作为这一期间的主

要测试行为，一般按照正式技术复审会议展开，一般情况下测试人员比较关注需

求的整体性检查，可使用的检查表为：

01需求是否完整？

02所有的需求是否均可唯一确

定？

03所有的需求的分级是否清晰

而适当？

04需求是否具有一致性?

（即，

内部无矛盾）

05需求组合是否充分地提出了

所有适当的例外情况?

06需求组合是否充分地提出了

边界情况?

07需求是否可行?

（即,该需求

组合有解决方案）

08需求可否用已知的约束来实

现?

09

整

体

检

查

需求是否足够?

（即,可以把它送到一个规范的开发组织，

并有一个生产出所需要产品

的合理的可能性）

10反面的需求明确地规定了吗?

11这些最简单的需求组合达到

了相关干系人的要求了吗?

12所有到其它需求的交叉引用

是否正确?

13功能性和非功能性的需求都

考虑到了吗?

14本条需求是否明确和准确?

15有没有尽可能地用简单的表

格来规定本条需求？

16本条需求能否被测试或被验

证?

17本条需求是否正确?

18需求是否在范围内?

（即,只

要有一个需求遗漏了，这个系

统就被认为是不完整的）

19需求是否很容易被更改?

20需求是否是用客户的语言和

术语来撰写的?

21这个需求可被所有相关涉及

人员接受吗？

22这个需求是否是对所有相关

涉及人员的需要的描述,而不

是一个解决方案?

23需求可被追踪吗?

24是否必需?

25如本需求有信息缺失，这些信

息是否记录于待决定列表并

指定了解答者和解答期限了

吗?

需求阶段测试人员发挥的实际效果不大，如果参与的测试人员本身具备很高的业

务知识或者本身就是业务专家则另当别论，一般参与正式技术复审会议通常按照

两种形式展开：

内部抽取检查：

由项目人员内部抽取一定数量的需求在内部展开检查，参与人员可以是 SA、业

务专家、资深开发、测试或者QA，展开后按照需求检查列表一项一项的过。

内

部抽取的定义是尽可能的发现问题，然后根据会议记录后的问题经过业务方证明，或者取消或者增加，主要排除镀金需求等一系列不可实现或者实现后不符

合主业务路线的需求，效果一般注重会议后的疑问跟踪，通常会议上会当场指定

需求跟踪人员，必须在指定时间内清除疑问，否则容易丢失。

这种会议容易跑题，

需要会议组织者经常纠偏。

指定需求检查：

需要邀请需求最终承载用户参与，并且用户具备一定的IT实施能力，这种形式

的会议通常会当场否定部分需求，或者大量增加需求实现。

效果最好，但是会议

交流比较激烈。

通常这种会议后会跟上内部抽取检查会议。

需求文档检查

会议前由QA展开，比较形式不注重业务本身检查

做好需求的测试，对于测试人员的要求可就不那么简单了。

除了要具备测试的基

本素质之外，这个人还要有比较深的行业背景。

对于行业业务了如指掌，对软件

的逻辑结构的设计和掌握程度也要水平比较高，否则就不能够知道需求分析，是

不是把客户需要的东西全部正确的实现了。

也不能预见所有分析的功能是否真的

都可以实现。

这样自然达不到评审的效果。

五.软件需求测试

软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统

测试的方法。

但这还不是足够的。

全面的质量管理要求我们在每个阶段都要进行

验证和确认的过程。

因此在需求阶段我们还需要对需求本身进行测试。

这个测试

是必要的，因为在许多失败的项目中，70%～85%的返工是由于需求方面的错

误所导致的。

并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发

散，这是一件及其痛苦的事情。

因此我们要求在项目的源头（需求）就开始测试。

这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这

些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），

因此在适用性上会受到限制。

通过静态手工方法进行需求测试中最常使用的手段

是同行评审。

通过评审来测试需求

同行评审是业界公认的最有效的排错手段之一。

我们在需求测试过程当中，使用

最多的也是同行评审（PeerReview），尤其是正规检视（Inspection）。

正规

检视是由MichaelFagan在IBM制定出来的一种非常严格的评审过程。

需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的

管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。

在项

目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否

则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。

好的需求应当具有的特点

一个良好的需求应当具有一下特点：

完整性：

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计

和实现这些功能所需的所有必要信息。

正确性：

每一项需求都必须准确地陈述其要开发的功能。

一致性：

一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施

的。

无二义性：

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言

极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：

需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行

了容错处理。

必要性：

“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。

要使每项需求都能回溯至某项客户的输入，如UseCase或别的来源。

可测试性：

每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：

每项需求只应在SRS中出现一次。

这样更改时易于保持一致性。

另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修

改。

可跟踪性：

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间

建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-

grained）的方式编写并单独标明，而不是大段大段的叙述。

另外应当对所有的需求分配优先级。

如果把所有的需求都看作同样的重要，

那么项目管理者在开发或节省预算或调度中就丧失控制自由度

通过用例设计来测试需求

我们从V模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能

测试为基础。

每个开发阶段的活动都与相应的测试活动是并行进行的。

在需求阶

段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执

行外，其本身也是对需求的一个验证过程。

通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。

以

功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系

统的行为。

虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作

可以解释需求的许多问题。

如果你在部分需求稳定时就开始开发测试用例，那么

就可以及早发现问题并以较少的费用解决这些问题。

设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，

为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同

于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测

试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：

1、需求不完整或者需求有错；

2、遗漏了测试用例或者测试用例本身有错误；不管是哪种解释，最终肯定会提高整个系统的质量。

但这个质量的获得是通过冗

余的人员来完成的，即：

开发人员在对系统需求进行进一步分析的时候，有一组

独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。

尽管这

两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更

清晰和更完善。

需求建模测试

需求的建模包括把需求转换成图形模型或形式化语言模型。

需求的图形化分

析模型包括数据流图（DataFlowDiagram，DFD）、实体关系图

（Entity-RelationshipDiagram，ERD）、状态转化图（State-Transition

Diagram，STD）、对话图（DialogMap）和类图（ClassDiagram）。

这些图形

化模型一般都需要借助一定的CASE（Computer-AidedSoftwareEngineering）

工具。

这样就可以借助于自动化分析工具本身提供的检测手段来对需求进行测

试，而这类检测主要可以提供描述上的完整性检查，需求项之间的不一致性检查

等方面的功能。

同时，使用这类自动分析工具有助于获得需求的质量特性，包括：

有效性、一致性、可靠性、可存活性、可用性、正确性、可维护性、可测试性、

可扩展性、可交互性、可重用性、可携带性等。

写测试需求主要为了什么呢？

我们的项目中基本都有很细致的功能规格说明，还

有其他一些相关的概念设计文档，我们总是会看到这些文档的最新版本。

然而，

我们的项目多为迭代方式进行，分很多版本提交，1.0.1、1.0.2等等。

在这些

版本中，我们并不是每个版本都要测试全部的功能，往往是测试一部分。

有的版

本主要测业务流程，有的主要测性能。

测试需求就是说明，这个版本需要测试哪

些东西。

测试需求按照功能性、可靠性、易用性、性能、可维护性、可移植性来分类。

同

时也要按照优先级来分类，有的是必须测试通过的，有的可以协商。

除了说明我们需要测试的内容以外，测试需求还有一个重要的作用：

辅助说明测

试接受标准。

比如某个版本的功能测试需求有100个功能点，其中30个必须

实现，其他70个实现60个即可，假如每个功能点1分，那么，功能测试接受

标准就是：

总分90分以上并且30个重要功能点必须测试通过。

假如没有达到

这个接受标准（只有85分），我们就可以负责的说：

测试不通过，不能发布。

如果要发布，可以，变更项目计划和测试计划。

测试需求最好能细致到功能点的粒度，这样对项目量化管理非常有好处，而且，

我认为这是应该在项目版本计划中进行说明的，如果项目计划中没有说的很详

细，那我们的测试计划就要写的详细一些。

六.测试人员在需求阶段应做哪些工作

相信很多人跟我一样有过这样的困惑，那就是在需求阶段我们测试人员应该做些

什么？

下面就将看过的一篇文章贴出来与大家一块分享。

首先，测试用例和测试工作