需求评审与需求测试

一.需求评审与需求测试在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。需求工程师取得用户的显性需求后，要仔细的分析用户到底要求软件实现什么功能，用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户所想的和需求说明书上所描述的有偏差。并且需求工程师取得用户的需求后必须做仔细透彻的分析，有时候用户的需求并不一定正确，可能是用户忽然的想法，并不可行。如果需求工程师不能对用户提出的需求进行判断的话，可能辛辛苦苦的实现了用户需求，结果被用户自己否决掉。用户绝对不会将责任揽到自己身上，他们只会说“你们是专家，怎么能怪我呢？”。网上有一幅漫画形象地描述了信息在传递过程中产生的误差。需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。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需求是否可行