软件测试实践之测试需求与测试用例.pdfVIP

软件测试实践之 测试需求与测试用例 陈雷 关键词：测试需求 测试用例 测试过程 本文是一位一线软件测试工作者对自己两年工作经验的总结，文中介绍了有关测试需求 整理和测试用例设计的一些方法和建议。这些方法和建议已经在实践中被证明可以用来提高 测试团队的工作效率，也许它们并不是完全适合于您的工作，但是可以为您的工作提供一种 新的实践思路。 这篇文章并不适合从未接触过软件测试工作的朋友，希望您在阅读本文之前，已经掌握 了软件测试的一些基本概念，并作过一些实际的软件测试工作，当然，最好也对RUP 中的 测试过程部分有所了解。另外，本文中将不会涉及到同测试工具相关的话题，有关测试工具 的引入和实施，笔者会在今后的文章中进行讨论。 测试需求整理的三板斧 测试需求的确定将为我们制定测试进度时间表、分配资源以及确定某个阶段测试工作是 否完成提供一个可供衡量的标准。当然，还有更重要的一点，已被确定的测试需求是我们进 行测试用例设计和考虑测试覆盖率的依据。 1. 确定测试工作的范围。 在很多实际工作中，因为受到一些外界因素的影响，比如市场需求的变化，既定发布时 间的到来，团队内并发性工作导致的资源紧张等，使我们不得不考虑对软件质量的“适度” 要求。在对软件测试的投入成本与收益做出衡量后，就需要决定是否在测试对象的确定和测 试类型的选择方面做一些增减。而测试对象的确定和测试类型的确定，也就是某个阶段测试 工作范围的确定。这里之所以提到测试工作范围的确定，是因为它将直接影响到测试需求的 确定。 当然，如果不考虑上面所说的那些因素，我们可以简单的把某个阶段测试工作范围的确 定等同于软件需求的确定。不过现实中的情况是软件需求在开发过程中会经常性的发生变 化，有时甚至在软件最终发布之前才能确定下来。我们又该如何根据频繁变更的软件需求确 定我们的测试工作范围呢？应该说要完成这样的工作是很困难的。但是我们可以通过其他的 方法来减少这种情况对工作造成的影响，比如采用软件需求的版本化管理。 这里所提到的“软件需求的版本化管理”，是指在一个软件产品进行一个新版本的迭代 时，要尽早的确定这个版本中所包含的需求，并同上个版本做出比较，哪些内容是新增的， 哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件 需求的涉众传达这部分信息。而如果在该版本的开发过程中出现需求变更的情况，则应该根 据市场策略、已公布的发布时间、客户需求、实现的代价和难易程度以及对现有工作的影响 等方面，由项目负责人对需求进行适度划分，明确哪些变更需求将对当前版本产生影响，哪 些变更需求由今后的版本负责处理。应对软件需求频繁变更的唯一方法是：早讨论、早决定、 早调整。 2. 整理测试需求。 测试需求的整理是要明确我们现在要“测什么”。在软件需求确定之后，就可以开始这 项工作了。 在一次迭代过程中的需求阶段结束时，我们手头上可以参考的东西，通常会有软件需求 规约（以下简称SRS）和用例（以下简称UC ）——当然，也可能是一份包含UC 的SRS。 通过对 SRS 和UC 的阅读，我们可以从文档对软件特性和业务流程的描述中获得对软件所 涉及的业务的一个基本的认识。比如用户的实际业务是如何进行的？多个业务之间是否存在 相互关系？在业务进行时是否受到一些条件的影响？等等。通过对这些业务的分析，我们可 以获得最初的一部分测试需求。你可以将测试需求定位在较高的层次上，也可以把你所能想 到的所有需要测试的内容都写下来，而并不一定是仅仅局限于对一个特性或一个由基本流同 某些备选流组成的场景的分析。这里强调的是基于业务的分析，换句话说，就是考虑在用户 处理实际业务时将会作些什么。 对于测试需求的表现形式，大家可以根据自己的需要来进行设计，使用电子表格还是文 本文档并不会影响测试需求的作用。只要在一条测试需求中，用容易理解的自然语言，清楚 的、明确的描述一项（也只应该有一项）需要测试的内容就可以了。 随着工作的开展，开发部门的架构设计文档和详细设计文档也将陆续提交。设计文档是 对软件需求中实际业务分析后得到的工件，文档中对于系统解决方案以及实现思路等方面的 内容，虽然更倾向于用计算机软件的语言来描述，但仍然可以从中发现同软件需求之间的紧 密联系。因此，我们可以通过对设计文档中这些特性的分析，来对已有的测试需求进行增补 或