敏捷开发和测试中重现缺陷和验证缺陷的解决方案(1)

第1部分:部署重现缺陷的环境

  简介:本文为系列的第一篇文章,首先简述了系列的主旨和每部分的内容。然后针对敏捷开发和测试中开发人员重现测试人员开出的缺陷这一问题,具体描述了如何用IBM工具Rational Automation Framework以及IBM Workload Deployer快速记录和部署重现缺陷所需的测试环境,从而让开发人员可以更快速准确地获得重现缺陷的环境。

  系列背景简介

  在敏捷开发的大环境下,产品需要根据用户的需求不断进行变化,产品版本的研发周期越来越短,产品的交付速度越来越快,只有开发和测试人员之间保持更加有效更加频繁的交互才能保证产品按时高质量地交付给用户。其中,开发人员和测试人员之间交互最多的部分就是缺陷 (defect) 问题的讨论。当测试人员发现问题并提交缺陷以后,开发人员需要重现测试人员发现的问题,并进行研究。最终针对缺陷的产品代码改动被开发人员提交到产品中,测试人员需要迅速对产品代码的改动进行验证,以确认缺陷不再出现在产品新的版本中。

图 1. 缺陷生命周期示意图

  为了适应产品交付速度的加快,我们从缩短缺陷验证周期的角度描述了如何使用 IBM 工具来帮助我们。以下是系列文章的三部分内容:

  ● 敏捷开发和测试中重现缺陷和验证缺陷解决方案,第1部分:部署重现缺陷的环境

  ● 敏捷开发和测试中重现缺陷和验证缺陷解决方案,第2部分:重现缺陷

  ● 敏捷开发和测试中重现缺陷和验证缺陷解决方案,第3部分:验证缺陷

  一个具体的实例

  "Garden of Summer"是一个基于 IBM WebSphere Application Server 中自带的以销售鲜花、水果、绿植为主的电子商务网站。

图 2. WAS 中的电子商务网站实例

  时,开发人员需要重现测试人员发现的问题并进行研究。在重现缺陷的过程中,开发人员用于重现缺陷的环境往往与测试人员的测试环境存在不一致,而这些配置的详细描述信息又不能非常准确没有疏漏的填写在缺陷的描述中,这样开发人员不能方便重现缺陷问题。为了保证环境配置一致,开发人员和测试人员之间需要花费大量的交流时间,或者我们经常做的是测试人员直接把测试环境交给开发人员去使用。

  例如上述的电子商务网站应用,可能存在复杂的应用服务器配置,所以如何方便快速搭建一个同样的发现缺陷的环境使我们急需解决的。

  下面我们来分享一下如何使用 Rational Automation Framework(RAF) 来记录测试环境的配置信息,然后直接通过 RAF 和 IBM Workload Deployer 的无缝集成实现缺陷环境的云端重现。

  IBM Rational Automation Framework 简介

  IBM Rational Automation Framework 能够自动执行中间件环境构建、中间件管理以及应用程序和相关工件的部署。这种可定制且可扩展的框架支持 IBM WebSphere?中间件、Oracle WebLogic Server 和 JBoss Application Server。现在,您可以利用该产品降低成本,自动执行复杂的管理和部署任务,并且可以掌控中间件环境。要点是:

  ● 降低运营成本 - 通过降低有关部署、维护及合规性的成本,以及与管理大型异构中间件相关的其他开支,降低运营成本。

  ● 提高生产力 - 通过自动执行易于出错的手工任务提高生产力。Rational Automation Framework 使团队能够利用较少的资源完成更多的工作,并且缩短完成任务所需的时间。

  ● 改进应用程序交付 - 通过提高速度、一致性和质量,使您能够使用一致、准确且可复用的流程交付应用程序。

  RAF 是一个定制化的,并且可扩展的自动化框架,它包括了中间件自动化管理,应用自动化部署以及产品安装和补丁安装的自动化。从 RAF 3.0..0.5 版本开始,RAF 实现了与 IWD/PureAS 系统的集成,并且作为 Advanced Middleware Configuration 成为了 IBM PureAS 的一部分。这部分的集成,使得 RAF 有能力读取一个现有的环境信息,同时在 IWD/PureAs 系统中生成一个与现有的环境相同配置的一个虚拟系统模式,用户可以使用该虚拟系统模式,在云环境中生成一个与现有环境相同配置的环境。

 IBM Workload Deployer 简介

  IBM Workload Deployer 是一种硬件设备,提供了对 IBM 中间件虚拟映像和模式的访问,支持轻松、快速、重复地创建可在专用云中安全部署、管理的应用程序环境,加速了将应用程序部署到云和虚拟化环境的过程。要点是:

  ● 在单独一个模式中利用多个虚拟映像的功能。

  ● POWER7 支持。

  ● 增强的部署配置文件自定义。

  ● 支持 WebSphere Application Server Hypervisor Edition for Red Hat Enterprise Linux Server on System z。

  ● 提供 WebSphere Application Server Hypervisor Edition - Intelligent Management Pack。

  ● 通过预先定义的模式和虚拟映像加速 WebSphere 环境的应用程序部署,并大幅缩短设置时间,从数周缩短到短短几分钟。

  ● 通过消除妨碍生产力的手动流程提高敏捷性。

  ● 作为安全、防篡改的映像和凭据存储库,确保共享环境中的安全性。

  ● 全面整合来自 IBM Rational?和 Tivol?的开发和服务管理工具,提供端到端支持。

  具体实现

  下面我们来描述一下具体使用的方法,这里我们将分为两个部分:

  ● 缺陷环境配置的捕捉和云端化

    → 捕捉测试人员的环境配置

    → 生成云端虚拟模板 (Virtual System Pattern)

  ● 部署缺陷环境

    → 实例化云端虚拟模板,部署重现缺陷环境

    → 同步环境配置到已存在的开发人员环境

  第一部分:缺陷环境配置的捕捉和云端化

  RAF 针对中间件信息的监控提供了集中不同的模式供用户使用:

  ● Import 模式
