- 浏览: 274568 次
- 性别:
- 来自: 武汉
文章分类
敏捷开发
是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
1,敏捷开发的路线:
- Test-Driven Development,测试驱动开发。
它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。
- Continuous Integration,持续集成。
在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。
- Refactoring,重构。
相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。
- Pair-Programming,结对编程。
在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。
- Stand up,站立会议。
每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。
- Frequent Releases,小版本发布。
在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。
- Minimal Documentation,较少的文档。
其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。
- Collaborative Focus,以合作为中心,表现为代码共享。
在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。
- Customer Engagement ,现场客户。
敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。
- Automated Testing ,自动化测试。
为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。
- Adaptive Planning,可调整计划。
敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。
2,敏捷开发方法
敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。
敏捷测试
首先敏捷测试(Agile testing)是测试的一种,原有测试定义中通过执行被测系统发现问题,通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
敏捷测试是遵循敏捷宣言的一种测试实践:
1、强调从客户的角度,即是从使用系统的用户的角度,来测试系统。
2、重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
敏捷测试与普通测试的区别:
1.项目相当于开发与测试并行,项目整体时间较快。
2.模块提交较快,测试时较有压迫感。
3.工作任务划分清晰,工作效率较高。
4.项目规划要合理,不然测试时会出现复测的现象,加大工作量。
5.发现问题需跟紧,项目中人员都比较忙,问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决,对相关的模块的测试影响比较小。
8.版本更换比较勤,影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。
是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
1,敏捷开发的路线:
- Test-Driven Development,测试驱动开发。
它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。
- Continuous Integration,持续集成。
在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。
- Refactoring,重构。
相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。
- Pair-Programming,结对编程。
在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。
- Stand up,站立会议。
每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。
- Frequent Releases,小版本发布。
在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。
- Minimal Documentation,较少的文档。
其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。
- Collaborative Focus,以合作为中心,表现为代码共享。
在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。
- Customer Engagement ,现场客户。
敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。
- Automated Testing ,自动化测试。
为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。
- Adaptive Planning,可调整计划。
敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。
2,敏捷开发方法
敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。
敏捷测试
首先敏捷测试(Agile testing)是测试的一种,原有测试定义中通过执行被测系统发现问题,通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
敏捷测试是遵循敏捷宣言的一种测试实践:
1、强调从客户的角度,即是从使用系统的用户的角度,来测试系统。
2、重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
敏捷测试与普通测试的区别:
1.项目相当于开发与测试并行,项目整体时间较快。
2.模块提交较快,测试时较有压迫感。
3.工作任务划分清晰,工作效率较高。
4.项目规划要合理,不然测试时会出现复测的现象,加大工作量。
5.发现问题需跟紧,项目中人员都比较忙,问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决,对相关的模块的测试影响比较小。
8.版本更换比较勤,影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。
发表评论
-
自动化测试遇到的一些问题
2013-07-11 12:43 8731, 页面上的checkbox 上执行click来勾选,结果出 ... -
(二) robot framework - variable file
2013-06-18 10:21 7417一,文件中创建variable的两种方式 1) 直接创建: 例 ... -
(一)Robot Framework的安装与卸载
2013-06-17 16:40 14117序言 关于robot framework (RF) 2.7+版 ... -
自动化测试应该在什么阶段进行?(转)
2013-05-21 13:05 1855软件自动化测试,作为 ... -
简单使用Selenium Grid
2013-01-22 16:59 39571, 启动hub(机器X) Hub作为中央节点,他将接收所有的 ... -
Selenium 2 跑safari浏览器 (在windows XP系统上)
2013-01-21 16:38 31481,配置环境(什么装JDK,ECLIPSE,SELENIUM, ... -
我常用的的处理模态窗口的方法(selenium 2)
2013-01-04 15:44 5814主要思想: 使用Java Robot模拟键盘的回车 来替代 s ... -
selenium + python 环境安装(转)
2012-12-16 04:07 12968安装程序 python-2.7.2.msi,python安装 ... -
Selenium 处理 modal 对话框(转)
2012-11-16 17:27 3601Selenium目前没有提供对IE模态对话框(即通过showM ... -
xpath再学习(持续更新中)
2012-06-19 17:52 1489目标XML代码: <?xml version=" ... -
自动化测试规范(转)
2012-06-17 10:05 1188测试用例名同测试用例的编号。 每个测试用例粒度 ... -
hudson编码问题
2012-06-10 10:54 1383现象1:在系统设置中提示:Your container doe ... -
关于Selenium 使用CSS定位的好教程
2012-01-30 17:36 1810Selenium Tips: CSS Selectors in ... -
selenium2 入门
2012-01-11 15:49 13231.1 下载selenium2.0的lib包 http:/ ... -
selenium支持的浏览器列表
2011-11-15 15:15 1539Supported browsers include: *f ... -
Selenium 的SeleneseTestBase和SeleneseTestCase
2011-11-10 13:21 23642个api的区别:SeleneseTestCase 和 Sel ...
相关推荐
总之,敏捷开发与敏捷测试是紧密相连的,它们共同致力于快速交付高质量的软件。通过敏捷开发的理念,如迭代开发、客户合作和响应变化,测试活动得以更好地融入整个开发流程,确保产品的稳定性和可靠性。同时,敏捷...
### 敏捷开发与敏捷测试的核心概念及其应用 #### 敏捷测试的定义与实践 敏捷测试作为一种紧跟敏捷开发理念的测试方法论,其核心在于更高效、灵活地确保软件质量的同时,保持整个项目的快速迭代与交付能力。敏捷...
在《敏捷开发与测试-V2.4(思步沙龙-北京站).pdf》中,可能详细介绍了敏捷开发和测试的实践、工具、案例研究以及如何在团队中成功实施敏捷的方法。通过深入阅读这份资料,开发者和测试人员可以更好地理解和应用敏捷...
敏捷开发强调的是快速响应变化、用户参与、团队协作以及持续改进,它不仅仅是一种开发方法,更是一种思维方式。 #### 二、敏捷软件过程概述 敏捷软件过程是一种注重快速迭代和持续改进的软件开发方法论。相比于传统...
Lisa Crispin 和 Janet Gregory 是敏捷测试领域的权威专家,她们在《敏捷软件测试:测试人员与敏捷团队的实践指南》一书中详细阐述了敏捷测试的实践方法、理念以及测试人员在敏捷开发中的角色和职责。 在敏捷测试中...
敏捷测试是一种与敏捷开发方法论相适应的测试策略,强调快速反馈、迭代开发和团队协作。在敏捷环境中,测试不是孤立于开发的过程,而是与之紧密集成。它鼓励频繁的自动化测试,确保代码的质量和系统的稳定性。敏捷...
敏捷测试模型强调的是与开发并行进行,测试不仅局限于功能测试,而是扩展到业务逻辑和接口测试。这要求测试人员: 1. **前置测试**:在需求阶段就开始参与,理解需求,尽早发现潜在问题。 2. **快速反馈**:通过短...
### 敏捷开发的核心理念与实践 #### 一、敏捷开发概述 敏捷开发是一种强调灵活性、快速响应变化的软件开发方法论。与传统的瀑布模型相比,敏捷开发更加注重团队之间的紧密协作、持续改进以及高质量的产品交付。...
传统的测试方法往往难以适应敏捷开发的速度与变化,因此如何在敏捷开发中有效地实施测试成为了一个重要的课题。 #### 二、敏捷开发及其测试模式简介 敏捷开发是一种以用户需求为中心,通过迭代、增量的方式快速...
《敏捷软件测试实践指南》是清华大学出版社出版的一本专业书籍,专注于讲解敏捷测试与敏捷开发的理论和实际操作。本书旨在帮助读者理解并掌握在敏捷环境中进行高效、灵活的软件测试方法,以适应快速变化的项目需求。...
现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功,但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息合并成一个整体,从而使其能够直接应用。, 本书为敏捷的计划、开发、交付和...
系统分析师-敏捷开发方法 本文将论述敏捷开发方法在系统分析师中的应用,通过实践证明,在项目的开发中采用合适的敏捷开发方法可以有效地缩短开发时间,提高产品质量。本文将从以下几个方面论述敏捷开发方法的应用...
它提倡在变化的环境中快速适应,敏捷开发常与Scrum框架一起使用。Scrum是敏捷开发中最流行的实践方式之一,它是一种迭代式增量的软件开发过程,采用时间驱动的Sprint周期来进行管理。 敏捷思想强调涌现式需求,即...
随着软件开发方式的演进,敏捷测试作为敏捷开发的重要组成部分,其实践与理论逐渐成为业界关注的焦点。敏捷测试不仅关注软件产品的质量,更注重整个开发过程的优化与改进。本文基于《敏捷测试的实践和理论》一文,...
测试驱动的软件开发(TDD,Test-Driven Development)...总的来说,TDD 和敏捷开发相结合,为软件开发提供了一种高效、高质量的方法论,但需要开发者有较高的测试意识和技术能力,以及团队对敏捷原则的深入理解和应用。
"敏捷开发方法与实践交流.pdf"这本书籍可能更侧重于实际操作和案例研究,分享了敏捷开发在实际项目中的应用经验和教训,帮助读者理解如何在团队中实施敏捷,如何进行敏捷规划、需求管理、迭代开发、每日站会、回顾...