这是2003年公司进行过程改进时的一篇讨论稿

??现在对于测试方面，首先就是一些工具的引入。这里包括：
??1.TestManager。现在主要是用来管理测试用例和测试执行还有测试日志的一些东西，还有更多的功能现在还没有研究。
??2.ClearQuset。自从引入后效果比较好，这次主要是考虑对于一些流程细节的调整。
??3.Robot。将作为近期的一个重点，希望可以通过使用自动化脚本来提高测试效率。
??4.Manual Test。也是Rational的一个测试工具，主要考虑用来代替word文档，用来书写那些使用手工方法进行测试的测试用例。
??5.RequisitePro。进行测试需求的管理。关于测试需求的内容会在下面具体说明。

??对于测试同需求、测试同开发之间的关系，现在同需求方面的思路已经比较明确，现简述如下。
??首先是软件或者产品需求同测试需求的关系。测试需求是在Rational中的测试流程中推荐的一个活动，但是在Rational中也没有说得太具体。现在的理解是类似与软件需求的作用，明确要作些什么，并确定优先级。而之所以要提出测试需求的概念，是考虑在设计测试用例时，如果多个人同时进行，就可能因为对需求的理解不同而产生不同的看法，而可能漏掉一些测试内容。比如一个“用户登录”特性，这个特性描述如下：用户登录：用户可通过用户登录来验证该用户的合法性，合法用户才能够登录到系统中。
??那么上面这个特性有两个地方需要测试，可以产生两条测试需求:
??1.检查对于用户合法性检查功能是否正确实现;
??2.检查系统对于用户登录操作是否正确相应.
??这里需要一个检查标准，就是怎样才能算是用户登录操作的结束。对于第一条测试需求将使用不同的用户名和密码进行验证，第二条则会使用不同属性的合法用户进行验证。也就是通过两条测试需求来保证对一条软件需求的覆盖，在设计测试用例的时候就参照测试需求来进行。
??上面的例子是一条软件需求对应多条测试需求，当然，可能大多数软件需求同测试需求是一一对应的关系，而多条软件需求对应一条测试需求的情况也可能会出现。
??对于这个问题的解决方案如下：
??在RequsitePro的需求项目中添加一种需求类型——可以定义为TsetRequirement（TR），每条测试需求的From属性中包含一条或多条软件需求。当需求发生变更是，可以直接通过视图查找到可以连接，来对测试需求进行修改。完成测试用例的设计后，在TestManager中建立测试用例同需求的关联时直接关联到测试需求上——当然，也可以同时关联到软件需求。这样在需求发生变更时，测试人员通过视图对存在可以连接的测试需求进行修改，然后在TM中找到测试需求变更后影响到的测试用例，再进行测试用例的修改，保证测试用例对软件需求的有效性。
??现在有几个问题还不能明确，也是需要进行试验的一个主要原因，就是如果单独维护测试需求，工作量到底有多大？当发生需求变更时，同时维护测试需求和测试用例是不是现实？如果软件需求同测试需求之间超过80％都是一一对应的关系，那么增加一个测试需求的维护是否有必要？
??当然，考虑测试需求的维护还有另外一个想法，就是测试优先级的考虑。但是如果测试需求的维护只有这一个功能，那么倒可以放到软件需求中来完成，增加两三个字段就可以解决了。

??上次需求、开发、测试三方会谈的时候，讨论到的一个问题是测试工作的开展以需求为原则，测试用例的设计也只以需求为标准。其实这段时间考虑了一下，本身测试用例也是动态的，在项目过程中会不断的增补、修改，所以现在测试用例设计的来源已经变得比较宽泛了。初期在需求工作时就开始进行测试用例的设计，但是在开发进行架构和详细设计的过程中也会根据设计来对测试用例进行增补和完善；而即使在测试版本交付测试后，在执行测试的过程中仍然会对测试用例进行增补和修改。所以测试用例已经不仅仅同需求相关，而同时也同设计文档、交付的产品相关。那么现在又有新的问题了，就是测试同开发怎样进行交流？当需求变更后，设计发生改变，测试也会根据需求和设计进行调整，那么需求可以通过RequsitePro来获得，设计通过什么来获得呢？如果测试可以通过“需求——>测试需求——>测试用例”的方式来进行跟踪，那么开发能否有一个类似的方法来进行管理呢？从测试角度来看，非常希望能有一个方法可以将测试和开发都关联到需求上去，建立一个沟通的结点。

??还有很多操作上的细节问题，现在也考虑的不周全，所以希望有一个需求、开发、测试联合进行的试验项目，我们大家可以一起来尝试一下怎样协调各方的工作。

????????????????????????????????????????? 测试部：陈雷