● Execute 模式
● Compare 模式
● Augment 模式
● Promote 模式
● Preview 模式

  首先我们要捕捉测试人员环境配置信息,这里需要用到 RAF 的 import 模式,这个模式中 RAF 可以把中间件的配置信息捕捉下来并存储到 RAF repository 中。

图 3. RAF 的 import 模式

  第一步:打开 RAF 登录界面,输入用户名和密码。

图 4. RAF 登陆界面

第二步:点击 Env Gen( 生成环境 ) 窗卡,选择 Read Existing Cell( 已存在的单元 )

图 5. RAF 仪表板 (dashboard)

  第三步:输入操作系统的登录信息,进行信息验证

图 6. 当前应用服务器单元的配置信息界面

  第四步:输入 Websphere Application Server 的 profile 路径并且进行 WAS 路径验证,默认值 (linux 示例:/opt/IBM/WebSphere/Profiles/DefaultDmgr01)

图 7. WAS profile 目录输入界面

  第五步:输入 WebSphere Application Server 的 security 信息

图 8. WAS 安全信息输入界面

  第六步:这里首先给出一个 Virtual System Pattern(VSP) 的名称,这个名称相当于我们正常理解的 VM template,然后需要用户提供测试环境的信息,hostname,用户名和密码,最后一个选项是提示用户是否覆盖已经存在的同名的 VSP

图 9. IBM Workload Deployer 信息填写界面

 第七步:确认后,RAF 会进行逐一操作并输出日志

图 10. 执行进度

  通过上述操作我们可以在 RAF 中看到相关的环境配置信息

图 11. RAF 中存储的环境配置信息

  同时我们也可以在 IWD 中 Virtual System Pattern 看到已经创建的虚拟模板。( 后面环境创建时会有屏幕信息展示。)

  第二部分:部署缺陷环境

  上面我们已经通过 RAF 捕捉了环境 ( 中间件 ) 配置信息,并把这个环境的虚拟模板云端化了,下面我们要通过这个虚拟模板把环境实例化,实现云端部署。

  在 RAF 读取环境信息的同时, RAF 在与 IWD 的集成环境当中,生成了一个虚拟系统模式。这个虚拟系统模式包括了与现有环境信息相同的中间件拓扑结构和配置信息,以及 RAF 的相应信息和脚本文件。

