可跟踪性能够收集关于单独的需求和受到需求变更影响的系统的其它部分,包括设计,编码,测试和帮助镜像等等.当测试人员知道需求发生变更时,他们能够对受到影响的部分作出相应的调整和修改.

当个别的需求能够进行评审时,就要尽可能的使用上述的特性对需求进行测试和验证.捕获与需求相关的缺陷,尽早的识别出它们,能够防止错误的需求产生与其一致的设计和实现,那时发现和改正缺陷是非常困难和代价昂贵的.

开发软件需要好的组织,计划,跟踪和测试的每个特性, 通过这些步骤之后这一系列特性都比略述了和量化了.

第三种．需求完成后尽可能早的设计测试流程

   就像软件开发工程师根据需求文档来设计详细文档一样，测试部门也同时根据需求文档来设计测试流程。在有些公司，测试流程的制定往往被推迟到软件已经集成并交付给测试部之后才开始，这是由于一方面是没有时间，另一方面是没有适合测试部制定测试流程的特定的需求文档。这种做法会产生下面这些问题：需求文档在软件开发后期有可能发现遗漏或者错误，软件实现出现了不能满足需求的问题，不可测试性和产生不完善的测试流程。

测试流程的设计在需求阶段就实施，不要等到软件开发阶段才开始，这样做可以给需求说明文档的开发过程带来好处。在测试流程的开发过程中，当测试人员在一定的层次上试图通过使用一系列的输入数据与系统进行交互时，需求文档中的一些观点，遗漏的地方，不正确的流程和其它错误的地方都有可能被发现。在这个过程中，需求就要满足各种各样的场景，同样通过交互可以明确所有场景中的某一清晰的路径。

如果需求中的一个问题没有被发现，那么需求中就需要去对这个问题进行重新设计。在开发过程中越早的进行这样的修正不会相互作用，这个修正也可能非常小的影响软件的设计和实现。

在第一条中我们已经提到过，早期发现的错误修改的成本都较低。如果一个缺陷是在开发过程的后期才被发现，所有风险承担者都必须修改需求，设计和代码，这将影响到预算，进度，不家可能影响员工的士气。然而，如果缺陷是在需求阶段发现的，修改它是一个很简单的事情，只要修改需求文档就行了。

参考验证需求的可测试性，通过测试流程的制定来识别出需求中的错误和遗漏部分。如果没有足够的信息或者说明书中提供的信息太含糊不清了，不能使用它来创建完整的测试流程和使用相关路径的相联系的测试用例，那么说明书就可以被认为是不可测试的，并且它并不适合软件的开发。对一个需求的测试能否制定是一个有价值的检查和需求改进完善过程中的一部分。不过也存在特例，需求也许不能立即使用有序的或手动的执行测试来被验证。这种例外需要简要的说明。例如：实现一个像“所有的数据文件要使用记录在案的方式保存三年”的需求就不能立即的被验证。然而，它就需要改正，持续和跟踪。

如果一个需求不能被验证，那么也就不能保存它能够正确实现。制定出包含数据输入的测试流程，一步一步的验证需求，了解每一个相应需求的预期输出，通过确认重要的需求信息没有遗漏能够保证需求的完整性，不要使需求复杂化，甚至不能够正确的实现和不可测试。越早的制定测试流程能够更早的发现需求中不可验证的问题。

在软件已经集成并交付给测试部之后再制定测试流程，要承担测试流程制定得不完整的风险，因为完成产品的测试周期的紧张的时间压力。这表现出以下几个方面：例如，测试流程也许缺少整体性，或者它没有制定全面，遗漏了一些路径或者可能产生测试结果的不同性的数据。结果是一些缺陷没有被发现。或者早期的需求描述得不够完善，没有提供必要的测试流程的定义，或者非常合适的软件开发过程。不完善的需求往往导致不完善的实现。

测试策略的制定可以以早期的软件需求的可测试性的评估为基础。当对需求的可测试性进行评审进，测试人员也许认为使用捕获或者回归工具是很好的方法，或者一些测试允许使用自动化测试方式。早早的确定这些有助于有充分的时间来评审和实施自动化测试工具。

还有另外一个例子：一些与需求相关的复杂的和各种的计算也许更适合使用用户测试驱动或者特殊的脚本来测试，在早期的评审阶段，这些方法就能够确定。在测试开始前测试驱动的开发和其它一些像测试准备活动需要额外的时间。

测试流程在需求定义阶段就制定带来了一些额外的负担，包括依据需求来制定测试流程的优先级，分配足够的人员和理解测试策略。这些通常都是代价很高的，如果可能的话，把每一个需求的测试流程都立即制定出来，这是因为时间，预算和人员的限制。理想状态下，需求和专业知识的专家和测试部门共同负责作为需求定义一部分的测试场景的创建，包括场景的输出（预期输出结果）。

测试流程的制定必须以迭代的实现计划为优先次序。如果存在时间限制，测试工程师第一个实现的应该是需求的测试流程的制定。他们可以制定出一个针对所有需求的测试流程的草案，以后再慢慢完善。

