在网上收集了几篇测试需求分析的文章

愚人 · 发表于 2009-11-4 23:13:36

软件测试之需求分析与软件可靠性保证

一、软件可靠性工程与需求工程的关系
　　软件需求分析是软件产品开发设计的第一步，也是最重要的一步。其工作质量的高低，不仅直接影响后续工程的质量，而且决定着所开发软件产品的价值。当然，完整、严密地描述用户需求，并不是一件十分容易的事。有些软件产品之所以功能不完善、性能差、可靠性低、可用度差、甚至不能使用，多数是因为用户需求分析工作不彻底所致。但是，目前软件可靠性工程研究与实践的重点，在于软件测试等一些事后的验证性工作，对软件可靠性设计重视不多，这在需求分析等前期阶段尤为突出。
　　二、软件需求分析
　　软件需求分析是软件设计的基础。它采用一系列行之有效的技术、方法和工具来分析用户需求，通过特定的形式系统地描述拟开发软件的功能、性能，以及行为特征和相关约束，定义所有内外部特征，最后形成既能指导软件设计、又能同用户沟通的软件需求规格说明。它覆盖了软件设计之前的各项活动。
　　软件需求分析是从用户最初的非形式化需求，到满足用户要求的软件产品设计的一个映射。
　　在软件计划的基础上，从深入分析用户需求出发，把用户的需求变换成以计算机为基础的系统需求。需求分析实际上是调查、评价、以致肯定用户对软件的需求的过程，是一个对用户意图不断进行揭示和判断的过程。其目的在于细化、精化软件的作用范围，确定拟开发软件的功能和性能，分析并确认其过程，确定软件成分及接口。
　　1.软件需求分析的任务与步骤
　　软件需求分析可分为四个步骤。
　　①归纳整理用户提出的各种问题和要求，弄清用户企图通过软件达到的目的，并把它作为要求和条件予以明确。即分析人员借助各种工具和方法，获得对用户需求的基本理解，然后在需求获取方法的驱动和指导下，从非形式需求陈述中提取出用户的实际需求。由此确定软件的功能、性能、接口关系及有关属性、软件条件、限制和边界等，标定软件的作用范围，确认支持性的软硬件环境及辅助工具与条件。此阶段还为软件需求分析活动提供了相应的过程控制机制。
　　②在需求获取的基础上，建立逻辑模型，使用自顶向下、逐层分解的方法，把用户对软件的需求分解成若干子系统或软件成分，将外部需求赋予软件的各个功能成分，定义软件成分的内部功能，并标定它们之间的接口。
　　③用准确、简练、无二义性的语言将用户需求规格化为软件需求规格说明，使用户和开发人员对拟开发软件有共同的理解，它同时还是软件确认、测试、验收和交付的基准。
　　④通过需求评审，对需求获取、需求定义等进行全面审查，力图发现需求分析中的错误和缺陷，最终确认软件需求规格说明。同时，以需求规格说明为输入，通过符号执行、模拟或快速原型等方法，向用户展示需求规格说明所刻划的系统外部行为和相应特征。
　形式化方法通常有严格定义的分割、抽象、投影机制，其数学定义有助于澄清认识。规格说明的构造往往是增量式的，但数学定义不是所有软件开发人员都能轻易掌握的，它与一般应用尚存在相当的距离。
　　非形式化方法常常以某种方法学或方法框架的形式出现，非形式化地描述一系列规格说明的步骤和原则，并定义相应的记号。其典型方法有结构化分析方法和面向对象分析方法等。结构化分析方法源于数据处理应用，是一种单纯的自顶向下的功能分解技术。面向对象分析方法大多通过对象(类)、状态、交互行为来刻划问题及问题的解，强调对对象及对象类的定义和求精。
　　在实践中，人们逐步认识到形式化和非形式化方法的不足。于是，力图寻求一种结合这两种方法的长处、并能有效克服其缺点的综合方法。基于知识表示的方法是这种方法的代表。
　　知识表示技术为需求规格说明奠定了形式基础，而非形式的方法框架给出了需求说明的指导原则。它由辅助系统检测当前的需求状态，提示下一步的工作。其辅助系统一般检测和提示多种意向的存在，并支持对需求的增量式开发。因此，其前景依赖于辅助系统的智能化程度和方法框架给出的各项指导原则的有效性。
　　需求说明语言的选择至关重要，它直接影响需求说明的质量和可理解性。一般地，需求说明语言应能对现实世界中的各种概念、特征、变化等具有完备的表达能力。而且，它应是易学、易用、易读、易懂的。目前，主要有自然语言、结构化行为描述语言、形式语言、半形式语言四类规格说明语言。
　　现在，大多数需求规格说明使用自然语言编制，但这相当危险，其非形式特征将妨碍软件开发人员就拟开发软件的各个细节达成共识。
　　三、需求分析工程中的可靠性保证
　　1.影响需求分析可靠性的因素
　　下述因素是影响软件需求分析可靠性的主要因素：
　　分析工具、方法的选择、使用及其有效性。
　　建模语言的选择与开发人员、分析对象和需求领域的适配性。
　　需求分析人员与用户和专家之间的沟通。
　　需求获取与分析的彻底性、完整性、准确性，以及分析方法的有效性。
　　需求分析规格说明定义与描述的完整性、准确性、一致性、无二义性，以及可读性、易理解性和可维护性。
　　功能需求包括备选功能的定义和识别。
　　性能需求包括纠错及功能增加所产生的影响。
　　环境要求对软件实现的影响。
　　数据的准确性和逻辑组织
　　不准使用需求说明语言中不曾定义的符号，保证所有语句均满足语法规则。实践表明，错误的预防、检测和更正是语法质量保证的三种基本手段。检测错误是通过模型的构造发现错误;预防错误是拒绝在模型中加入错误的语句;更正错误是用正确的语句替换错误的语句。前两者可以通过需求说明语言的形式预防来完成，后者则较难自动化。
　语义质量是需求模型有效性和完备性的保证。有效性要求模型中的所有语句都正确且与用户需求相关;完备性要求模型包含领域中关于问题的所有相关语句。需求模型与领域越相似，其语义质量越高。但对实际问题，不可能达到彻底的有效性和完备性，因而较为实际的目标是在约定的可信度下的有效性和完备性。多数提高模型质量的方法都依赖于人们对模型具体内容的理解，即语用手段。一致性检测往往可自动完成，而不必真正理解给出的模型。
　　语用质量影响人们对表达同一意义的多种表达方式的选择，其目标是可理解性。它不仅要使需求模型能被理解，而且要确保开发人员理解该模型。与语义质量目标一样，在可理解性中也需要引入可信度。任何有助于理解需求模型的手段都可以纳入达到语用目标的有益途径。
　　例如，各种逐项阅读、以求理解的模型检查，以图表代替文字的模型可视化，利用动画表现系统动态特征的模型动画显示，根据统计数据预测模型所刻划软件行为特征的系统模型，基于解释的模型查阅手段，基于过滤(甚至包括语言翻译)的阅读范围控制等。
　　3.软件需求分析中的可靠性分析、设计与管理
　　在软件需求分析过程中，可靠性任务包含四方面内容：一是对可靠性需求的获取、分析二是确定拟开发软件的可靠性目标;三是软件需求分析过程中的可靠性设计;四是为实现可靠性目标而采取的可靠性管理。在需求分析活动中，将这四方面的可靠性任务以用户和软件开发人员共同熟悉的软件可靠性度量加以反映。
　　用户需求中有时已经包含了用户对可靠性的要求，这样，需求分析人员只需将其可靠性要求和其它要求一起进行细化，并以规定的要求和形式形成能综合反映可靠性要求的规格说明即可。不过，大部分用户对可靠性提不出明确的要求、甚至没有要求，这就需要根据用户对拟开发软件的功能、性能等要求，来确定用户对可靠性的要求和可靠性目标，并将其随软件功能的分解而分解。
　　在软件需求分析过程中，我们可以很方便地列举出影响软件需求分析可靠性的一些常见的错误和缺陷，并可以估计需求分析错误相对这些错误和缺陷的分布。
　　为了进一步开展软件需求分析中的可靠性设计，可以用需求分析中的错误或缺陷度量来对需求分析的有关可靠性指标进行度量。通过度量，明确主要的软件错误分布及对软件需求分析可靠性的影响，以及软件需求分析阶段的错误或缺陷指标后，我们就可以对相关的错误或缺陷进行控制。
　　需求分析中的错误或缺陷，主要残存于需求规格说明中。对此，可通过仔细的复核、审查与评审来降低。当然，分析人员素质的提高，以及分析工具、方法和说明语言的选择都相当重要。
　　软件需求分析阶段中的可靠性问题，同样严重受制于其复杂性。因此，有效地控制其复杂性(包括结构的、功能分解的、总体的、规格说明的复杂性)，是确保需求分析阶段可靠性的有效措施。
　　为了能有效地避免需求分析中的人为因素，需求重用在很多时候是一种非常有效的方法。它包括模型、方法、概念、工具的重用，以及需求规格说明的片段、甚至完全的重用。
　　因为软件需求分析是一项纯智力活动，所以需要在这一过程中、尤其在需求分析的后期，进行有效的评审和验证。它们是发现需求分析错误和缺陷的最有效的办法。当然，它们也只能发现需求分析中的错误和缺陷，并不能保证需求分析没有错误和缺陷。此时，采用基于严格数学正确性证明和公理证明的非形式化正确性证明方法，会收到意想不到的效果。
浅谈项目测试需求分析
1. 什么是测试需求？
确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。
2. 为什么要做测试需求分析
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
3. 测试需求的依据与收集