图 12. 通过 RAF 和 IWD 集成生成的 Virtual System Pattern

  第一步:登陆 IWD,并找到之前创建时命名的 Virtual System Pattern

图 13. IWD 主页面

图 14. Virtual System Pattern 中节点拓扑

  第二步:选择部署 (deploy) 进行实例化:

图 15. 部署确认界面

 第三步:部署结束后开发人员会获得新的虚拟机的 hostname,用户名和密码。

  第三部分:同步捕捉的测试环境配置到开发人员环境

  在工作中我们还常常会遇到这样的问题,开发人员已经自己搭建了一个环境,他希望能够把自己的环境配置变得和测试人员发现缺陷时的环境一样,可以么?

  答案是肯定的,我们可以借助 RAF 的另外两个模式:Compare 模式和 Execute 模式。Compare 模式可以对比开发人员的环境配置和之前我们捕捉的测试环境的差异,然后通过 Execute 模式,可以把这个开发人员的环境配置变成测试环境配置。

  第一步:对比开发人员的环境配置和之前捕捉的测试环境配置

图 16. Rational Automation Framework Client 界面

图 17. Compare 模式对比的结果

  第二步:针对测试人员和开发人员环境配置的不同,在 RAF Client 中进行相应的修改。

  第三步:在 RAF Client 中,右键点击测试人员的环境,选择 Run Action.

图 18. Execute 模式执行界面

 第四步:使用 Execute 模式执行 Dynamic Action was_common_configure_all,可以把开发人员的环境配置同步成测试环境配置

图 19. Execute 模式执行界面

  使用完毕后开发人员还可以把环境配置变回去。在 RAF Rich Client 中,选择一个 Scope 点击右键,选择 Restore from Local History。选择需要恢复的版本并再一次执行 Execute 模式,用户可以轻松的讲配置恢复到上一步执行 Execute 之前的某一个环境配置信息的版本。

图 20. 恢复到历史版本界面

  目前我们已经通过 RAF 和 IWD 把重现缺陷所需的环境部署在了云端,下面开发人员就可以在这个环境上安装被测产品并根据测试人员在缺陷中的描述重现缺陷问题,关于如何提高这部分的效率,我们将在系列第二篇中详细讲述。

  未来展望

  捕捉更多环境信息

  目前使用 RAF 我们只能捕捉应用服务器等信息(IBM WebSphere Family Product,IBM WebSphere MQ Series,WebSphere Message Broker ,Oracle WebLogic ,Red Hat JBoss),但是一下操作系统相关的信息还不能准确捕捉,我们还需要借助其他工具,比如 IBM Tivoli 的产品获得更多测试环境的信息。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-10 21:51:58

敏捷开发和测试中重现缺陷和验证缺陷的解决方案(1)的相关文章

针对敏捷开发和测试中开发人员:部署重现缺陷的环境

在敏捷开发的大环境下,产品需要根据用户的需求不断进行变化,产品版本的研发周期越来越短,产品的交付速度越来越快,只有开发和http://www.aliyun.com/zixun/aggregation/9621.html">测试人员之间保持更加有效更加频繁的交互才能保证产品按时高质量地交付给用户.其中,开发人员和测试人员之间交互最多的部分就是缺陷 (defect) 问题的讨论.当测试人员发现问题并提交缺陷以后,开发人员需要重现测试人员发现的问题,并进行研究.最终针对缺陷的产品代码改动被开发人

独立软件测试团队在敏捷开发中的几个特别实践

最近读了<测试人与敏捷团队的五个约定>,很是赞同.但发现其并没有紧扣敏捷开发测试的特点,这五个约定在传统开发中已经早有实践,也有相关论述.哪么在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践? 从敏捷团队的组建上来说,敏捷团队并没有要求安排专门的测试人员,甚至于在某些的方法中不建议清楚的区分开发人员角色和测试人员角色. 本文讨论的是已经存在独立测试团队的情况,如何在敏捷开发中进行高效的测试. 实践1:测试保护开发 通过快速的自动化测试跟进开发,保证新增和修改不破坏已经获得的成果