需求通常通过循环的评审和分析来达到最优。非常普遍的是新的需求的细节和场景表面的分类都是在设计和开发阶段。完美主义者也许认为所有需求的细节都是在需求开发阶段标识出来的。然而，实际上是项目期限的限制要求我们尽早的开始开发，完成需求近乎完美是极其罕见的。如果在开发过程中需求逐步完善，那么相应的测试流程也要做相应的完善。这就需要任何改变都要相互一致：他们可以认为是活着的文档。

在需求阶段，包括需求和测试流程都需要一个完善的过程，这就要求测试设计者和风险承担者做出有效的管理。参考第四条关于需求变更时所有风险承担者之间交流的重要性。

第四种．确保需求变更的交流性

测试流程是建立在需求的基础上，当需求发生变更时，应保证测试组成员都被告知了，这是很重要的。这看起来是很显然的，可是，令人惊讶的是测试流程在执行的时候往往和软件的实现相冲突，这是由于需求发生了更新，测试人员要对开发和执行测试流程负责任，而很多时候需求发生变更时去没有通知他们，这就导致了缺陷的错误报告和浪费必须的调查和保贵的时间。

下面有一些原因可以解释这个过程的减弱，如下：

1．               没有文档的需求。像产品或项目经理、客户或者需求分析员，这些人来指导开发人员去实现功能的改变，去没有和其他风险承担者达成一致，而且开发人员实现这些变更没有进行交流和保存成文档。这个过程就需要开发人员不论怎样或不论何时，当需求发生变更的时候要把它清楚的保存起来。通常通过使用变更控制簿，工程评审簿和下面讨论的其它相似的机制来处理。

2．               过期的需求文档。对于测试人员来说，另一个缺陷是部分的或者馈乏的配置管理会使测试人员使用版本过期的需求文档来制定测试计划和流程。更新需求时需要文档化，把它放入到配置管理中并且和相关人员进行交流。

3．               软件缺陷。尽管需求文档和测试文档都非常正确，可是开发人员也许不能够正确的实现需求。

  在最后一条中，必须写缺陷报告。然而，如果需求变更过程没有被执行，那么很难去澄清上述的场景是否真的会发生。问题是发生在软件、需求和测试流程中，还是所有的过程中？为了避免陷入臆测之中，所有的需求变更都必须公开的进行评估，达到一致的同意和所有风险承担者之间的交流。

  如果需求需要变更时，变更过程会引起连锁反应，影响到设计，编码和其它相关的文档，包括测试的相关文档。为了有效的管理这个过程，任何变更都应该置于配置管理的基线和版本中。

  变更过程的概括是何时提出来的，如何提出来的，是谁提出来的和什么地方提出来的。这个过程需要指明的是变更请求可以在生命周期的任何阶段提出来，在任何类型的评审，走查，或者需求、设计、编码、缺陷跟踪，和测试活动中，或者其它阶段。

  每一个需求请求都要经过变更控制会议通过并且使用变更请求表保存成文档，变更请求表是方便变更请求的包括必须信息的列表。建立变更控制会议有助于确保需求的任何变更和其它的变更请求符合指定的流程。变更控制会议检验了变更请求文档是合适的，已评估的和一致同意的；它所影响的其它文档（需求，设计文档等等）都被更新了的；并且所有风险承担者都被通知了。

变更控制会议通过包括来自产品管理、需求管理、QA人员，同样还有测试经理和配置经理的代表。变更控制会议必须建立在必要性基础上。所有风险承担者都需要依据优先级、风险和相关变更建议的均衡来评估地面需求变更。

分析提出的变更相关的和关键的影响是可执行性。例如，需求变更可能影响到整个测试文档，需要来增加测试环境的主要部分和花费数周的时间来扩充测试任务。或者由于影响到整个自动化测试系统，执行步骤也需要作相应的改变。在变更被通过之前，这些影响必须能够识别、交流和公布出来。

变更控制会议确定了变更请求的有效性、影响、必要性和优先级（例如是否要立即执行或者是否作为增进的文档保存到项目的知识库中）。变更控制会议必须确保变更建议、相关的风险评估和决策决定过程是可文档化的和相互交流的。

必须认识到任何变更建议的所有部分都会有助于风险分析和变更的减弱。一个有效的方法是使用需求管理工具来保证它的实施，和维护测试流程中的需求的可跟踪性一样，需求管理工具被经常用来跟踪需求变更的情况。如果需求发生变更时，变更就应该在需求管理工具中得到反映和更新，并且工具应当标记相影响的测试产物（和其它影响元素，例如设计、编码等等），因此相应的各自的部分能够更新他们的产品。

  变更信息通过使用需求管理工具来管理，使得测试人员能够像变更对测试相关产物或测试进度表的影响一样，再次评估需求变更的可测试性。受到需求和实现变更影响的测试流程必须能够再次访问和更新。以前确认的缺陷也必须重新评定，以确定需求的变更是否使它们变成作废的。如果是脚本、测试驱动或者其它已经创建的测试机制，它们也要应做相应的更新。

一个明确的方便需求变更交流的和考虑到有效的测试计划的过程，对项目的效率是非常关键的。

