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

在敏捷开发的大环境下,产品需要根据用户的需求不断进行变化,产品版本的研发周期越来越短,产品的交付速度越来越快,只有开发和">测试人员之间保持更加有效更加频繁的交互才能保证产品按时高质量地交付给用户。其中,开发人员和测试人员之间交互最多的部分就是缺陷 (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 系统中生成一个与现有的环境相同配置的一个虚拟系统模式,用户可以使用该虚拟系统模式,在云环境中生成一个与现有环境相同配置的环境。

时间: 2024-08-03 10:32:10

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

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

第1部分:部署重现缺陷的环境 简介:本文为系列的第一篇文章,首先简述了系列的主旨和每部分的内容.然后针对敏捷开发和测试中开发人员重现测试人员开出的缺陷这一问题,具体描述了如何用IBM工具Rational Automation Framework以及IBM Workload Deployer快速记录和部署重现缺陷所需的测试环境,从而让开发人员可以更快速准确地获得重现缺陷的环境. 系列背景简介 在敏捷开发的大环境下,产品需要根据用户的需求不断进行变化,产品版本的研发周期越来越短,产品的交付速度越来越

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

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

web接口开发与测试

最近一直在学习和整理web开发与接口测试的相关资料.接口测试本身毫无任何难度,甚至有很多工具和类库来帮助我们进行接口测试.大多测试人员很难深入了解web接口测试的原因是对web开发不太了解,当你越了解开发就会越看得清接口是什么.当然,web开发是比较麻烦,我们很难一下子掌握.   注:不过本文并不是一个零基础的文章,需要你对 Django web开发,requests接口库,unittest单元测试框架,三者有一定的了解.   Django快速开发之投票系统 之前分享过一篇Django开发投票系

浅谈在软件开发中的开发与测试

我们知道开发人员与测试人员在某种程度上可以说是冤家对头,因为开发总是认为我做的产品是完美无缺的,没有Bug的,但是测试总是想方设法给你挑刺,因而产生了"矛盾".很多公司对开发的绩效评估里就有一条是每千行代码产生的Bug量,当然是越少越好了,但是对于测试的绩效评估也有一条平均每天提交的Bug量,所以表明上看起来这种矛盾真的是无法避免的,因为大家都要"混饭"吃的. 但是大家其实心里都很清楚,一个产品不可能没有Bug的,或多或少,或大或小,总是会有Bug存在,不然微软也不

针对企业开发与测试访问IBM云计算功能

为应用程序开发和测试需求设置和维护IT 基础结构极具挑战性.前期的资本支出和运营成本很高,然而,通常基础结构的利用率却很低,很难在项目间实现共享.使得成本不断攀升的因素之一为获取.配置和维护软.硬件环境的艰巨任务.并且,由于这些任务大多需要手动完成,会因配置不正确而增加出现测试错误的风险.最终,依靠本地及全球的开发人员团队,您需要提出一项安全性极高的解决方案,来支持基于团队的应用程序开发与测试.云计算能够帮助您应对这些挑战,并降低循环时间,支持更快速地应用程序部署. 利用IBM Smart Bu

项目开发中切换部署开发、测试、生产多环境

在开发的过程中,不可避免会接触到至少三个环境的程序部署:开发.测试和生产环境. 每个环境都使用一套数据库配置,路径配置等,如果每次都人工的干预每一个配置文件,工作会比较繁杂,且容易遗漏并且出错. spring3.1之后提供了profile功能,可以切换不同的自定义profile环境,唯一的缺点是和maven结合不大好,只能在web.xml中进行修改. 方法如下: 1.在beans.xml中定义各个环境. <beans profile="develop"> </bean

请问:各位所在的公司有没有不设专门的测试岗位的、开发人员自已编写代码自已测试?开发人员感觉差不多了,就可以发布了?

问题描述 请问:各位所在的公司有没有不设专门的测试岗位的.开发人员自已编写代码自已测试?开发人员感觉差不多了,就可以发布了? 解决方案 解决方案二:当然有.没测试过的东西,谁有那个胆子发布?会出事的.公司有专门的测试岗位.程序员自己也要测试.解决方案三:很小的公司(<20人)的...一般没有专门测试岗位..解决方案四:自已顶起来解决方案五:有的几十个人的外企,一样没有专业测试团队.基本上就是给系统工程师黑盒跑跑看就可以发布了.毕竟这个公司的产品不是给平民大众用的.

通过 Rational Team Concert 实现敏捷的嵌入式产品线开发

概述 过去 10 年中,软件社区大量采用了敏捷实践.这些实践反映了现有的瀑布式软件开发流程中的缺陷: 交付缓慢 瀑布式方法需要几个月或者甚至几年才能创建出可执行(且可审核)的系统,因此减少了利益相关者提供反馈的机会,限制了业务灵活性. 尽早决策 由于提供审核和建议的机会有限,利益相关者必须尽早地确定对系统成功至关重要的特性. 有限的调整机会 长期.固定的计划减少了针对新环境进行调整的能力,无论是从技术发现还是从业务变更方面. 相比较而言,敏捷实践持续集成小型系统变更,提供了一个用于持续审核的环境

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

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