本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章(如下面所列)的第 9 部分。
本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated,我们的客户 Audiophile Speaker Design, Inc. (ASDI),它雇用我们实现他们最初的 IT 需求。对于更详细的信息,参见 第 1 部分。 到目前为止,我们已经接近了 ASDI 项目第一阶段的尾声了。ASDI 已经获得了我们提供的一系列的系统演示,并且他们对产品感到十分的满意。(实际上,我们有一些担心,因为项目的第一阶段已经是如此可用的系统,我们担心 ASDI 会推迟或者取消接下来的第二阶段的项目。) 客户感到满意的最终因素是我们进行了充分符合需求的系统测试和验收测试。
包装开发 构建的频率 自动化的脚本尤其使进行这么频繁的构建变得切实可行。至少我们运行了脚本来测试被我们已经解决了的缺陷所影响的系统部分。我们通常可以更进一步,为系统的大多数或者全部运行脚本。我们非常幸运我们能够通过自动化的测试脚本来测试系统的模块;Rational 的测试工具能够非常好的符合我们使用的技术,然而,有一些其他技术的结合可能会给测试脚本的使用带来挑战或者根本无法使用测试脚本。 集成测试(I&T) 团队的介入 I&T 团队根据他们对工程团队进展的理解定义预计将要构建的目标。他们与项目工程师一起讨论构建以确保构建能够符合他们的预期。例如,如果因为一些组件或者子系统没有准备好,工程团队没有为功能测试准好准备,对于组装,检查每一个被编译的的代码、被匹配的接口和第三方的工具(JDK、库和购买的工具)在线程和子系统团队成员中是一致的来说,构建只是简单的练习活动。对于系统十分成熟的构建来说,团队将根据系统特定的方面进行负载测试或者功能测试。 接近开发周期的尾声,I&T 的领导是一个项目团队中非常重要的角色 - 甚至比团队领导或者项目经理还重要。I&T 领导为测试执行指定计划,了解系统区域的弱点和长处,并不断的监控缺陷分析数据。同时,他也管理需求、组件、线程、测试脚本和缺陷的完全的跟踪映射,这可以帮助他对他的团队的动作进行计划和优先级划分。 修复缺陷
无论 I&T 团队什么时候在系统中发现了一个缺陷,他们都会在 ClearQuest 数据库中提交它,在数据库中他们能够获得上面所提到的很多细节。他们在 ClearQuest 中连接数据库,并在提交缺陷表单中填写缺陷,如图 1 所示。
缺陷数据库能够被所有的工程团队的成员所共享,并能够通过网络在任何时间内被访问。例如,在图 1 中被提交的缺陷的所有者,他的工作是在产品的搜索能力上,他与搜索团队负责用户信息的成员分在同一组中。为了保持对任何被分配的打开状态的测试问题的跟踪,I&T 团队使用了一个 ClearQuest 的查询。图 2 显示了搜索团队的查询结果,图 1 中被提交的缺陷被显示在了结果集中。查询(结果总是反映被 I&T 团队更新的数据库的最新内容)结果被过滤了,仅仅包括搜索团队的缺陷,并通过优先级和提交时间进行排序。
其他的团队以相似的方式在他们各自的区域查询 ClearQuest ,并收到适当被过滤的结果。仅仅是 I&T 团队、项目过程师和团队领导能够看到项目进展中的完整的缺陷列表。 在图 2 中的 Actions 按钮提供了修改、分配、关闭、复制、推迟或者删除当前被选定查询结果的选项。根据项目团队成员的职位,不同人能够进行不同的操作:
系统测试 我们通常在被 I&T 团队建立的清洁环境中进行系统的构建,因此我们彻底的测试了构建的文档。如果在构建文档中遇到了任何的错误,一个问题(在“文档”分类中)连同任何被识别的测试缺陷被提交到缺陷数据库中。 从单元测试阶段(在第 8 部分被讨论)到现在,我们测试了系统的功能需求和系统的非功能需求,现在我们在系统的非功能需求上投入了比在早期测试阶段更多的精力。我们测试的主要非功能领域是可用性和性能(负载测试),我们将在下面进行讨论。 可用性建议 一些可用性的问题必须被推迟解决,因为他们超出了第一阶段的范围或者处理他们是非常耗成本的。然而,许多容易修复的和会给客户带来混乱的小的可用性问题被发现了。这是我们最成本高效的测试活动中的一些,因为通常从客户的角度来看,只不过是一些小的代码改变就能大大的改进产品。可用性的建议包括新的错误信息、布局的改进、调整按钮的标题和菜单、文档的整理和屏幕工作流程的修改。 负载测试 Web 负载测试 对于 Web 的负载测试,我们使用了 Rational SiteLoad 。这个工具能使我们录制由一系列我们执行的 Web 事务组成的脚本,然后将这些步骤复制作为多个虚拟的用户。我们和 ASDI 一起复查了被预期的负载模式以确定有多少用户同时访问 Web 应用,我们决定测试 20 个用户的负载。 通过使用 SiteLoad ,我们能够容易的模拟 20 个系统的并发用户,并精确的统计相关的系统性能。当我们启动 SiteLoad 时,它启动了我们的浏览器,并提示我们创建一个测试或者运行一个已存在的测试(见图 3)。
当我们选择录制一个新脚本时,SiteLoad 弹出一个基于 Java 的浏览器,并记录我们在它之上所做的所有动作。例如,当我们在这个浏览器中浏览我们的 partSearch.jsp 页面时,SiteLoad 从服务器端加载这个页面(如图 4 所示),并记录我们的动作,包括我们输入的任何数据值和按钮的点击动作。我们设计了这个特定的测试以执行基于多个参数的很多次数据库查询操作。这显然是一个很简单的测试,因为数据库能够缓存查询;其他的一些测试会更加的严格和具有挑战性。
对于我们录制的每一个脚本,我们也能够为测试设置一些通常的性能需求。我们决定当测试 partSearch.jsp 页面的脚本被回放时,我们希望至少有 90% 的页面在四秒或者更少的时间内被加载(见图 5)。虽然这并不符合高性能的要求,但这对于我们系统的可用性和整体质量来说已经足够了。
图 6 显示了我们如何配置 SiteLoad 来模拟 20 个并发用户反复的执行我们记录的 partSearch.jsp 页面的动作。SiteLoad 能够进行更加复杂的性能建模以帮助我们找出我们的系统的“性能围墙”,但是我们选择在我们的首次尝试中直接进行 20 个并发用户的最大值测试。如果我们遇到问题,我们将减少最初的用户数量至 5 个,并每一分钟或者两分钟增加一个用户。我们也能够为终止测试设定一个标准,但我们没有这样做,因为我们正可视化的监视测试的过程以了解我们的系统有什么样的行为。
当测试正在运行时,SiteLoad 显示并不断的更新象图 7 中显示的统计数据。在这个例子中,一个柱状图表明我们的测试脚本的性能结果;几乎所有的页面都在 8 秒钟内被加载执行(换句话说,只有 0-20% 在我们的 4 秒钟内的性能限制中)。使用在屏幕顶部附近的绿色菜单栏中提供的选项,我们能够选择查看更加详细的测试报告,比如,页面访问、CPU 负载和平均负载时间。
B2B 负载测试 对于 SSL/XML 的 B2B 负载测试,我们使用了 Rational Robot 来录制虚拟用户(VU)脚本。我们输入我们希望 Robot 执行的命令来监视并以一个脚本的生成最为结束,这个脚本与被 Robot 生成的 GUI 脚本(在 第 8 部分被讨论)十分不同。不像 GUI 脚本,VU 脚本记录和接收与传输信息相关的低级信息。通过从多台机器运行 VU 脚本,我们能够模拟并发操作系统的 B2B 客户端会话。 ASDI 怀疑可能会有多余两个的并发会话会发生,因此我们能够完成一些超越这个需求的步骤,以确保良好的系统性能。 测试完成情况检查
除了检查上面的项目,我们还复查并预排了一个系统演示,整个演示作为产品的最终展示服务于与客户进行外部的 TRR 。我们为我们构建的产品自豪,并且我们希望确保显示系统所有关键的特性,因为我们知道 ASDI 的高层管理人员将出席这个外部的 TRR 。 在外部 TRR 期间,我们按照与内部 TRR 相同的日程安排进行。我们与 ASDI 一起审阅了检查列表以显示每一件事情都被完成了,并且结束了这个演示。并不令人惊讶,在最终的演示中出现了更多的一些想法,处于对将来的考虑我们将他们注释下来。 验收测试 当我们在外部 TRR 中陈述 CAT (客户验收测试)将是相当简短的,并且我们能够非常快速的执行和检查脚本的执行结果时, ASDI 表示他们想看到所有一步一步的测试执行以便他们知道发生了什么。虽然我们不希望这样,但看起来对我们还是公平并且可行的。我们为我们的测试脚本文档化了所有的测试过程和计划,甚至当脚本升级时,我们也维护了我们的测试计划,因此,对于我们来说手工执行测试不是什么问题。 我们没有准备的是手工进行验收测试要花费多长时间。现在我们根据我们文档化的测试过程进行手工的测试,我们意识到自动化的测试为我们节省了多少时间。 我们发现在我们的测试过程中丢失了一些必须提供的细节。我们不总是能够获得足够的信息来创建一个明确的并且可反复使用的测试。我们也意识到有时我们更新了测试脚本但没有修改测试计划。在对测试计划进行了小的变更后,我们为一个快速检查向客户交付了测试计划;我们同意变更是非常小的,并不需要其他的 TRR 。 验收测试发生在我们的开发环境中,开始于根据构建文档进行清洁的构建,并引发测试过程的执行。这些测试大概会花费一共两到一天半的时间来执行。我们团队中的三个成员执行这些任务(I&T 领导、项目工程师和团队领导),还有三个来自 ASDI 的人员(QA、项目经理和技术领导)。 我们引以自豪的是在验收测试期间没有软件缺陷出现。仅仅出现了一些不重要的问题,通常是在“文档”和“不友好行为”类别中的。所有的需求都被满足了,客户在测试结束时非常的高兴。 总结 尤其是测试过程有一个很大的成功。Rational 工具给人印象最深刻的也许是测试的功能。这是我们第一次引入自动化测试,并且我们对它工作的如此好感到惊讶。自动化测试的最大痛处是相应需求变化的脚本修改;然而,这个责任被传递给了集成与测试团队,因此不会影响我们的工程团队的工作。 计划未来 主要风险
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=240519 |
|