对敏捷开发的一些思考-软件测试技术实战(13)

发表于:2017-7-25 13:31

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:顾翔    来源:51Testing软件测试网原创

  13.6  对敏捷开发的一些思考
  13.6.1  简介
  敏捷软件开发(Agile software development),是从20世纪90年代开始逐渐引起广泛关注的一种新型软件开发方法,它是应对快速变化的需求而产生的。它的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",共同点是更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本及紧凑而自我组织型的团队等,它能够很好地适应需求变化的代码编写和团队组织,更注重软件开发中人的作用。"敏捷"(Agile)一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。敏捷开发是软件工程经过原始模型、大棒模型、瀑布模型、迭代模型后产生的。
  敏捷组织宣言是。
  个体和互动高于流程和工具。
  工作的软件高于详尽的文档。
  客户合作高于合同谈判。
  响应变化高于遵循计划。
  敏捷组织12条原则是。
  (1)通过早期和连续型的高价值工作交付满足"客户"。
  (2)大工作分成可以迅速完成的较小组成部门。
  (3)识别最好的工作是从自我组织的团队中出现的。
  (4)为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。
  (5)创建可以改善可持续工作的流程。
  (5)维持完整工作的不变的步调。
  (7)欢迎改变的需求,即使是在项目后期。
  (8)在项目期间每天与项目团队和业务所有者开会。
  (9)在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。
  (10)通过完车的工作量计量工作进度。
  (11)不断地追求完善。
  (12)利用调整获得竞争优势。
  13.6.2  敏捷开发的优点
  1.采用敏捷.可以快速提高软件的发布周期
  许多软件公司以前采用瀑布模型:从业务建模、需求调研、需求分析、设计、编码及软件测试到最终送交给客户使用,需要经历很长的周期。而采用敏捷开发,可将一个产品或项目分解为多个sprint,开发小组每周或每几周提交一部分产品,而这部分产品都要保证是可运行,可使用的。经过多模块的集成及集成测试,客户每一到两个月就可拿到一份可以使用的软件产品,这样可保证客户尽早发现产品所存在的问题,及时反馈回来。此外这里并不是产品的重要部分,而是它关注的特性,有需求不符合能快速反馈和及时修正,从而缩短软件发布周期。敏捷开发提倡客户参与到项目中去,尽管实施起来比较困难,但若能够真正做到这一点,就更加体现出了敏捷开发的优点。另外若再采用火车模型进行产品发布,则更可以有效地缩短产品发布的周期。
  2.采用敏捷开发,软件测试能够尽早参与到项目中来
  (1)测试前移,能够参与到需求分析当中,这样对系统能有更深入的理解,方便后面挖掘深层次的Bug
  (2)测试人员是代表客户测试,在前期参与到需求澄清,与客户沟通交流,将沟通结论放到测试场景中去,防止做出来的东西与客户实际期望有偏差。
  (3)测试人员应尽早介入测试,能够帮助产品快速稳定,根据经验,开发代码发现的Bug满足二八原则,即80%的问题出现在那20%的代码中。如果测试人员发现问题较大,可以反向推动开发人员尽早进行重构等质量保证活动,不用等到后期代码和架构全部定下来了再去返工,会造成资源浪费。
  (4)从流程上来看,也是一样,如果测试前期就介入的话,就能及早发现问题,开发就能及时修改,不需要走繁琐的流程,假如是转系统测试之后找出Bug,就需要提单->审核->改单->审核->回归测试等多个流程,成本上会造成较大的浪费。
  3.釆用敏捷开发,可以减少许多不必要的文档
  记得笔者当时做QA工作的时候,领导要求我和我的同事撰写《公司产品开发软件测试流程规范》,这要涉及流程、干系人和文档这3个部分,见本篇第12.1节。在文档部分就要从业务建模、需求调研、需求分析、概要设计、详细设计、单元测试、集成测试、系统测试、验收测试到软件部署,共定义了五十多个模版。但在实施过程中很困难,大部分文档,开发、软件研发工程师写得都很草率甚至不写,问及原因,无非是时间紧迫或者认为书写这些文档是没必要的,他们会说:"设计和开发都是我一个人,一切都在我脑子里"。敏捷"宣言"中说:"工作的软件高于详尽的文档"。敏捷小组中的员工可以根据产品或项目的具体情况来决定应该写哪些文档,哪些文档可以不写,灵活决定。
  但必要的文档还是要有的,主要强调的是可以工作的软件,以前需要很详细的设计文档,原因是多方面的,可能这个要作为测试人员测试方案的输入,但现在测试是提早介入,对一些实现细节和方案是清楚的,所以可以省略。另外,敏捷开发强调的是每天提供可用的软件,做出来的东西,随时要随时可演示可交付,东西都出来了,也可用了,所以胜过一大堆文档。
  4.采用敏捷开发,结对编程与结对软件测试,是有利于提高产品质量并有利于培养新员工的
  结对编程与结对软件测试,一个人工作,另一个人随时检查,及时沟通,遇到问题立即解决。
  5.采用敏捷开发,日立会(Standup meeting)是一种很好的沟通形式
  日立会即每天早上研发小组内的所有同事在一起,每人各自介绍昨天做了哪些工作,今天计划做哪些工作以及工作中遇到了哪些问题。日立会是敏捷开发中的一项重要内容,它是一项很好的沟通活动。通过日立会,研发小组内的同事可以及时了解小组的工作进展情况。对于遇到的问题,若小组内其他同事可以协助解决,这个问题可交给这位同事处理;若小组内其他成员都无法解决,可由Scrum Master上报给上级领导,让上级领导决定如何处理。这样可以有效地提高工作效率。
  组织日立会一方面是及时暴露风险和问题,及时得到帮助和解决;另一方面就是能够督促每个人能按照每天的进度安排和计划及时完成任务,防止因为个人原因而导致项目进度延迟。
  任何一种方法有优点也会有不足之处,下面来谈一谈敏捷开发的缺点,这是本人的一些体会,不一定正确,仅供参考。
  13.6.3  敏捷开发的缺点
  1.采用敏捷开发,对开发团队的人员素质要求比较高
  敏捷开发的首要任务是快速,目前提出的"全栈软件工程师",它要求软件开发工程师在开发的各方面,即从需求,设计,编码,软件测试一直到系统搭建都要求是行家里手,这样可以减少因彼此沟通带来的时耗,这才能保证他在一个Sprint中能独立完成产品中某个特定的任务。显然这样的软件开发工程师的素质一定要求很高的,而在软件开发行业中,人员流动率高,新手多的情况下,要做到这一点是比较困难的。
  2.采用敏捷开发,开发工程师与软件测试工程师混为一体,彼此分工不明晰
  敏捷开发要求软件开发工程师会软件测试,软件测试工程师会软件开发,这实施起来是比较困难的。因为软件开发和软件测试工程师关注的重点是不同的:开发关注技术实现比较多,一般都采用正向思维;而软件测试关注业务比较多,多采用逆向思维。所以一个产品要保证有高的品质,就必须要有独立的软件测试工程师,因此测试和开发要有比较清晰明确的分工。正如古话所说:"闻道有先后,术业有专攻"。
  3.采用敏捷开发,是"短平快"的开发方式,由于产品发布周期短,所以产品的软件测试、维护、升级等操作的频率也增加了
  这必然增大开发工程师、软件测试工程师以及运行维护工程师的工作压力,在这样高压的环境下工作很容易出错,从而影响产品的质量。
  4.采用敏捷开发,不利于文档的建立和修改
  敏捷开发有一句口号"拥抱变化"。然而客户需求的变更是经常变化的,正如当今社会流行的"唯一不变的是变化"。为了缩短版本发布周期,特别是在版本发布之前,当客户的需求发生变更时,敏捷开发团队仅仅是修改代码而没有时间修改所对应的文档,这就造成了产品和文档的开发不一致性这就给产品的后期优化、调整或二次开发,带来了极大的麻烦,在人员频繁流动中更是灾难性的。
  13.6.4  总结
  敏捷开发是一个新方法,存在优点也存在缺点,我们不要一味赶时髦,要根据自己的企业现状和产品特点,选择符合自己的软件工程方法,只要这个方法可以给企业提高质量,带来效益,那就是一个好的方法。敏捷开发的特点是版本发布速度快,然而中国又有一句古话:"慢工出细活",现在又提出"工匠精神"活干得快,往往会影响质量,所以笔者认为对于一些版本发布频率要求不高,或者涉及严格质量要求的产品,比如航空航天、金融等领域的产品,不一定要采用敏捷开发的方法,可采用更适合于自身产品特性的软件开发方法。笔者有一位同行在美国工作,从事金融软件的开发业务,可以想象,这种产品的质量要求是很高的,容不得半点差错,所以他们仍旧采用传统的瀑布模型开发方法,他每天从软件设计工程师拿来设计文档,该文档写得很详细,然后按照设计文档进行编码,另外,他经常在家里通过互联网工作(每年只要去公司一到两次,公司Office只有40平方米,这样省去了为员工租用Office带来的开销),公司效益很好,已经维持了近二十年。
  13.7  精益创业与探索式软件测试
  最近阅读了李善友先生写的关于《精益创业》的4本书,主题思想是传统工业社会思维方式与现代互联网社会思维方式的区别。传统工业社会思维方式是先摸索用户的需求,然后依次为计划、实现、测试和使用。然而,用户往往开始时并不知道自己想要什么,提不出自己想要的真正需求。所以,现代互联网社会的思维方式要变为与用户一起先摸索、交流,经过多次迭代获悉用户最基本需求之后再进行开发、测试,然后交给用户使用,并且从用户使用情况中快速得到反馈信息,以挖掘更深层次的需求,最后再进行多次的迭代式开发和测试。
  这种摸着石头过河的思维方式是非常符合当前软件产品形式的。笔者经常把软件测试比喻为寻宝,缺陷在哪里?它具有很大的不确定性和一定程度上的未知性。而自动化测试是对基本的并且已知的缺陷进行验证,自动化软件测试的最大优点在于能有效地控制回归测试。探索式软件测试在软件测试过程中是非常重要,特别是基于测程管理的探索式软件测试加强了探索式测试的可管理性,这与精益创业的精神完全符合。软件测试工程师不要一上来就花太多时间去思考要测试什么,而是要通过不断地测试,逐步了解软件产品,产品中哪些地方容易出错,哪些地方就需要重点进行测试,并通过测试来决定采取什么手段进行什么样的测试,然后再决定如何进行更深一步的测试。
  自动化测试可对最基本的功能进行测试,其他的测试工作需要交给基于测程的探索式软件测试来完成了。
  下面简单介绍一下基于测程的探索式测试方法。探索式测试是一种基于经验的测试方法,而对于基于经验的测试方法最让人头痛的就是测试的管理方法。基于测程的探索式测试方法就是为了解决这个问题。参见图13-4。
  
  首先进入第一个测程。测程开始就是测试分析,设计和执行一起进行,测试过程中随时进行记录。比如,测试过哪些模块,使用了哪些方法,遇到了哪些问题,读者可以参见本书第一篇第3.2节"基于场景的测试"中的测试记录。一个测程一般在0.5~3h(这个数据是有科学依据的,小于0.5h思维进入不了状态,也就进行不了有效的测试,而大于3h,人就容易疲劳)。一个测程测试完毕后,测试工程师与测试经理及其他测试工程师一起讨论。测试记录总结如下内容。
  需要进一步学习哪些专业知识(包括业务知识、测试技术、其他知识)。
  系统中发现的哪些问题是有效的缺陷,讨论后填写到缺陷管理软件中。
  下一次需要重点测试哪些模块,使用哪些方法和技巧。
  然后进入下一轮测程。
  随着探索式测试测程的持续进行,探索式测试工程师对产品业务、缺陷分布情况有了越来越清晰的了解,从而能采用更加有效的具有针对性的测试策略。
本文选自《软件测试技术实战-设计、工具及管理》第十三章,本站经人民邮电出版社和作者的授权。
版权声明:51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号