2010-09-28 23:32:52 d8111 阅读数 21
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

1.开发负责代码编写,dev环境发布和测试;beta则需要提转测申请,由测试把关,发布。IDC则更甚。

2.开发负责代码编写,dev环境发布和测试;beta开发也可以发布,IDC也是有开发控制发布节奏。测试介入beta环境,IDC测试用例


上面两种哪种更为敏捷呢?最近的经验告诉我,答案是1. 因为职责的分明,有了强烈的版本节奏感。在一个需要快速迭代的web服务项目,版本节奏非常重要!!做过的话,你就懂的。

方案2,相对于方案1,则更适合项目起步,快速发展期。(因为在方案1中,鉴于国情,测试经常资源不够,测试mm过于固执非要改xx地方。。。)

两种方案的敏捷区别,并不在于开发人员本身的代码素质。更多要求的是开发对业务的全面理解和对测试的理解。



3.DO分离,就是开发负责写代码,运维人员负责IDC机器的一切,开发人员不应该上IDC机器。

但是是不是敏捷了呢?

以前上IDC看日志文件,现在需要做模块,抓日志下来看。。。

以前开发可以上IDC top/free, 监控代码表现,现在只能YY。。。

以前可以上DB机,查看分表数据是否均衡,磁盘容量和占用比,现在只能听天由命,或者找运营的沟通,提需求,周期则从2分钟变成1D。

那么这么不敏捷的流程,为什么会执行??就像现在的互联网服务一样,单点扩容的代价是高昂的,需要分区容忍性, 适当的单机效率降低,换取便捷的扩充性。从质量管理上看,非常合理,容易保证测试环境和IDC环境,控制代码风险,事故责任容易划分。

2019-12-18 16:29:18 villainy13579 阅读数 10
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

尽管跳上敏捷的潮流对企业来说很有诱惑力,但这并不总是那么容易,向敏捷的转变很可能伴随着的是测试方面的一系列挑战。为了使敏捷能够快速交付高质量的产品,测试必须比以往更早地开始介入。

 

今天,任何软件应用程序都需要在大量的设备、操作系统、浏览器、硬件配置和网络上无缝地运行。但是,使用传统的瀑布式测试模型来确保这一点是不可能的,因为涉及到太多的变量和依赖项。这就是软件开发的敏捷模型发挥作用的地方。开发和QA在跨职能团队的小迭代或冲刺中紧密协作。

敏捷就是要对变化做出响应,不管这些变化是与技术相关的还是基于客户需求的。在这种跨功能和协作的软件开发方法中,快速创建解决方案以实现业务目标。敏捷使团队能够以更快的速度设计适合客户需求的产品。

尽管跳上敏捷的潮流对企业来说很有诱惑力,但这并不总是那么容易的,向敏捷的转变很可能伴随着特别是测试方面的一系列挑战。

  1. 转向敏捷时的测试挑战

走敏捷路线需要转变思维方式。为了使敏捷能够快速交付高质量的产品,测试必须比以往更早地开始。这带来了一些无法预料的挑战。

  • 改变心态:早期测试的好处应该清楚地传达给组织中的每个人;否则,员工就不会理解改变测试方式的重要性。质量应该成为整个团队的责任。测试必须在每个冲刺环节的第一天开始,而不是在最后。对这些做法的任何抵制都会延迟软件的交付。
  • 不灵活的员工:在传统的瀑布模型中,每个QA专家都知道他们的角色是什么。测试责任明确,没有混淆的余地。使用敏捷,目标是以尽可能最佳的方式执行所有必要的开发任务。在这种情况下,角色不是那么具体,每个人都被要求在必要时提供帮助。这会导致对要做的工作以及测试人员扮演什么角色的不确定性。如果不解决这种不确定性,它可能会滋生阻力,最终导致交付脱轨。
  • 缺少文档:由于敏捷测试通常涉及自动化测试,因此有跳过所需文档的倾向。但由于缺乏文档,无法充分跟踪重要的事情和过去的变化。为了克服这一点,应定期进行内部审计或测试评审,以确保产生适当数量的文件。还应该使用与用户情景一致的测试管理工具来跟踪测试进度。
  • 实现跨团队无缝协作的障碍:敏捷测试方法要求跨职能团队每天无缝协作。然而,某些团队可能不像其他团队那样迅速地接受跨团队协作,并且可能仍然倾向于在竖井中工作。如果没有开发人员和测试人员日复一日的合作,质量和交付将受到影响。
  1. 敏捷测试策略的关键促成因素