今天读了一下Elfriede Dustin的<<Effective Software Testing:50 specific ways to improve you testing>>,现在把我的感受写在这里,供大家学习,错误的地方还请大家多多指正啊!谢谢大家提出批评!

请勿转载,谢谢合作!

有效的软件测试----50种途径改进你的测试

       第一部分    需求阶段

最有效的测试开始于一个项目的开始阶段,也就是在编程的很早之前就开始做测试.需求分析第一次验证的时候,这样,在以后的项目阶段中,测试可以专注于保证程序代码的质量.在软件生命周期中,昂贵的成本可以通过与减少需求阶段的错误达到最小化,更优于详细设计和代码书写的时候发现问题.

需求说明文档对一个软件项目或者系统来说,描述其功能基本上是越详细越好.与需求的提供者之间的沟通是在需求开发阶段的最大的风险之一,需求说明文档应当把信息陈述的准确和清楚,让每一位读者都能够从同一个角度来理解.

如果需求达到一致性的程度,那就是在需求开发阶段,要尽可能的使风险承担者有效的参与需求的开发和收集.尽量使需求说明文档可视化,可以通过对风险承担者进行详细的提问来验证和阐明需求的细节.各种不同的需求测试在应用中应该保证每个细节都是相关的,而且每一个人都能理解它所阐述的意思.

第一种  在最开始阶段就确保测试人员的参与

   在软件生命周期的开始阶段,测试人员就应该参与,这样可以使他们更准确的理解他们要测试的产品,可以帮助风险承担者开发出可以验证的需求说明文档.

   在缺陷还没有渗透到开发的后期阶段中的时候,缺陷预测是一个常用的技术和方法来帮助我们发现和避免错误, 在需求阶段,缺陷预测是最有效的,解决需求变更中的缺陷带来的影响和成本是最低的:仅仅是对需求说明文档进行修改或者可能修改测试计划.如果测试人员或者风险承担者在软件开发周期的早期阶段就参与进来,他们可以有助于发现或识别出遗漏的,矛盾的和模糊不清的地方等等,可以影响需求说明文档的可测性,正确性和其它品质.

   如果一个程序或者方法的设计可能是它的功能的执行能够被测试,预期结果是可以预料,输出结果是可见的或者可验证的,那么这个需求设计的就是可测试的.

测试人员应该真实的理解需求说明文档,这样他可以更好的设计出测试计划,设计,流程和用例.在项目生命周期中,测试部门的早期参与可以减少对功能的使用的困惑.另外,早期的参与可以使测试人员获得软件的更多的方面的内容,包括对最终用户哪些是最主要的方面或者哪些地方是高风险的.这些知识应该让测试人员更早的知道,测试人员应该专注于软件的哪些方面,避免重复测试很少使用的地方或者很少测试最常用的地方.

有些测试组织认为测试人员仅仅是需求或其它软件开发工作的产品的使用者,要求他们在软件已经开发完成并交付给测试人员后去学习软件的需求和相应的领域知识,而不是在软件开发的早期阶段就让测试人员参与进来.这种做法在小型项目中也许可行,但是是大型的复杂的项目中,如果他们交付给测试人员的软件是在已经通过需求,分析,设计和其它一些软件实施后的,再去期待测试人员去发现重大的错误,这是很不现实的.拿软件的输入输出作为例子,测试人员需要更深入的知识,这些知识仅仅是通过在对使用功能说明书的过程中,运用思维能力对其的理解.这种理解不仅可以增强测试流程的的质量和深度,而且可以为测试人员提供关于需求的反馈信息.

在软件生命周期的早期发现的缺陷,修复的成本也就很低.下表可以显示出在不同阶段发现缺陷时修复的相应成本.

注:我做测试也已经8个多月了,在我的实际的测试工作中也存在一些问题,有一次我在向开发人员要新增的一个项目的功能说明文档的时候,那位仁兄说:"你要那个干什么? ",我当时就木在那里了,不知道我该说什么,幸好我当时没向他要需求说明文档,不然的话还不知道会出现什么呢.一个项目的测试尤其是到了项目的后期再进行测试,测试人员没有参与到需求的开发阶段,那他只能从开发人员的早期书写的需求和功能文档中来学习项目.项目的持续时间很长,其间开发组也更换了一些员工,PM对项目的文档管理不是很完善,公司的软件的流程和QA的控制也不是很好的话,这时候的测试人员是最可怜的,他所看到的文档说不定是N年前写的,这期间所有的变更没有记录下来.光是看文档那是肯定不行的,去和开发人员交流的时候也会经常听到他们说:"这是XXX在的时候写的,我也不是很清楚具体内容,你去问问其它人吧"等等类似的话语,这时候只能对着文档和已经做出来的软件做测试,效果怎么样?大家自己清楚.

Elfriede Dustin教我们做的第一条就是测试人员在立项之后,需求开始之初就参与到项目中,对需求进行测试评估,这样可以更加完善需求,不会到了软件开发后期总是出现需求的变更,我所在的项目组就是出现很多的需求变更,一个代码在W行左右的变更至少也需要2-3M才能完成,成本就可想而知了.