测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软件的主要工作内容。
测试需求主要通过以下途径来收集：
1）  与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
2）  与客户或系统分析员的沟通。
3）  业务背景资料。如待测软件业务领域的知识等。
4）  正式与非正式的培训。
5）  其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。
4.测试需求的分析
目前不少的书籍与网站资料开始重视测试需求的分析，同时也提出了一些测试需求分析的方法。这里也提出一些自己的看法。
测试需求需要考虑几个层面的因素：
第一层：测试阶段。系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能，那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余，可不再重复测试。而在验收测试阶段，更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能，以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试，不过也是见仁见智的做法，要看测试管理者对测试策略与风险的平衡能力了。
目前，大多数的测试都会在系统测试中完成，验收测试只是对于系统测试的回归。此种情况也是合理的，关键看测试周期与资源是否允许，以及各测试阶段的任务划分。
第二层：待测软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。
第三层：测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南，那些已经是很好的测试需求参考了，在此仅列出业务流的测试分析方法。
任何一套软件都会有一定的业务流，也就是用户用该软件来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：
1）  常用的或规定的业务流程
2）  各业务流程分支的遍历
3）  明确规定不可使用的业务流程
4）  没有明确规定但是应该不可以执行的业务流程
5）  其他异常或不符合规定的操作
然后根据软件需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于软件的需求以及其他信息，来确定该场景应该导致的结果，便形成了软件业务流的基本测试需求。
在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流
程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。
5.测试需求的优先级