克服这些挑战并成功地过渡到敏捷测试取决于以下几点,但这些是最有用的实践。              

  • 左移:与瀑布模型不同,在瀑布模型中,测试是在开发之后进行的,左移是关于移动测试活动,以便它们与开发一起完成。这有助于快速识别缺陷并加快开发生命周期。在这里,测试的重点在开发周期中提前或向左移动,从而在每个冲刺环节结束之前更好地识别缺陷。通过早期的测试,早期的错误检测和缺陷控制成为可能。
  • 测试自动化:由于需要在全渠道平台上验证软件并快速测试,敏捷测试专家必须利用测试自动化来执行重复测试,如回归。选择正确的工具并学习如何编写可维护的自动化测试脚本是必不可少的。
  • 持续测试和反馈:由于交付周期缩短,不可能在测试上花费额外的时间。事实上,在敏捷软件开发生命周期(SDLC)中,测试和质量保证应该是一个与开发并行运行的连续过程。这需要开发人员和测试人员之间的无摩擦协作,以便最终产品满足所有需求。
  • 虚拟化:在动态测试环境中,需要跨位置测试软件和api的各种参数,服务虚拟化是必不可少的。它虚拟化和模拟测试变量和软件的缺陷,而无需使用整个实际应用程序。              
  • 集成手工测试和自动化:仅仅通过手工测试来满足敏捷冲刺环节的紧迫期限是不现实的。为了使测试与开发并行运行,手动和自动测试都必须集成到SDLC中。只要过程变得重复和平凡,自动化就会派上用场。当手头的任务需要创造性和分析性思维时,应引入人工监督。这样做将有助于提高整体效率,因为自动化将提高速度和准确性,手动测试将有助于创新的方法来修复错误。              
  1. 使您的测试更加灵活

在软件开发和测试生命周期中建立敏捷实践需要每个团队成员的积极参与。敏捷周期的运行速度并没有为单独的测试阶段留下太多空间,因此测试应该是连续的、自动化的,并且与开发阶段并行。应尽早开始,并在SDLC的每个阶段进行。              

只有开发团队和测试团队之间的无缝协作才能实现这一点。没有协作,敏捷测试就不可能成为可行的,你所拥有的只是快速的传统瀑布过程。

测试
2011-04-27 22:26:00 hhb200766 阅读数 335
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

在测试与开发并行的过程中,如何保证测试的充分性,测试的依据,如何确定需求的完整性等等

根据少量的需求开发并测试,如何保证测试的覆盖率,及功能的完整性,业务的完善性

在一个少依据,没有规范测试用例的情况下,如何与开发并行去完成系统的测试和保证系统的质量

在xp开发的过程中,测试在某一时刻介入,对产品的功能进行测试的同时,也是对产品需求某种程度的完善

此时产品进入一个迭代的测试开发--开发测试的循环过程,为了响应快速实现快速实施的目标,

产品测试趋向项目的质量目标,

在上述前提下,开展测试:

这种无序的测试,在人员可控功能可控的范围内,进行测试,如何保证开发测试的并行?

无疑配置管理起着至关重要的作用,每次的迭代,代码的改动,无疑对开发测试都是一个挑战,

举个例子:第一个小版本测试发现问题,在第二个小版本测试时已验证修复,但在第3个版本时之前修复的问题有重新浮现,并且可以看到原来修正的2/3bug有出现了,这时可以明确发布小版本有问题,最终无人去对这个过程所犯的错误埋单,

对开发测试来说前2论的测试无疑是浪费时间了,时间对一个产品某种程度上意味着市场,

信息快速迭代的时代,速度意味着生命,敏捷测试或许因此而产生,

不难看出一个规范的流程对开发测试来说都是不可缺少的,流程或许难以规范,但是必要的阶段还是有很好的警示作用,团队的作用在这个时候就能体现出他的优势了,大家行动一致步调统一,才使得进度保持一致

 

 

2012-07-05 21:58:18 liubofengpython 阅读数 957
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师
前两天公司组织了一次敏捷开发模式的分享会,对于测试人员来说,为了推动整个模式的高效运作,测试也有敏捷,如下是个人觉得敏捷测试中涉及到的一些关键点与大家分享。

一、测试也有敏捷

1、全程参与

      测试人员从项目立项到发布结束全程参与整个研发过程,而不是开发完毕后很突然的提交到测试部安排测试,测试人员必须从需求阶段就开始介入,从理解需求到帮助产品人员完善需求;在我们很多项目中经常忽略了测试人员参与需求的评审及讨论,这个和W模型中谈到的测试和开发并行稍有区别,以前的有V和W模型,而现在的是敏捷模型(具体区别在哪里有时间再和大家分享)。

2、从客户出发

      保持大局观,站在客户的立场,保证最终发布的是一个优秀的产品,而不仅仅是提交了多少个Bug,这主要是价值取向不一样,在一个团队中,不管你处于什么角色,最终的目的是要让这个产品是一个优秀的产品,是客户需要的有价值的产品,而不是各个角色在这个项目中付出了多少,提交多少Bug等等各自的业绩数据。

3、测试驱动

      测试驱动产品整个开发过程,测试人员要做的不仅仅是测试,而是要做对这个项目一切有利的事情,比如与客户沟通需求澄清、版本控制、流程机制等其他事务。

4、时刻敏捷

      根据不同迭代调整测试策略(测试进度、人力投入、测试方向)

