软件测试人员对 RUP 四个阶段的贡献：另一种观点(2)

　　系数将被平台的数量或所需的其他类型的测试工作副本所修改。

　　缺陷管理、构建，发布过程

　　存在与将测试人员插入开发过程中有关的成本。测试人员共享其他项目团队使用的特定开发工具，如用于缺陷跟踪的工具，以及构建和发布工具，如用于配置管理的工具。

　　精化(Elaboration)阶段：管理技术风险

　　RUP 的精化阶段是对准技术风险的管理的。为了制定出自该阶段的可行或不可行的决策，我们需要论证一个对每个鉴别出的技术风险的满意解决方案。通常，最糟的技术问题由非功能需求导致。非功能需求可以造成这样的有趣断言“系统将拥有 99.999% 的可用性，”或者“系统将支持 10,000 个同时发生的用户会话。”这些需求写起来便宜，但满足和测试起来昂贵。为了进行适当的评估，我们需要了解：

　　在完成极端的非功能目标中可能隐含的权衡。

　　当接近这些极限时各种架构退化的方式。

　　有了此数据，架构师可以选择最适当的架构，并且，当涉众面对他们需求的所有含意时，通常会更愿意调节他们的雄心，并且得到更多的回报。

　　因此，关键的评估需求是其中一个度量，并且这应该是此阶段测试人员主要的目标。

　　量度方法的评估

　　对于每个技术问题，架构团队将建立一个或多个具体表现一个解决方案方法的可执行系统。可能会有若干有竞争的解决方案(举例来说，通信中的 UDP 对 TCP)和大量的对于每个解决方案的可配置选择(举例来说，进程架构中的 10 线程 对 50 个线程)。测试人员执行对生成架构的度量所必需的步骤。

　　度量强调的是是否对解决方案有了成熟的考虑而不是功能是否被正确的实现了，因为没有人会期望生命周期中早期就实现完全正确的功能或者甚至花费大量的精力去雕琢还不成熟的系统的功能。初始阶段中指定的许多实验室环境将在精化阶段中被需要。我们将度量性能和可伸缩性，跨过通信链接和出自数据库的数据速率，随负载变化时的响应时间，并且我们将生成需求所要求的其他度量。根据所有的架构原型执行这些测试，并且测试团队将与架构师携手工作，共同设计确认或驳斥每个设计决策的测试。

　　当传统测试人员可能会参与整个基于文档的活动时，测试团队在此阶段的行为与瀑布过程中所做的惊人地不同。当项目从一个危机牵绊到下一个时，许多工作都不相关了。相反，在迭代的项目的精化阶段，测试人员在起劲的行动着，被闪光灯和不停的拨号所围绕。测试人员赞成相关的且实际的测试，使它们与架构师保持一致，并且评估并解释结果。

　　当然这是富有挑战的工作，但同时还是要大量参与的、有价值的，并令人满意的。如果对于小型的团队环境及上千行的代码的情况建立这些测试都是棘手的，那么设想一下对上百万行的代码项目的大型团队来说所受到的阻碍。

　　虽然这个阶段执行测试设计和实现，但是我们应该记住，重要的是测试结果而不是测试文档。由于将会抛弃许多架构的提议，所以相关的测试也一样。我们仅需要做足够的测试设计和实现，用以获得必需的度量。我们不像细化提议那样做太多测试，随着最主要的架构候选的出现，我们可以添加严密，如可溯性和其他文档。

　　测试设计

　　作为并行活动，精化阶段表现出一次方便的时机来考虑技术架构中的小变更如何能够更好的帮助测试设计和测试自动化。

　　通过测试自动化，我的意思是使用记录键盘和鼠标事件的 GUI 记录或回放工具，可以回放来重复测试。经验丰富的测试人员知道自动化尤其要求重要的脚本维护工作。值得考虑一下允许脚本构造的“测试架构”，这与设计人员创建“软件架构”来简化应用程序构造具有同样意义。

　　测试人员应该考虑解决方案，特别是测试可能参数化的方法或映射到需求所暗示的“组合爆炸”的结合方法的复杂性维度。例如，考虑一个指定某个需要支持的平台组合的非功能需求。根据一个平台撰写脚本，在所有平台上“回放”是有利的。这同样可以应用到数据库后端、应用程序服务器、Web 服务器和环境基础架构的其他元素，并且特别是对于这些的排列组合。手动测试每个组合将是不能忍受的痛苦。测试自动化是唯一经济的解决方案。

　　大多数应用程序为测试人员的专长提供许多应用程序专用的机会。设计人员将找到“用参数表示”问题领域的方法，并且这些经常成为类似地用参数表示测试所沿着的维度。例如，在我所工作过的一个应用程序中，有许多看起来一样的屏幕上的表格，因此设计人员将列参数化为通用的小部件，这给予测试人员类似的能力来用参数表示它们的测试。

　　针对测试的设计在精化阶段如此重要的一个原因是在构建阶段很难找出时间来适当处理这一活动。但是有一个甚至更好的理由：通过测试人员和设计人员之间的良好对话，架构中的小让步可以给测试设计添加一个大好处。总而言之，精化阶段是针对测试而设计的适当时机。

　　构建(Construction)阶段：管理进度风险

　　RUP 的构建阶段瞄准进度风险的管理。如果应用了 RUP 首选的基于用例的方法，就可以比利用传统的(瀑布)方法更快地集中于可用的(尽管不完全)系统。当达到这一可用地不完全层次，剩下的路也就不远了。

　　该方法生成了一系列客观的改进的可执行系统，并且拥有重要的优势：

　　在尽可能最早的时候给客户展示系统的功能。

　　团队可以及早地获得部署经验。生成的可执行系统可以转化为产品化阶段的子集(部分部署)。这使我们获得产品化阶段问题的经验 —— 例如，验收测试所需要的是什么，如何为部署而打包，以及一百个其他的问题(参见下面的产品化阶段)。

　　我们收集量度，这使得在迭代开发中可以立即看到项目进展。在瀑布过程中，不太可能直接比较分析活动量度和设计活动量度或编码活动量度，因为它们是完全不同的活动。但在迭代过程中，比较迭代 1 的量度与迭代 2 的量度更加容易，因为我们在重复同一组活动。

　　在几个星期内，我们就会完成一个分析——设计——编码——测试的周期，这个给我们一种明显进展的感觉。这就是构建阶段的迭代的独特之处。测试活动评估进展并验证确实有了进展。

原文转自：http://www.ltesting.net