RUP测试过程实践(2)

　　相信看到这里，已经有些朋友在想：这些问题也不是很难啊，在RUP对测试过程的描述中都已经说的很明白了啊。软件测试工作必须要通过计划测试、设计测试、实现测试、执行测试、评估测试几个阶段来完成。其中计划测试阶段需要制定测试计划、整理测试需求;设计测试阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求;实现测试阶段要根据测试用例实现具体的自动化脚本或者手工的操作步骤;执行测试阶段则通过自动化测试工具或人手工来执行那些自动化或手工脚本;最后的评估阶段则要对软件的质量和测试工作自身的质量做出一个客观的评价。RUP中还有详细的工作指南和文档模板呢!

　　对，上面所说的这些都没有错，RUP中对于软件测试过程的描述要比笔者上面这段文字详细也生动得多。但是，我们同时也可以看到，RUP中描述到的，更多的是关注于过程的管理，或者更准确的说，RUP是在为我们提供一个大的方向，是一个稳定的、具有指导作用的框架，而不是一些具体的、涉及到操作细节的方法。这也是为什么很多朋友通读了RUP中关于软件测试的部分，但是一旦实际应用仍然找不准方向的原因。笔者今天希望同大家讨论的，则恰恰是这样一些在实践RUP测试过程时，从实际工作中总结出来的工作方法和经验。 对于测试过程方面的规范和一些基本概念， RUP中已经讲的很详细了，笔者在此也就不再赘述，有需要的读者请参照RUP中的相关部分。本文中所关注的内容包括：

　　1.在计划测试时，如何确定测试工作的范围和如何整理测试需求;

　　2.设计测试用例时，应该如何把握测试用例的粒度;

　　3.如何平衡测试用例的可用性和可维护性;

　　4.如何通过逆向的测试数据分析方法来保证测试用例的有效性和减少测试工作中资源的浪费;

　　5.一个简单的但有实际意义的例子将展示如何将笔者的方法应用到测试过程中。

　　这里要事先声明一下，笔者工作三年来，不管是开发还是测试，工作内容始终是围绕着信息管理系统相关业务展开的，而对于测试工作，也一直局限于在系统测试阶段通过手工方法和简单的利用一些测试工具特性进行黑盒测试。因此，在本文下面描述的内容中，难免受到客观环境和笔者个人经验的影响。也正因为如此， 笔者不保证本文中方法和观点适合于所有组织和个人的软件开发过程 。只是希望能够借此为大家提供一种思路，帮助更多人进行个性化的 RUP测试过程实践，共同提高软件测试行业的水平。 另外，本文中使用到的例子，均为笔者的一些假设，如果侵害到任何第三方组织或个人的利益，实属巧合，请通过 E-Mail通知笔者，笔者将在今后再次发布本文时做出相应的调整。

　　如何确定测试工作的范围?

　　对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布(即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本)。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。

　　那么到底该如何确定每次迭代是测试工作的范围呢? 在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。

　　不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢?或者说通过什么样的方法可以改善我们上面提到的那些问题呢? 一个实际的做法就是实现软件需求的版本化控制 。既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。

原文转自：http://www.uml.org.cn/Test/200908281.asp