5、不是一个人

      项目所有人员均参与测试,当然测试人员肯定是主要角色了,其他开发人员、产品人员等和项目相关的人员也要抽一定的时间来测试,只是和测试人员测试的重点和方向不一样而已,比如产品人员更多的关注用户体验、价值收益等,一但发现问题或者不妥之处立即反馈修正。

 

二、走出敏捷误区

1、敏捷开发是否需要文档?

      敏捷肯定也需要文档,只是没有CMMI要求的那个严格,那么细致。我们也不能完全依靠文档来帮助我们提高效率,但一些框架性基础性的文档肯定是需要的,特别是基础需求,这样能够帮助项目成员了解整个项目的大概意图。在敏捷的过程中我们要做好文档的变更管理(因为变化无处不在)。

     很多人认为敏捷重在沟通,这完全没错,但我们不能因为这个缺乏一些文档支撑,不能只靠口头或者零粹的邮件代替文档,那就是乱上加乱,敏捷过头了!

2、敏捷开发模式与项目管理是否有冲突?

     完全没有冲突,只是价值观有些区别,其实在某种意义上来说,如果项目管理没做好就直接进入敏捷模式跨越比较大,推行起来比较困难,比如项目管理中涉及到的变更管理、沟通管理等这些都是敏捷模式所需要的,也是一些基础性的工作方式。因此可以认为项目管理是一个基础。

3、敏捷是善变的良药?

    显然敏捷不是善变的良药,一个产品的研发过程中肯定会涉及到很多变化,但是我们的方向不能变,比如开始需求是要做一个花卷,最后改成要做包子,其实像这类变化是不能容忍的,如果要改变花卷的颜色形状那还是可行的。

    敏捷中涉及到的变化是指在需求不清晰的情况下,通过迭代让客户快速确认反馈最终形成一个非常清晰的需求并得以呈现,而不是随意的变化,那技术人员不累死还不讨好。

三、敏捷要求

1、产品的整体规划及需求说明(包括未来的产品走向)

      我们把产品比喻成一个孩子的话,那么产品经理就犹如这个孩子的父母,作为父母的必须要为孩子的成长做一些规划,这样才有利于孩子的成长以及在成长过程中根据孩子的反馈不断的修正成长路线,这样父母才是一个合格的父母。

2、迭代计划需要产品人员制定和重点把控

      和前一个观点差不多,只是说明产品人员是一个产品成功或者失败的关键,是产品的灵魂人物,产品经理们责任重大啊。

3、迭代的划分要遵循可测试性原则(保证每次迭代是一个可执行完整操作流的测试)

      在做迭代计划中需要测试人员参与考量下每次迭代的可测试性是否最佳,不能出现迭代开发完毕后完全是一个不能测试不能评估的半成品,都展现不出什么价值谈何评估反馈,不能为下一个迭代提供有价值的东西那么就不要去迭代,直接与其他合并即可。

4、迭代中的需求变更需要落实在文字或图表上

5、测试将原有的W测试模式变为迭代测试

6、文档流程只是一个辅助工具,最主要依靠及时有效的沟通(文档、沟通之间如何权衡这是个度的问题,千万不能走极端)。

欢迎转载此文,转载时请注明文章来源:张元礼的博客 http://blog.csdn.net/vincetest


2018-12-25 14:41:25 qq_40729662 阅读数 44
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

现在大家都在讲敏捷开发,那对应的敏捷测试是怎么开展的?
1、敏捷开发 基本思路就是快速迭代, 小步快跑,持续响应用户需求的变化, 不断增加产品的功能
那敏捷测试就必须适应这种开发的节奏:
1、测试尽早接入,尽早搞清楚要做什么需求,这样测试可以准备的更充分些(很多时间在需求澄清的时候才介入)
2、理解清楚需求, 做好测试用例,做好用例评审
3、随着迭代的持续,产品功能越来越多,测试在每个迭代需要回归的功能越来越多, 实现合理的自动化测试,把人从重复的劳动中释放出来, 专注于新需求的测试
4、做好持续集成,尽早发现每次系统集成起来的bug

一个偶现的问题,我们如何去重现,重现的思路是什么?
1、偶现的问题,说明我去重现了,只是没有复现出来, 不然你肯定不知道这个缺陷是不是偶现的
那我们怎么去重现呢?
1、仔细回顾自己的操作过程, 思考自己重现的过程是否和出现缺陷的过程一致
2、把出现bug 的日志找出来,看看日志中是否有报错,如果有分析,这个错误出现原因,不能分析出来找对应的开发看看
3、在重复自己步骤,查看日志都没有重现的情况下, 思考出现这个bug 可能和那些操作有关, 最好思考整个业务流有哪些情况, 比如订单显示不对, 业务流就是生成订单到结算订单到查看订单
然后看业务流的每个过程中数据库数据记录是否正确,日志中是否有异常
4、如果还是不能定位出来,还是要提交bug单,然后让开发定位

sprint敏捷开发

阅读数 252

没有更多推荐了,返回首页