【IT168 技术文章】
RUP（Rational Unified Process，Ratinaol 统一过程） 是rational公司提出的一套软件开发过程，目前最新的版本是2003。RUP的最大特点就是它提供了一套完整的软件开发过程框架，任何人或组织都可以根据自己的需要来对这个过程进行裁剪，并根据自身需要进行调整后使其成为个性化的过程。读者可以参考网络上流传的《RUP2000中文版》。 （ Rational以及 Rational Unified Process 均系 Rational Software Corporation 在美国和其他国家的商标或注册商标。）
有句老话说：万事开头难。说的是在做事情的时候，通常都是一开始觉得非常困难，但是只要上了道，入了门，就会越来越容易、越来越顺了。写文章也是如此。不过笔者这里说的开头难并不是不会写文章，而是专指不会写文章的开头部分。过去看到过的很多小说，无论是言情的或者武侠的，都会拿很长的篇幅出来作为“引子”，或者叫“楔子”，用来交待一些同小说相关的信息。而一部小说是否能够吸引读者，这部分内容也起了很大的作用。不过，笔者作为一个技术工作者，写的大多数都是技术文章，一般来说文章的内容、结构都是一早就想明白的，唯独这个开头，实在不知如何写起。不过想想也罢，既然不擅长这个，那就努力把内容写的详细、易懂一些，尽量让读者不会有上当的感觉吧。
软件测试作为一个独立的职位或者说行业，并不是软件业的新生事物，但的确是随着最近两年一些新的思想注入国内软件行业（比如敏捷开发过程、测试驱动开发等），才得以红火起来的——这一点，从相关书籍的出版和销售就可以看得出来，从事软件测试工作的人也渐渐多了起来。但是也因为是刚刚起步，同时国内大多数软件公司都还处在中小型开发团队甚至作坊式开发的层次，不可能提供太多的测试职位，想找到一些高水平并且富有经验的测试人员更是难上加难。这最终也就导致了国内大多数测试从业者都处在“初级阶段”这样一个结果。
笔者长期活跃在国内的几个比较知名的测试论坛，发现大家希望讨论的问题主要可以分为两种：一种是对于一些测试工作具体操作方法的提问，一种是对于测试工具使用的提问。总体看来，更多的问题集中在了后者。这似乎已经成为了国内软件业的通病，无论是开发还是测试，总希望可以通过某个工具或者语言来一劳永逸的实现某个理想。如果真的希望工具可以改变一切，那么这种愿望总是会落空的。而前者，大多是因为进入了一些刚刚开始重视软件测试的中小型软件公司，而公司的开发团队中负责软件测试的可能只有一两个对软件测试一知半解的新手，当公司需要开展某些方面的测试工作时，缺少这部分相关经验的朋友变选择了通过网络求助。
测试工具的应用，的确可以提高工作效率，而对于测试工具方面的提问，本来也是无可厚非的，但是在笔者的实践中，如果希望提高一个团队的工作效率和改善工作效果，关注于过程和方法要远远好于关注工具。测试工具的学习、引入和使用，本身就是一个需要消耗大量资源的过程，而且对于工具的选择和引入工具时机的选择也是非常关键的，如果负责这项工作的并不是一位在软件行业沉浸多年，有着丰富测试经验并熟知开发过程的资深人士，那么开发团队将为此承担巨大的风险。即使成功的引入了测试工具，工具本身可以带来的效率的提高也不是在短期内可以体现的。在这里，笔者希望刚刚或者正在准备组建测试团队的软件公司在考虑测试流程的搭建和测试工具引入时，不要给刚刚进入测试行业的朋友太多压力，因为这两项工作都不仅仅同软件测试本身相关，同时也会涉及到项目管理、开发过程方面的内容。轻易的做出一个决定只会对将来在团队中测试工作的开展带来不利的影响。
在这篇文章中，笔者不打算对测试工具方面的问题提出任何建议，而将对网络上大家关注的测试过程和测试方法方面给出一些具有实际参考价值的经验。
测试工作应该什么时候开始？ 测试用例是不是一定要写？如果写，应该详细到什么程度才会比较好用又容易维护？ 什么样的测试用例才是好的测试用例？测试用例如何覆盖测试需求？测试需求和测试用例的关系是什么？怎么样保证测试需求的整理和测试用例的设计不会浪费太多的人力或其他资源？……
这些问题可谓是老生常谈了，在论坛上、MSN上，或者邮件中，也经常会有朋友问到笔者一些这方面的问题。相信不管是测试新手，还是从事测试工作有一段时间的朋友，都会在工作中不得不经常的要考虑，这些问题到底有没有一个相对明确的答案呢？
相信看到这里，已经有些朋友在想：这些问题也不是很难啊，在RUP对测试过程的描述中都已经说的很明白了啊。软件测试工作必须要通过计划测试、设计测试、实现测试、执行测试、评估测试几个阶段来完成。其中计划测试阶段需要制定测试计划、整理测试需求；设计测试阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求；实现测试阶段要根据测试用例实现具体的自动化脚本或者手工的操作步骤；执行测试阶段则通过自动化测试工具或人手工来执行那些自动化或手工脚本；最后的评估阶段则要对软件的质量和测试工作自身的质量做出一个客观的评价。RUP中还有详细的工作指南和文档模板呢！
对，上面所说的这些都没有错，RUP中对于软件测试过程的描述要比笔者上面这段文字详细也生动得多。但是，我们同时也可以看到，RUP中描述到的，更多的是关注于过程的管理，或者更准确的说，RUP是在为我们提供一个大的方向，是一个稳定的、具有指导作用的框架，而不是一些具体的、涉及到操作细节的方法。这也是为什么很多朋友通读了RUP中关于软件测试的部分，但是一旦实际应用仍然找不准方向的原因。笔者今天希望同大家讨论的，则恰恰是这样一些在实践RUP测试过程时，从实际工作中总结出来的工作方法和经验。 对于测试过程方面的规范和一些基本概念， RUP中已经讲的很详细了，笔者在此也就不再赘述，有需要的读者请参照RUP中的相关部分。本文中所关注的内容包括：
1.在计划测试时，如何确定测试工作的范围和如何整理测试需求；
2.设计测试用例时，应该如何把握测试用例的粒度；
3.如何平衡测试用例的可用性和可维护性；
4.如何通过逆向的测试数据分析方法来保证测试用例的有效性和减少测试工作中资源的浪费；
5.一个简单的但有实际意义的例子将展示如何将笔者的方法应用到测试过程中。
这里要事先声明一下，笔者工作三年来，不管是开发还是测试，工作内容始终是围绕着信息管理系统相关业务展开的，而对于测试工作，也一直局限于在系统测试阶段通过手工方法和简单的利用一些测试工具特性进行黑盒测试。因此，在本文下面描述的内容中，难免受到客观环境和笔者个人经验的影响。也正因为如此， 笔者不保证本文中方法和观点适合于所有组织和个人的软件开发过程 。只是希望能够借此为大家提供一种思路，帮助更多人进行个性化的 RUP测试过程实践，共同提高软件测试行业的水平。 另外，本文中使用到的例子，均为笔者的一些假设，如果侵害到任何第三方组织或个人的利益，实属巧合，请通过 E-Mail通知笔者，笔者将在今后再次发布本文时做出相应的调整。
如何确定测试工作的范围？
对于一个存在生命周期的软件产品来说，它的开发和测试往往都不是一次性的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代，我们的测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。
那么到底该如何确定每次迭代是测试工作的范围呢？ 在笔者的实践中，通常把测试工作范围的确定，等价的认为是软件需求的确定。
不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？ 一个实际的做法就是实现软件需求的版本化控制 。既然说到了这里，就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。
