如何整理测试需求

《如何整理测试需求》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、如何整理测试需求？软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。　　一旦当前阶段测试工作的范围确定下来，我们就可以开始考虑测试需求的整理——也就是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。整理测试需求的第一步，就是要“测试需求”。测试需求？对，不知道您是否想到，这里的“测试需求”中的“测试”是一个动词，指的

2、是对软件需求本身的检查。　　对于软件缺陷都会有一段定义：缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍。　　注意，笔者这里的观点并不是说可以取消团队中的“需求评审会议”，这里并不存在冲突。笔者所希望讲述的，是测试人员应该如何看待软件需求，而并不是把“需求评审会议”所承担的责任揽到自己身上。?在论坛上也偶尔看到有的朋友问：如何测试需求呢？每次看到这样的提问，笔者内心就禁不住的一阵激动，因为一直以来，讨论这

3、方面问题的朋友的确少之又少。在笔者的实际工作中，对软件需求的检查包括两个方面的内容。一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求？我们的需求人员是否真的可以正确的理解用户的需求？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？有没有一些被用户认为他们过去使用的软件已经提供了相应的功能，所以认为我们也应当提

4、供，而没有提出来的？关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了——既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。　　要保证软件需求的可测试性。对于“可测试性”，笔者的概念是：对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个

5、可以重复的过程来对这个明确的结果进行验证。说的具体一点，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必

6、要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。当然，对于如何提高软件需求的质量，在网络上或者已经出版的书刊中都已经有了很多更加具体、实用的方法，如果有兴趣，大家也可以找来参考。不过，如果您是一位测试者，那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试，慢慢的体会，一定会发现这种方法给您带来的好处。?现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约（以下简

7、称SRS）和用例（以下简称UC）——当然，也可能是一份包含UC的SRS。通过对SRS和UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测试需求中最基本的一部分。　　至于测试需求的表现形式，笔者认为大家都可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需

8、求中，用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。　　另外，大家也可能注意到了，在软件开发过程的这个阶段，通常是没有用户界面（以下简称UI）可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分，但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求，将是完全基于业务务的，而并不包括基于UI的那部分规则，是同软件的最终具体实现相独立