优先级别的确定，利于测试工作有的放矢的展开，使测试人员清晰了解核心的功能、特性与流程有哪些，客户最为关注的是什么，由此可确定测试的工作重点在何处，更方便处理测试进度发生问题时，实现不同优先级别的功能、模块、系统等迭代递交或取舍，从而缓和测试风险。
通常，需求管理规范的客户，会规定用户需求/软件需求的优先级别，测试需求的优先级可根据其直接定义。如果没有规定项目需求的优先级，则可与客户沟通，确定哪些功能或特性是需要尤其关注的，从而确定测试需求的优先级。
6.测试需求的覆盖率与覆盖程度
测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经跟测试需求存在了一对一或一对多的对应关系，可以说测试需求已经覆盖了该功能点，以此类推，如果确定了所有的软件需求都建立了对应的测试需求，那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%，但并不意味着测试需求的覆盖程度高。因为测试需求的覆盖率只计算了显性的（即被明确规定的功能与特性）因素，而隐性的（即没有被明确规定但是有可能或不应该拥有的功能与特性）因素并未计算在内。因此根据不断的完善或实际测试中发生的缺陷，可以对测试需求进行补充或优化，并更新进测试用例中，以此来提高测试需求的覆盖程度。

软件测试需求分析与定义方法

如何确定测试工作的范围？
对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。
那么到底该如何确定每次迭代是测试工作的范围呢？在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。
不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？一个实际的做法就是实现软件需求的版本化控制。既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。如何整理测试需求？
一旦当前阶段测试工作的范围确定下来，我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。整理测试需求的第一步，就是要“测试需求”。测试需求？对，不知道您是否想到，这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。
啊？这不是已经超出了测试工作的范围了吗？测试人员不是应该只关心软件的实现同需求是否相符吗？这样对测试人员要求未免太高了。——这是笔者过去同一些朋友谈到测试人员必须对需求进行检查时听到的一些不同的声音。　　在这里，首先要明确一个问题，就是软件测试的工作到底做什么？
在《软件测试》（ Ron Patton〔美〕，中文版由机械工业出版社出版，这本书是测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。
瞧！这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时候呢？
不知道大家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不同版本的软件工程方面的书中，对于软件缺陷都会有一段类似的描述：缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见下图）。这样看来，上面问题的答案自然就变成了“秃子头上的虱子”：从需求阶段开始！从“测试需求”开始！
注意，笔者这里的观点并不是说可以取消团队中的“需求评审会议”，这里并不存在冲突。笔者所希望讲述的，是测试人员应该如何看待软件需求，而并不是把“需求评审会议”所承担的责任揽到自己身上。?在论坛上也偶尔看到有的朋友问：如何测试需求呢？每次看到这样的提问，笔者内心就禁不住的一阵激动，因为一直以来，讨论这方面问题的朋友的确少之又少。
在笔者的实际工作中，对软件需求的检查包括两个方面的内容。
一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。
二是要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。当然，对于如何提高软件需求的质量，在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法，如果有兴趣，大家也可以找来参考。不过，如果您是一位测试者，那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试，慢慢的体会，一定会发现这种方法给您带来的好处。?现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约（以下简称SRS）和用例（以下简称UC）——当然，也可能是一份包含UC的SRS。通过对SRS和UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测试需求中最基本的一部分。
至于测试需求的表现形式，笔者认为大家都可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需求中，用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。
另外，大家也可能注意到了，在软件开发过程的这个阶段，通常是没有用户界面（以下简称UI）可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分，但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求，将是完全基于业务的，而并不包括基于UI的那部分规则，是同软件的最终具体实现相独立的。
随着开发工作的继续，开发部门的架构设计文档和详细设计文档也将陆续提交，这时候，我们可以根据设计文档来对已有的测试需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有同SRS或UC中已经定义的部分相符的内容，才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一方作为基准，决定是否需要调整软件需求，然后对测试需求进行相应的增补或者调整。比如对于一些算法，需要考虑设计文档中定义的，同系统实现相关的那些计算公式，是否同软件需求中描述的算法表达的是否是同一个意思？而对于一些约束或者业务规则，设计文档中描述的是否同需求中的相应部分一致？呵呵，看完上面这部分内容，恐怕又有一部分朋友晕倒在地了，而没有晕倒的那部分朋友也要提出异议：啊？！你这不是又包含了对开发人员所作的设计工作的检查吗？！刚刚让我们检查需求，现在又让我们检查设计，真的把我们当成全才了！没办法，为了让软件交到我们手上的时候只包含尽量少的缺陷，大家只能再辛苦一下了。我们的工作不应当仅仅限制在软件交付后尽力找到存在的缺陷，而更应该努力及早发现软件缺陷出现的苗头，尽量预防缺陷的出现。虽然并不是说在所有的团队中都应该由测试人员承担“测试需求”和“测试设计”的工作，但是测试人员对这些工作起到的作用，是其他团队中的其他角色所无法替代的。开发部门完成编码实现工作，提交供内部测试的应用程序时，测试人员手头上应该已经准备好了绝大部分测试用例和测试数据，测试部门将开始执行测试。通常在我们执行测试的过程中，即使我们已经从“通过测试”和“失败测试”两个不同的角度准备了非常充分的测试用例和测试数据，但总是有些缺陷的出现是出乎我们意料的，或者说是已有的测试需求和测试用例未能覆盖的。那么，对于这部分缺陷，也应当添加到测试需求中，并设计相应的测试用例，以便于下次版本迭代时进行参考。OK，相信说到这里，各位看客也应该可以理解我的观点了：对于一个长期发展的团队或者持续开发的产品，它的所有东西都是要不断积累的、不断迭代的。无论对于软件需求还是测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间，也是不断迭代和积累的。