应用 Rational 工具简化基于 J2EE 的项目第 9 部分: 产品化开发与测试
上一篇 / 下一篇 2007-06-27 17:39:33 / 个人分类：10.RUP学习笔记
本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章（如下面所列）的第 9 部分。
- 第 1 部分: 项目介绍；高层次计划
- 第 2 部分: 风险管理；需求管理
- 第 3 部分: 模型创建和访问控制；需求分析
- 第 4 部分: 用例细化；产成报告；工具和技术选择
- 第 5 部分: 体系架构和设计
- 第 6 部分: 详细设计；早期开发；双向工程；早期单元测试
- 第 7 部分: 继续开发；早期的构建；演示
- 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本
- 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付
- 第 10 部分: 项目完成；结论；未来的工作
本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。对于更详细的信息，参见 第 1 部分。
到目前为止，我们已经接近了 ASDI 项目第一阶段的尾声了。ASDI 已经获得了我们提供的一系列的系统演示，并且他们对产品感到十分的满意。（实际上，我们有一些担心，因为项目的第一阶段已经是如此可用的系统，我们担心 ASDI 会推迟或者取消接下来的第二阶段的项目。） 客户感到满意的最终因素是我们进行了充分符合需求的系统测试和验收测试。
包装开发
在这个时候，我们的编码工作已经显著的减少了。我们在修改和精化产品的阶段，团队的工作主要是针对一些小的更改。当集成与测试（I&T）团队发现软件的缺陷时，他们在基于缺陷缺陷跟踪的数据库模式之上的 Rational ClearQuest 数据库中填写并对缺陷进行优先级划分。这些缺陷报告被工程团队复查。团队领导和项目工程师通常决定缺陷的优先级并维护一个描述对于被给定的构建版本哪一个人将对其进行修复的计划。
构建的频率
执行完整的系统构建版本的频率 �� 在一个清洁的环境中从头开始构建系统 �� 使我们大大的接近了第一阶段项目的尾声。最初计划每个月进行一次构建，但这些构建有时被每周进行一次。这对于大的项目或者缺少高技能的开发人员的团队来说，建立一个清洁的构建环境的日常开支、从源代码库中得到软件，构建系统和测试系统的行为是不太可行。然而，感谢我们所使用工具的紧密集成、我们良好的文档建立过程和我们使用了 Rational 的测试工具快速的完成了我们的测试执行，我们才能够将系统的构建增加到每周一次的频率。
自动化的脚本尤其使进行这么频繁的构建变得切实可行。至少我们运行了脚本来测试被我们已经解决了的缺陷所影响的系统部分。我们通常可以更进一步，为系统的大多数或者全部运行脚本。我们非常幸运我们能够通过自动化的测试脚本来测试系统的模块；Rational 的测试工具能够非常好的符合我们使用的技术，然而，有一些其他技术的结合可能会给测试脚本的使用带来挑战或者根本无法使用测试脚本。
集成测试（I&T） 团队的介入
目前为止，我们到达了进行系统构建的阶段，I&T 团队完全的投入到并领导这个过程。在项目的开发周期中(在 第六部分)我们就将 I&T 团队引入到了项目团队中，并且进行全职的工作，因此现在他们已经做好准备了。在我们之前的项目中，我们比较迟的将 I&T 团队引入到了项目中，几乎接近开发周期的尾声，但这会产生一定的问题。我们最终意识到 I&T 团队需要一定的准备时间，就像其他项目团队的技术成员一样。虽然对于我们较早的构建来说，在组装系统方面 I&T 团队要比系统团队慢，但是这是我们对他们预期的学习过程的一部分，并使他们自由的进行构建，而工程团队则可以继续他们的开发工作。
I&T 团队根据他们对工程团队进展的理解定义预计将要构建的目标。他们与项目工程师一起讨论构建以确保构建能够符合他们的预期。例如，如果因为一些组件或者子系统没有准备好，工程团队没有为功能测试准好准备，对于组装，检查每一个被编译的的代码、被匹配的接口和第三方的工具（JDK、库和购买的工具）在线程和子系统团队成员中是一致的来说，构建只是简单的练习活动。对于系统十分成熟的构建来说，团队将根据系统特定的方面进行负载测试或者功能测试。
接近开发周期的尾声，I&T 的领导是一个项目团队中非常重要的角色 － 甚至比团队领导或者项目经理还重要。I&T 领导为测试执行指定计划，了解系统区域的弱点和长处，并不断的监控缺陷分析数据。同时，他也管理需求、组件、线程、测试脚本和缺陷的完全的跟踪映射，这可以帮助他对他的团队的动作进行计划和优先级划分。
修复缺陷
修复缺陷绝不是微不足道的任务。每一个缺陷都会引发以下的问题：
- 这真的是一个缺陷吗？
- 它是什么类型的缺陷？它能属于这些分类的任何一种：装饰性的、不良的、数据丢失、文档、操作、安装、丢失特性、性能、稳定性、未期望的行为或者不友好的行为。
- 我们需要现在修复它还是将他推迟修复？
- 相关的需求不正确吗？
- 我们如何能够修复这个缺陷？
- 我们应该以什么样的速度修复它？
- 如果进行了修复，软件的哪些其他部分将会受到影响？
- 谁应该修复它？
无论 I&T 团队什么时候在系统中发现了一个缺陷，他们都会在 ClearQuest 数据库中提交它，在数据库中他们能够获得上面所提到的很多细节。他们在 ClearQuest 中连接数据库，并在提交缺陷表单中填写缺陷，如图 1 所示。
|
| 图1: 提交一个缺陷 |
| (点击放大) |
缺陷数据库能够被所有的工程团队的成员所共享，并能够通过网络在任何时间内被访问。例如，在图 1 中被提交的缺陷的所有者，他的工作是在产品的搜索能力上，他与搜索团队负责用户信息的成员分在同一组中。为了保持对任何被分配的打开状态的测试问题的跟踪，I&T 团队使用了一个 ClearQuest 的查询。图 2 显示了搜索团队的查询结果，图 1 中被提交的缺陷被显示在了结果集中。查询（结果总是反映被 I&T 团队更新的数据库的最新内容）结果被过滤了，仅仅包括搜索团队的缺陷，并通过优先级和提交时间进行排序。
|
| 图 2: 被过滤的缺陷查询结果 |
| (点击放大) |
其他的团队以相似的方式在他们各自的区域查询 ClearQuest ，并收到适当被过滤的结果。仅仅是 I&T 团队、项目过程师和团队领导能够看到项目进展中的完整的缺陷列表。
在图 2 中的 Actions 按钮提供了修改、分配、关闭、复制、推迟或者删除当前被选定查询结果的选项。根据项目团队成员的职位，不同人能够进行不同的操作：
- 工程团队成员仅仅能够修改或者分配缺陷。例如，搜索团队的领导能够将一个缺陷分配给他的团队的指定成员。
- I&T 团队能够执行所有的动作：在数据库中提交缺陷，修改、分配、关闭、复制、推迟或者删除缺陷。
- 项目工程师也有执行所有动作的权限，虽然关闭动作总是由 I&T 团队执行的。
系统测试
系统测试通过使用被录制的测试脚本对整个系统进行测试。这种测试不仅对客户的验收测试十分重要，同时它也深层次的检验了系统并提供了在测试脚本中的缺陷的洞察力。无论我们多么严密的对变更进行跟踪，也经常会有一些小的变更超出我们预计的范围从而带来一些冲突，以未预料的方式影响其他的代码片断。
我们通常在被 I&T 团队建立的清洁环境中进行系统的构建，因此我们彻底的测试了构建的文档。如果在构建文档中遇到了任何的错误，一个问题（在“文档”分类中）连同任何被识别的测试缺陷被提交到缺陷数据库中。
从单元测试阶段（在第 8 部分被讨论）到现在，我们测试了系统的功能需求和系统的非功能需求，现在我们在系统的非功能需求上投入了比在早期测试阶段更多的精力。我们测试的主要非功能领域是可用性和性能（负载测试），我们将在下面进行讨论。
可用性建议
我们用了我们仅有的可用性专家。虽然她被包含在早期的用户界面的计划和模拟工作中，帮助人机界面的工作，但她没有加入到我们和 I&T 团队的其他成员中。她现在的工作是作为一名用户与系统一起工作，找出可用性的问题，并将问题提交到缺陷数据库中（通常在“不友好的行为”类别中）。
一些可用性的问题必须被推迟解决，因为他们超出了第一阶段的范围或者处理他们是非常耗成本的。然而，许多容易修复的和会给客户带来混乱的小的可用性问题被发现了。这是我们最成本高效的测试活动中的一些，因为通常从客户的角度来看，只不过是一些小的代码改变就能大大的改进产品。可用性的建议包括新的错误信息、布局的改进、调整按钮的标题和菜单、文档的整理和屏幕工作流程的修改。
负载测试
我们的系统没有苛刻的性能需求，但是我们想让系统在最大负载下是可用的。我们在早期做了一些负载测试，但是这个测试类型会在接近开发周期的尾声时达到最高点。我们想确保系统能够超越 ASDI 的期望。我们希望我们能够以项目的第二阶段的形式得到接下来的工作，我们不希望造成性能的问题。我们对系统的两个部分进行了负载测试：Web 应用接口和通过基于 SSL/XML 的 command gateway （在第 5 部分被介绍）的 B2B接口。
Web 负载测试
对于 Web 的负载测试，我们使用了 Rational SiteLoad 。这个工具能使我们录制由一系列我们执行的 Web 事务组成的脚本，然后将这些步骤复制作为多个虚拟的用户。我们和 ASDI 一起复查了被预期的负载模式以确定有多少用户同时访问 Web 应用，我们决定测试 20 个用户的负载。
通过使用 SiteLoad ，我们能够容易的模拟 20 个系统的并发用户，并精确的统计相关的系统性能。当我们启动 SiteLoad 时，它启动了我们的浏览器，并提示我们创建一个测试或者运行一个已存在的测试（见图 3）。
|
| 图3: SiteLoad 的主屏幕 |
| (点击放大) |
当我们选择录制一个新脚本时，SiteLoad 弹出一个基于 Java 的浏览器，并记录我们在它之上所做的所有动作。例如，当我们在这个浏览器中浏览我们的 partSearch.jsp 页面时，SiteLoad 从服务器端加载这个页面（如图 4 所示），并记录我们的动作，包括我们输入的任何数据值和按钮的点击动作。我们设计了这个特定的测试以执行基于多个参数的很多次数据库查询操作。这显然是一个很简单的测试，因为数据库能够缓存查询；其他的一些测试会更加的严格和具有挑战性。
|
| 图 4: SiteLoad 记录浏览器的动作 |
| (点击放大) |
对于我们录制的每一个脚本，我们也能够为测试设置一些通常的性能需求。我们决定当测试 partSearch.jsp 页面的脚本被回放时，我们希望至少有 90% 的页面在四秒或者更少的时间内被加载（见图 5）。虽然这并不符合高性能的要求，但这对于我们系统的可用性和整体质量来说已经足够了。
|
| 图 5: 设置 SiteLoad 的性能需求 |
| (点击放大) |
图 6 显示了我们如何配置 SiteLoad 来模拟 20 个并发用户反复的执行我们记录的 partSearch.jsp 页面的动作。SiteLoad 能够进行更加复杂的性能建模以帮助我们找出我们的系统的“性能围墙”，但是我们选择在我们的首次尝试中直接进行 20 个并发用户的最大值测试。如果我们遇到问题，我们将减少最初的用户数量至 5 个，并每一分钟或者两分钟增加一个用户。我们也能够为终止测试设定一个标准，但我们没有这样做，因为我们正可视化的监视测试的过程以了解我们的系统有什么样的行为。
|
| 图 6: 设置 SiteLoad 用户特性 |
| (点击放大) |
当测试正在运行时，SiteLoad 显示并不断的更新象图 7 中显示的统计数据。在这个例子中，一个柱状图表明我们的测试脚本的性能结果；几乎所有的页面都在 8 秒钟内被加载执行（换句话说，只有 0-20% 在我们的 4 秒钟内的性能限制中）。使用在屏幕顶部附近的绿色菜单栏中提供的选项，我们能够选择查看更加详细的测试报告，比如，页面访问、CPU 负载和平均负载时间。
|
| 图 7: SiteLoad 的测试结果 |
| (点击放大) |
B2B 负载测试
对于 SSL/XML 的 B2B 负载测试，我们使用了 Rational Robot 来录制虚拟用户（VU）脚本。我们输入我们希望 Robot 执行的命令来监视并以一个脚本的生成最为结束，这个脚本与被 Robot 生成的 GUI 脚本（在 第 8 部分被讨论）十分不同。不像 GUI 脚本，VU 脚本记录和接收与传输信息相关的低级信息。通过从多台机器运行 VU 脚本，我们能够模拟并发操作系统的 B2B 客户端会话。 ASDI 怀疑可能会有多余两个的并发会话会发生，因此我们能够完成一些超越这个需求的步骤，以确保良好的系统性能。
测试完成情况检查
在我们计划中的最后两周里，工程团队进行了系统测试，并通过了所有的需求，并且 I&T 团队关闭了所有的问题，除了一些我们已经与客户讨论过得认为可以被推迟的不重要的问题。对于我们来说下一个里程碑是测试完成情况检查（TRR），我们执行了两个 TRR ：一个是内部的，一个是与客户一起的。内部的 TRR 以下列检查来实现：
- 所有的文档都完成了吗？
- 所有的代码都被检入（check in）并被测试了吗？
- 为了将来的查证所有的代码复查和单元测试列表都被存档了吗？
- 遗留任何没有被推迟的测试问题吗？
- 所有的变更请求都被关闭了或者合并进入需求了吗？
- Rational Rose 的全部模型被文档化并且适合交付吗？
- 系统的所有方面都向客户演示了吗？
除了检查上面的项目，我们还复查并预排了一个系统演示，整个演示作为产品的最终展示服务于与客户进行外部的 TRR 。我们为我们构建的产品自豪，并且我们希望确保显示系统所有关键的特性，因为我们知道 ASDI 的高层管理人员将出席这个外部的 TRR 。
在外部 TRR 期间，我们按照与内部 TRR 相同的日程安排进行。我们与 ASDI 一起审阅了检查列表以显示每一件事情都被完成了，并且结束了这个演示。并不令人惊讶，在最终的演示中出现了更多的一些想法，处于对将来的考虑我们将他们注释下来。
验收测试
为了 ASDI 同意项目的第一阶段已经被成功的完成，系统必须通过一些最终的验收测试。我们有理由相信系统能够通过这些测试，因为我们已经为执行系统的端到端的测试编写了一套脚本来检查是否所有的需求都被覆盖到了。这些脚本使用 Rational Robot 创建的，并且被 ASDI 彻底的检查过了。我们能够想到的唯一能够防碍我们验收测试成功的事情就是被工程团队最后时刻的变更可能会影响其他的代码片断。但是在我们开始验收测试之前我们收到了一个令人惊讶的消息， ASDI 在外部 TRR 中告诉我们他们想让我们手工的进行验收测。我们认为我们在验收计划中指出使用测试脚本的意图是非常清楚的，但是现在我们意识到我们在计划中的措词是含糊不清的。
当我们在外部 TRR 中陈述 CAT （客户验收测试）将是相当简短的，并且我们能够非常快速的执行和检查脚本的执行结果时， ASDI 表示他们想看到所有一步一步的测试执行以便他们知道发生了什么。虽然我们不希望这样，但看起来对我们还是公平并且可行的。我们为我们的测试脚本文档化了所有的测试过程和计划，甚至当脚本升级时，我们也维护了我们的测试计划，因此，对于我们来说手工执行测试不是什么问题。
我们没有准备的是手工进行验收测试要花费多长时间。现在我们根据我们文档化的测试过程进行手工的测试，我们意识到自动化的测试为我们节省了多少时间。
我们发现在我们的测试过程中丢失了一些必须提供的细节。我们不总是能够获得足够的信息来创建一个明确的并且可反复使用的测试。我们也意识到有时我们更新了测试脚本但没有修改测试计划。在对测试计划进行了小的变更后，我们为一个快速检查向客户交付了测试计划；我们同意变更是非常小的，并不需要其他的 TRR 。
验收测试发生在我们的开发环境中，开始于根据构建文档进行清洁的构建，并引发测试过程的执行。这些测试大概会花费一共两到一天半的时间来执行。我们团队中的三个成员执行这些任务（I&T 领导、项目工程师和团队领导），还有三个来自 ASDI 的人员（QA、项目经理和技术领导）。
我们引以自豪的是在验收测试期间没有软件缺陷出现。仅仅出现了一些不重要的问题，通常是在“文档”和“不友好行为”类别中的。所有的需求都被满足了，客户在测试结束时非常的高兴。
总结
这也许是我们的团队在开发和测试的结尾不必花费大量时间工作的第一个项目。其中对此作出贡献的因素是我们有更好的工具、对技术的熟悉和一个在项目早期就一起工作的工程团队。
尤其是测试过程有一个很大的成功。Rational 工具给人印象最深刻的也许是测试的功能。这是我们第一次引入自动化测试，并且我们对它工作的如此好感到惊讶。自动化测试的最大痛处是相应需求变化的脚本修改；然而，这个责任被传递给了集成与测试团队，因此不会影响我们的工程团队的工作。
计划未来
现在我们在客户的环境中安装了软件，并给他们一些时间评估系统。虽然没有一个正式的保证阶段，但是 ASDI 一直在向 ClearQuest 数据库中提交问题。最后，一个是否进行项目第二阶段的协议必须被达成。
主要风险
在此时我们觉得已经没有任何主要的风险了。我们很自信所有大的问题都已经被解决了，并且我们充分的准备了这个项目剩余部分可能会出现的任何问题。
| 关于作者
Steven Franklin 在软件的设计、架构和工程过程方面有非常广泛的背景，这些经验通常被用到大的，分布式的信息管理和控制系统中。他从1997年开始使用 Rational 工具，他主要的兴趣在 XML 、J2EE、无线和软件工程技术方面。你可以通过 steve@sfranklin.net联系 Steven 。 |
Link URL: http://www.cnblogs.com/jackei/archive/2005/01/12/90916.html
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
数据统计
- 访问量: 291182
- 日志数: 354
- 建立时间: 2006-12-26
- 更新时间: 2007-09-16
