模板
教程
环境
性能
功能
管理
TMap和Rational统一过程(6)
通过设计基于类描述的测试用例，一个人能够在较深的级别上测试系统。实际上，许多内部对象不能之间被控制，这使得单独测试它们不太可能。然后这些定义的测试用例只能通过将它们与测试用例合并来测试。
除了以上提到的测试规格说明技术之外，检查单也被使用，它是基于经验和系统的许多值得测试或复审的方面的。最终，测试基础的不同的未文档化的变量，像最终用户的知识和经验，可以用来补足文档化的内容。
测试人员在开发过程早期所涉及的内容，特别是在开发人员和最终用户之间的沟通过程中，在迭代系统开发中是及其重要的。也允许测试人员评估非文档化的协议。
基础结构
TMap的基础，“基础结构”，涉及到测试环境、工具和工作空间。对于一个RUP项目中的一个测试过程，只有工具支持是特定的，其它两个都是“一切正常”。IBM Rational软件提供几个工具支持测试过程，如早先的“系统测试”一节中所描述。然而，测试自动化不是其自己的一个目标。特别是，使用记录和回放工具--如Functional Tester 或 Robot--的功能验收测试的自动化需要小心地被考虑。以下考虑对这种情况有影响：
在软件以较小的方式经常变更，并且新的发布版本经常交付时，回归测试的自动化就十分重要了。
测试的自动化要求开发期间的一个适度稳定的系统。如果不是这种情况，测试脚本就需要一次又一次地构建。稳定性会受到影响，例如，用户界面的易变性和项目或迭代中系统分解的质量。
在迭代中测试的时限决定是否有充足的时间用于测试自动化。
是否能找到足够的(高级)测试自动化人员?如果没有，计划能提供足够的时间培训人员吗?
维护组织能够接收自动化测试集吗(在一个稍后的时间)?
验收测试
要弥补RUP中验收测试(AT)指南的不足，可以建议可能性：
将验收测试组织和结构化为TMap所描述的。
将验收测试与系统测试按照TMap描述的组织在一起，按本文档所注明的那样。
在第一个场景中，验收测试是作为一个项目独立实施的，其是独立于其它RUP项目被执行的。一个设计良好的测试可以提供足够的保证，系统可以按照产品的质量验收。然而，这种类型的一个项目会降低系统开发过程的快速和迭代特性。如果组织发现，将采取迭代化开发的系统直接产品化的风险太高，就可以找到选择这种方法的原因了。在第二个场景中，验收测试按照与RUP迭代中的系统测试相同的方式来执行。在这种情况下，系统开发过程的迭代特性可以被维护，并且测试被组织起来，也称为可能。
第三种组合是将验收测试和系统测试集成到一个集成测试级别(IT)。实际上，这个步骤有太多不合需要的结果和风险，许多测试的质量和覆盖度都不足。因此，这种选则就不推荐。所有这三种可能性的说明如图11。
图11：验收测试的三种可能性
选择的选项取决于具体情况。无论如何，主测试计划需要确保，系统测试和验收测试是有关测试覆盖的补充。这意味着，在测试覆盖中，不应当有任何不必要的覆盖或缺口。
回页首
参考文献
Copeland, L.,Use Cases and testing: Testing UML models, Part 1," 来自STQE Letter, 2002年6月，在 www.stickyminds.com
IBM Rational 软件(1997)，UML Summary 版本 1.0
IBM Rational软件，不同的RUP白皮书，www.rational.com
Koomen, T., (2002) Testen van iCBD, www.tmap.net
Koomen, T., (2003) Exploratory testing and TMap, www.tmap.net
Kruchten, P. (2000), The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, ISBN: 0-201-70710-1
Pol, M., R. Teunissen, E. van Veenendaal (1999), Testen volgens TMap, Tutein Nolthenius,Hertogenbosch, ISBN: 90-72194-58-6
Szymkowiak, P., Kruchten, P. Testing: The RUP philosophy, The Rational Edge, February 2003.
回页首
感谢
RUP2002版的产生得到了Sogeti工作组"TMap in RUP"的帮助。特别感谢Fedor Janssen, Richard Hakvoort, Loek Wilhelmus, Wim Bos, Andrsan Pelt, 和 Rob Baarda。Chris Dugardyn是IBM Rational的测试咨询师，Rabo的Cees Dulfer也提供了有价值信息。我也将感谢Sogeti的Mark Tolsma，在准备用于本文写作的材料上得到了他的帮助。
回页首
附录A：按照RUP和TMap的主测试计划
下表全面对比了RUP MTP和TMap MTP。
回页首
附录B：RUP和TMap测试活动的详细对比
下面的两个表在详细层次上对比了RUP和TMap的活动。第一个表说明了与RUP活动相连的每个阶段的TMap活动。当没有清晰的关系时，这个域已经被标记了一个问题标记(?)。请考虑，一个RUP活动可以出现在多个工作流上。在许多情况下，一个工作流的活动可以被映射到一个TMap活动上是很清楚的，但是相同的活动不能被映射到一个不同的工作流上。这种情况的一个例子是测试和评价中的“定义测试明细”，其可以被映射到TMap规格说明阶段中的“准备测试规格说明”。相同的活动“定义测试明细”也出现在“改善测试资产”和“验证测试方法”上。在这些情况下，匹配的TMap活动还没有被填充。
原文转自：http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/koomen/