创建标准化代码在VS中实现敏捷开发

标准化程序开发是敏捷开发中的核心内容之一.标准化代码不仅有利于团队之间的合作,也有利于模块之间的集成,节省时间与成本.在VS中也为创建标准化代码做出了很多努力.笔者在这篇文章中就跟大家分享一下,在VS平台中创建标准化代码的注意事项.具体的说,就是五大禁令和四大推荐. 禁令一:不要随意检查代码. 这可能跟用户正常的认识有所差异.有些开发人员可能认为在开发过程中,检查代码是必须的.不过在敏捷开发的模型中,这恰恰是禁止的.因为如果在代码的编写中,不时的检查代码,会浪费开发人员大量的时间与精力.当然,这

DevOps和IaaS开启云时代的开发和测试

背景 在软件发展的几十年历程中,人们一直在孜孜不倦地追求用更快的速度交付更高质量的软件及服务.无论是不断革新的软件工程思想,还是持续优化的编程语言及工具,亦或是纷纷出现的可复用开发.测试框架,无不大大提高了整个软件开发及交付的效率.但是,与此同时,软件系统复杂度急速上升,可靠性要求越来越高,这让软件快速交付依然非常具有挑战.尤其是进入互联网和云计算时代,市场竞争异常激烈,人们对于软件交付的周期已经从原来的以季度.年度为单位缩短到以天计算,以便在市场中快速试错,找到真正的用户需求.这些都给传统的软

敏捷开发-快速迭代

今天跟大家分享的是"敏捷开发.快速迭代".我们大都采用的是"瀑布开发模式",有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理.经过YH系统的开发,也且生体会到了这一弊端. 有问题就要去解决它!于是我想到了"敏捷开发".借鉴敏捷开发模式,来改善软件开发过程,提高项目的开发效率. 要想借鉴,首先得弄懂以下3个问题. 1. 什么是敏捷开发 百度百科中是这样解释的:敏捷开发是一种以人为核心.迭代.循序

敏捷软件开发之何为敏捷开发

敏捷开发,Agile Development,就是指能够在需求迅速变化的情况下快速开发软件.我们接触最多敏捷实践方式有:极限编程(XP).结对编程.测试驱动开发(TDD)等. 追究敏捷的历史,就必须要提到著名的敏捷开发宣言,2001年,17位业界专家(其中包括我们非常熟悉的Martin, Martin Fowler)组成了一个敏捷联盟,并且创建了一份敏捷联盟宣言,宣扬了4条核心价值观:     1, Individuals and interactions over processes and

敏捷开发时代:软件安全测试需更灵活

我们生活在一个软件定义的世界中.软件几乎接触到方方面面.任何努力保持竞争优势或市场先机的企业,都必须在某种程度上重新整合其软件.这会导致快速的开发方法,如敏捷开发和开发运维,促进持续的产品改进.但是,这些新的开发方法能够使测试最小化,反过来又可能破坏性能和安全性. 为保持竞争优势,企业必须提供高质量的应用体验.此外,安全是必须的而不是"有安全性也不错".因而,持续的测试方法已经日益重要,其动态性就像新的开发过程一样.幸运的是,企业越来越明白这种不断增长的需要,并且重新思考整个过程. 推

需求采集为小公司敏捷开发中的用户服务

网页制作Webjx文章简介:最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只要把握的好,数据分析工作做 最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只

敏捷测试中理想的测试组织

近些年,在软件项目中非常流行一个词--敏捷.大大小小的项目,通常都包含着"敏捷"这个 关键字.其实敏捷本身是一种优化的思想,是软件工程发展到一定阶段后的产物.面对风云变幻的市 场,都希望迅速响应市场或客户的变化.但如何真正在项目中做到敏捷,除了方法论之外,还有各种 外部条件的制约.而现实是很多研发团队只注重了方法论的学习,而没注意组织结构应该如何变化才 能适应敏捷测试的需要.有的人可能会说,敏捷强调的不是人人都应该是开发和测试吗?但这只是在 理想情况中.真实项目中,肯定还是存在测试和开